THANK YOU FOR SUBSCRIBING

Configuration Management (CM), as a discipline for supporting software development, has been around for half a century and has evolved into standard practice within traditional Systems Development Life Cycle (SDLC) processes. A well-designed CM system integrated with well-defined processes and management buy-in is a highly valuable component of system implementations and operations.

"The successful implementation of cloud modules has been an incredible lesson in CM principles."

There are many definitions of configuration management, including industry association standards from the Institute of Electrical and Electronics Engineers, the Project Management Institute and others. Similarly, CM practices are a part of every popular SDLC model from Waterfall and Agile to extreme programming and everything in between. No matter the source of the definition, CM is sure to include the following practices:
• Maintain the CMDB (Configuration Management  Data Base)
• Identify Configuration Items
• Manage Version Control Repositories Identification for each type of Configuration Item
• Version control of the Configuration Items
• Build Management
• Control Changes and the ability to track them
• Auditing and Status Reporting

As the industry has evolved, it is clear that there is no one SDLC model and flavor of configuration management that fits all the needs and situations of every organization. The nature of modern IT is simply too dynamic. But case studies involving the most complex projects can yield important lessons as the industry moves to the cloud and beyond. In 2006, CNSI was contracted to update the state of Michigan’s aging Medicaid Management Information System (MMIS). A decade later, through multiple system implementations, including a migration to the cloud, the project has yielded an evolution and maturation of CM practices, which are defined below.

Phase 1 – Pre Configuration Management

-Prevent developers from spending time on builds and deployments
-Begin to identify a need to hire a dedicated CM Resource with clearly defined roles and responsibilities
-Set-up the Configuration Management System (CMS)

Phase 2 – Standalone Configuration Management

-Perform research on the toolsets to be used
-Provide inputs to executive management on the choices and cost justification
-Develop a formal CM Plan and implement it
-Hire dedicated CM Staff
-Select the build tools and set-up the automation framework

Phase 3 – Integrated Configuration Management

-Integrate CM into project delivery
-Take responsibility for CMS, Builds and Deployments
-Concentrate on automation and continuous integration

Phase 4 – Cloud Services

-Incorporate new build tools to meet the latest project demands as part of continuous improvement.
-Change existing Build Framework to support Cloud Enablement
● Multi Tenancy
● Self Service
● Automated Provisioning
-Focus on Continuous Improvement

Applying this phased approach to a MMIS, which is built around thousands of files with millions of lines of code, is a unique challenge in itself. Documentation becomes a key aspect of the complete package (requirements, design and change requests) and application binaries for final delivery to the customer.

The Michigan MMIS replaced a legacy (mainframe) system designed in 1972. After the system went live in 2009, a number of compliance mandates emerged, most notably the Affordable Care Act.

To complicate matters, several major project initiatives were undertaken in parallel, including a major user interface upgrade, and expansion of Medicaid eligibility, implementation of a mobile platform and migration to the cloud.

Each of these challenges required significant forethought with regard to CM. Once the project timelines were established, the code branching and merging strategy had to evolve to support the ongoing requirements in parallel along with supporting the day to day operations. As the system was expanding in its complexity, the Development/Testing/ Management Team was growing and becoming geographically dispersed—often in different time zones. New options like http(s) access were explored for the source control tool within the existing toolset to allow for effective and efficient collaboration over distant networks. Backup strategies were redesigned to be able to accommodate the needs of CMS availability across the time zones.

To address the evolving CM needs, design changes were made to the Defect Repository System to expand to handle the changes. All the future changes would be made with scalability and modularity as the underlying philosophy.

Just when CM capabilities caught up to the needs of the project, a new challenge emerged: to provide the MMIS as a service, also known as Medicaid as a Service (MaaS). The MaaS was to be hosted on a multi-tenant cloud infrastructure with shared commercial off-the-shelf components and separate application and database instances to comply with data security standards. The design of the system had to be revisited and code had to be refactored to support multiple tenants. Mature CM principles had to be applied to the hardware, documents, source code management, build strategy and defect management repository to support the cloud implementation.

The transition to a cloud services model began in 2013 with the implementation of the first module used by the States of Michigan and Illinois and will continue through 2017 when the transition to the cloud is complete. The successful implementation of cloud modules has been an incredible lesson in CM principles. We’ve applied the controls that come with a traditional CM approach with an agile mindset that values adapting and responding to change. This has resulted in an ability to deliver CM services efficiently with a high degree of quality. The need for faster turnaround is a constant pressure and drives the feedback loop for continuous improvement.