The Role of EA in Federal IT Development

Dave Mayo, Everware-CBDI

January 2013

“There is more value created with overall alignment than with local excellence.”                                                                                                                                             –                                                              -- Don Reinertsen

As I look back on over a decade of EA in the federal government, I must say I am disappointed in the results so far.  In my experience as an EA practitioner, I have boiled down the role of EA to two areas:  (1) Support decision-making by the business (mission) and IT leadership – EA provides a repository of information about enterprise components and their interrelationships in the form of a set of models that can be queried to gain valuable insights; and (2) Provide guidance to IT to develop & deploy assets that support the business.  The role of EA here is to help eliminate (or at least reduce) redundancy, inconsistency, and inefficiency in IT and to promote alignment, sharing (reuse) and interoperability across the enterprise.  The first of these is an analytical role along the lines of business intelligence (BI), using the EA repository as the knowledgebase.  The second is a prescriptive role to evolve the portfolio of IT assets in the strategic direction of the enterprise (based on the EA Target Architecture).

Unfortunately, EA in practice seems to have come down to two completely different things: (1) A compliance exercise to meet the evaluation criteria of OMB and GAO.  Never mind the fact that both evaluation methods are intended to get agencies to undertake “real” EA.  Agencies seem intent on doing as little as possible to score well on OMB and GAO assessments.   (2) A descriptive exercise that typically focuses on the as-is situation.  Although, “this is what we look like” does have some value, it is limited and the exercise is very costly (ask DoD about the billion dollars spent on the Business Systems Modernization program).  But the primary shortcoming across many EA programs is the lack of the intention to be prescriptive, combined with the governance to make it happen.  It is the second role and shortcoming that I wish to address here – EA should provide the foundation for application development (AD) and modernization. 

The role of EA in AD lies in transforming abstract business requirements from the problem space into concrete solutions that address these requirements – while keeping all of the capabilities and solutions synchronized to provide traceability.  The most successful organizations have adopted the SOA architectural style and apply it at all levels of this transformation.  At the highest level, it involves depicting business requirements as capabilities - discrete units of process, data and technology that allow you to accomplish something of value.  Modeling capabilities (and their dependencies) is an important part of the Business Architecture because it starts the componentization thought-process.    As you move across the problem/solution divide, these capabilities are transformed into the services or solutions that implement them. 

EA has two roles in this transformation.  The first is to establish the rules and parameters to guide the transformation. This includes setting standards, similar to building codes, that must be adopted by development teams. These include standards for development patterns, semantics and deployment platforms, among others.  While constraining, these standards actually foster creativity and accelerate development because the teams don't have to reinvent/readdress these issues – in the same way that inventors of electrical appliances don’t have to worry about how to get electricity to the appliance.  The second role for EA deals with the big picture.  It is to produce the overall (target) architecture of solutions, and the services they consume, so that the development teams can build them out – similar to a “table-top” model of a building or a community that shows how everything fits together without providing the internal detail of each piece.  The overall solution architecture as well as the EA rules and constraints are provided to the acquisition process to be incorporated into contract language that directs the design and development of solutions. The solution architecture from the EA and the services consumed by the solution are provided for incorporation in the RFPs and define what the contractors are to build.

At the Solution Engineering phase of a program, EA should provide the definitional clarity described above (denoting the components of the architecture, their definitions, boundaries, and how they interoperate) as well as more detailed artifacts to guide design and development, including reference architectures and principles that identify patterns and platforms that can/must be used by design/development teams.  An example of a very successful architecture principle at a high level is that all functionality must be service based, that all interactions will occur through the service interfaces and that all service interfaces must be externalizable.  Amazon used this principle to implement all capabilities as services and in the process created a business platform to integrate all internal and external offerings.   (ref. Amazon;  see Steve Yegge’s Rant, 2011).

During design and development, the EA team should perform compliance reviews at appropriate stage gates to determine that the program is building out the components of the architecture and is complying with the rules and constraints.  Today, most EA programs review development progress “from an architectural perspective”.  But without a model to compare it to, the results are weak at best.  In many cases, development programs claim compliance with the EA because they can “map” their application to the Reference Models, rather than demonstrating that they are actually building out a part of a segment/domain architecture that will be reusable by others.

  

The bottom line is that AD should operate in a manner like most construction industries – develop an architecture and then build it, preferably by assembling solutions from pre-built components.  If the architecture is service based, it will be modifiable on an incremental basis and thus should stand the test of time.  If the solution components are specified and modeled in a rigorous manner, then automation (eg, code generation) can accelerate the process and facilitate the maintenance/enhancement process. 

This is the concept that we at Everware-CBDI have based our core competencies on.  We call it Service Oriented Application Modernization (SOAM) and it bridges EA and solution development.  SOAM consists of four disciplines: SOA, Agile Development, Model Driven Development, and Portfolio Transition Engineering.  This approach rapidly evolves the suite of IT assets to a set of rationalized, reusable components that can be reconfigured to address new challenges.   In the process we are able to align development results with the business goals and objectives.