In my last blog, I analyzed the 25 point plan for Federal IT reform from Vivek Kundra, inferring the four objectives for the Plan. In this blog, I outline the solution for achieving the objectives – something we at Everware-CBDI refer to as Service Oriented Application Modernization (SOAM). Recalling that the objectives of the Plan were to (1) increase IT cost effectiveness, (2) provide better IT support to the business/mission, (3) reduce development risk and cycletimes, and (4) reduce redundancy and inconsistency through reuse, an evolutionary modernization program is the necessary foundation. The era of large, all-or-nothing software development programs is over. In its place iterative, incremental, spiral, agile and other light methodologies are taking over. The goal is Agile IT – a portfolio of IT resources that not only aligns with business change, but is actually capable of enabling it.
Agile IT is an elusive term – especially in the Federal space – almost an oxymoron. However, there is an approach that we have applied successfully that contains the core components of Agile IT. Our SOAM combines best practices from Service Oriented Architecture (SOA), Model-Driven Development (MDD) and Agile Methods. At first glance, these might seem to be incongruous, even diametrically opposed, however, we have found that each provides a balance to the others and the result is highly synergistic.
For example, Agile Methods are adept at quickly creating software to serve specific purposes. However, Agile teams often begin with little or no formal documentation (eg, requirements or architecture) – the emphasis is on producing functionality (code) quickly that can be assessed by knowledgeable and empowered users. Therein lies the beauty of Agile: the solution evolves based on rapid feedback from users into the development process. But what if you don’t have access to knowledgeable users who are empowered to make decisions about the design for the entire organization (which is typically the case for government projects)? What’s more, Agile works best with small teams of highly-skilled developers who are well versed in the tools across the lifecycle and technology stack. The result is that Agile is more difficult to scale. You can’t just grow the team size – it becomes unwieldy. And if you have multiple teams, then you have communication/coordination issues. That is where SOA comes in.
SOA is an architectural style in which solutions to user needs are composed from services (imagine that!) that are accessed via well-defined interfaces. SOA allows the solution to be designed as a collection of interacting modules that can be reused in multiple ways. There are many benefits derived from SOA – such as lower cost from not having to build functionality (again), greater consistency in the enforcement of business rules, flexibility from the plug and play nature of services, and better alignment with the business needs. But for the development process, the key advantage is the ability to divide a solution into independent modules that are well insulated from each other. Obviously, you need other teams to integrate the modules into the solutions (à la “twin track” development); but, with an overarching service oriented architecture, the objectives of each team and their interrelationships should be clear.
Of course, with SOA the number of moving parts increases dramatically. Managing them is where MDD comes in. MDD uses models to document the requirements, design the solution and services, and generate the code or other executable artifacts (eg, BPEL, business rules, etc.) that become the system. Using MDD, the solution is developed at an abstract level and translated to more detailed versions. For example, typically a platform-independent version is created that is transformed to a platform-specific version by applying design patterns and platform conventions and constraints. From the platform specific models, the code is generated that become the executables of the system. In the Everware-CBDI MDD environment, some amount of code customization or extension is required (typically 10 -20%), but the generated code is intended for human consumption and hand modification. There are two key advantages from MDD in the development process. First, much of the functionality is generated – accelerating development, reducing the coding effort and associated errors, and improving the consistency of the code base. This also allows the developers to focus on customizing the code for the users’ requirements (value-added effort), rather than on the application “plumbing” that integrates all of the components of the solution. Secondly, MDD serves a coordinating role in synchronizing the efforts across all of the development teams. Changes in one module/model are automatically rippled across all related modules (avoiding the infamous ‘I fixed the error in 5 of the 6 places where it was found’ problem). This second benefit also implies more efficient maintenance for increased agility and a lower TCO of the software.
As you can see, at Everware-CBDI we have taken the agile approach a step further – developers don’t focus on producing commodity code (well, some of them do focus on specific code extensions); the focus is on refining the models from which code is generated. This is not only more efficient, it enables the rapid turnaround associated with agile methods to be combined with an architectural and engineering based approach to developing software solutions on a large scale. As, hopefully, should be clear from the above, each of these disciplines augments the others to make the approach so beneficial. The result is greatly improved productivity, flexibility of solutions, and responsiveness to the user needs – all of which support the four objectives of the 25 point plan mentioned above.
If you are interested in applying SOAM in your environment, please contact me (dmayo at everware-cbdi dot com) or check out our web site.
Dave Mayo, Everware-CBDI
Developing Data Strategy
5 years ago
