Government Case Study Addressing CMS EA business problems and driving transformation

By Mike Azar CMS Chief Enterprise Architect/Government | Christal Russ Lead Senior Enterprise Architect | David Rice Senior Engineer | Shahram Ghaffari Senior Cloud Engineer | Don Bohman Senior API Developer

The United States Center for Medicare & Medicaid services is the government agency responsible for administering the largest healthcare benefits programs in the country. As a federal agency, there is an expectation for robust enterprise architecture while balancing issues of scalability, sustainability and security.
In this session, we will discuss the transition strategy and implementation of the CMS EA tool suite. The presenters will speak about the challenges, innovations and processes used to successfully implement the Sparx Systems architecture platform.

Session Recording

Questions and Answers

Labnaf is a unified process, language, repository supported by productivity tools and dashboards. How do the Labnaf tools relate to Sparx: Summarizes

Some pieces start falling together, but it is still a few maturity steps ahead. First need to walk before we can run.

Resistance to changing toolsets can be a big problem in government agencies. What are some of the things you learned in the process about how to mitigate the "fear of change" and get people excited about the new platform?

Government concerns and hesitations are easily addressed by defining the to-be use cases of the architecture and assessing the current tool capabilities. When this is realized, the barriers from transitioning are broken down and the buy-off for the new tool adoption begins. Also, level setting our EA knowledge helped tremendously. The Design sprints gave us an opportunity to see what we can really do with a well-integrated architecture.

I heard 3 for EA Repository, which is my minimum figure as well. for up to 30 concurrent users and 100 Prolaborate licences

That's about right, some teams have 1 dedicated Model manager (Full time on it), or we can have 2 or 3 for Model management and administration.

Were there any lessons learned from this transformation initiative that can be applied to other government agencies facing similar challenges?

There are numerous lessons learned concerning this project specifically: 1. Ensuring you have the proper technical skills to support a major transition of an EA tool suite. You need to have resources that are familiar with operating in the Federal space, understand the federal EA requirements, they must have extensive knowledge of different frameworks, and experience in numerous EA-related industry tools. These resources were instrumental is delivering a flexible and highly functional EA tool suite. 2. The Government staff and leadership teams needs to be open to changing the way they have done things in the past. That required us to build trust, as well as educating and mentoring the government along the way. Also, the government team needs to be willing to make real-time decisions to meet the aggressive timelines. I am sure can speak more from his perspective.

Software product information is provided by Technopedia and is updated on a periodic basis. System Information is provided through our system census process.

We are seeing a lot more customers bringing in things like technopedia data to add depth to their apm data

Do you all do any reverse-engineering? How does that work?

The ELDM was reverse engineered from a SQL Server DB. Much of the additional data was populated via any number of means, import via Sparx NA's Model flow was key, as was the import of the BPMN model data via the BPMN 2.0 import

Are the users "specific named users" or are the users generic users? (for web-prolaborate). So, can many diff users use Prolaborate, not just the specific named users.

This is Prolaborate licensing specific query, Prolaborate licenses are usually purchased as bundles (in 50, 100, 250, 500, etc), These are not 'Named Users', You can have upto certain number of users added to the system at a point of time. However you can remove those and add another set of users if the projects change or the teams move on.

How did you elicit use cases from CMS partners?

These use case came from CMS partner requests. We decided at the beginning of our transformation he would serve our partners needs first in order to build out our data sets.

Are the 100 Prolab users...only for specific people?

These are not 'Named Users', You can have upto 100 of users added to the system at a point of time. however you can remove those and add another set of users if the projects change or the teams move on.

If you need objects broken out with specific object names, why do the objects not have object names within the database (like a normal/standard database). It sounds like that is an clear requirement: objects need to have names so they can be found in the data-tier in the database.

Reading this, for object type names (such as "System", "Organization" etc.) this is where the material Don was talking through comes in. Of course the Sparx database structure is what provides its flexibility, but when it comes to reporting or API work it is often more convenient for this to be made more consumable by folks not trained in the tool and its DB structure. The Team worked to create this more normalized structure for use for the API, data validation reporting, etc. It consists of Views and stored procedures for the Sparx DB.