Everware-CBDI is engaged with a large healthcare agency to develop a modern healthcare benefits management application. The system is critical to the future of healthcare in America and has very tight deadlines for deployment. This application is large, complex and must support many stakeholders. It has three main user portals: one for providers to register and provide information about their plans, one for applicants to compare and enroll in plans, and one for government regulators to monitor enrollments and validate eligibility documents. The application is designed for multi-tenancy – complying with PII security concerns while housing the plans from multiple healthcare providers under state-specific regulations in a single system. It also has significant integration requirements with other agency internal systems as well as with external systems. This is a large-scale agile development project.
Everware-CBDI is applying our Service Oriented Application Modernization™ (SOAM™) approach to this program under the prime systems integrator and is providing architecture support, UML modeling support and code generation for the application development. SOAM combines (1) Service Oriented Architecture (SOA) to divide domains and solutions into discrete capabilities and services, (2) Agile Architecture and Development Methods for rapid delivery and frequent user feedback cycles, and (3) Model-Driven Development (MDD) to coordinate multiple concurrent teams and generate code. SOAM also encompasses Portfolio Transition Engineering to evolve capabilities from legacy applications; however, this dimension is not applied for this program because it consists of new development.
The tight deadlines for deploying the application (the first part for registering plans is already in production and the ability for applicants to sign up for plans is required to be live in October 2013) present significant challenges for design and development. Moreover, the schedule is complicated by the fact that agency officials are still interpreting the healthcare legislation resulting in a nearly continuous stream of new or updated requirements (significant requirements churn) – causing frequent refactoring. For example, nearly half-way through the project the agency decided to adopt NIEM (the National Information Exchange Model) for all external interactions. This was accomplished largely without impacting the development teams. Additionally, every aspect of the project had to be stood-up from scratch, from staffing the team to establishing the various technical environments.
For traditional development, these challenges would represent a major obstacle to delivering on time. Fortunately, our team recognized that the speed and agility of the SOAM approach could overcome many of these obstacles and proposed a solution that would meet the requirements of the program office. The first piece is the architecture driven process to identify the services from which the application is assembled. Using an agile SOA approach, the service architecture is developed incrementally on a just enough basis and grows over time with the application. The service architecture establishes the boundaries and specifies the responsibilities of each team assigned to develop the individual components. Early on the focus is on the touch points between the services (the service interfaces) and the specification of the services down to the data used and the methods provided. This solution is designed as a fully service based application (that is, there is no “free range” code in the system) which provides many benefits for development and ultimately the maintenance of the system.
This is a large project with a team of nearly 250 people. Achieving on-schedule delivery via multiple concurrent agile development teams requires co-ordination and sufficient architecture to ensure consistency across them.
SOA provides the dividing lines for the teams, which helps immensely when performing concurrent Agile Development by multiple agile teams. The SOAM agile methodology is based on SCRUM which is characterized by frequent short Sprints (usually 4 weeks in duration), along with parallel architecture Sprints to lay the groundwork. For this application, five to twelve Scrum teams (with 10 – 25 staff each) work in parallel on a continuous basis and development started almost immediately after the project kickoff. Potentially deliverable code is produced in each development Sprint, although it is typically held to be combined with other functionality for release into production.
Keeping multiple development teams synchronized presents a challenge under any circumstances; for agile development the challenge is even more daunting. The SOAM solution to coordinating across teams is based on Model Driven Development. MDD uses UML models to store and manage all of the information about the components to be developed. The models are placed under configuration management and version control, so that all changes are integrated, managed and available to other teams. This coordination would be impossible under the time constraints imposed on this application if the system were developed by hand coding each piece. The result would be chaos. MDD has an additional benefit for development: automated generation of code and other artifacts (such as documentation). For this application, Everware-CBDI’s MDD toolset, MDAgile™ is used to generate the code for all of the services (functional and data access) and extended if necessary. For much of the application, no hand manipulation of the generated code is needed or permitted – this is referred to as “Architecture Owned” code. The user interface (UI) for this system is being developed by hand, although even here some code generation is used to establish an initial framework and the required REST channel services. As a result, for the back end of the system (the services) about 80% is generated and untouched, whereas for the entire application about 50% is generated.
This project has demonstrated the viability and advantages of the SOAM approach. Due to the aggressive deadlines, coupled with the dynamic business requirements, it is highly likely that the objectives and schedule could not have been met using traditional development techniques. Some of the derived benefits include: