An SOA for the Federal Enterprise
Strategically align your enterprise architecture with the President's management agenda using IBM Rational's 4+1 View Model
by Rick Murphy
| BP at a Glance |
Modeling Federal Architectures
Problem: Comply with the federal government mandate for agencies to align information systems with strategic objectives, including simplified access to services by citizens.
Solution:: IBM Rational's 4+1 View Model is used to model a services-oriented architecture that prioritizes service to citizens and meets the requirements of the federal enterprise architecture initiative.
|
As an enterprise architect, choices about what I model are as important as how I model. To align an enterprise architecture with the President's Management Agenda for Expanded Electronic Government (see "Enterprise Architecture by Legislation," Enterprise Architect Online), artifacts in a strategic information asset base should model key business drivers. This approach is more elegant than reconciling lists of standards or mapping target architectures to reference models.
Probably the most significant driver in the agenda is the call for "simplified delivery of services to citizens." Here I'll show how to better align an enterprise architecture with the President's Management Agenda (PMA), describe why services-oriented architecture (SOA) is the best approach to accomplish this goal, and provide contrasting architectural views that illustrate the significance of what I model. I do this by creating two UML artifacts from IBM Rational's 4+1 View Model strategically aligned with the requirement for simplified citizen services.
Despite being the world's largest single consumer of information technology, the U.S. federal government has failed to achieve the 40 percent productivity gains achieved by the private sector. The PMA identifies the first cause of this failure as an inability to effectively measure the value of information technology investments to citizens. The PMA states "Agencies typically evaluate their IT systems according to how well they serve agency's needsnot the citizen's needs. Systems will often be evaluated by the percentage of time they are working rather than the performance gains they deliver to the programs they support. In general, agencies do not evaluate their IT systems by standards relevant to the work the agency is supposed to do."
If a strategic information asset base contains business cases, capital planning, life cycle and human resource management documents, shouldn't it also contain artifacts that allow us to evaluate our information technology investments and show citizens and the services they receive? These artifacts range from high-level abstractions that visualize technologies for communicating with stakeholders to lower-level abstractions that allow us to bring enterprise architecture to life by forward-engineering code from the artifacts. Unfortunately, many enterprise architectures do not contain these artifacts because they model abstractions indirectly related to key business drivers.
Contrasting Architectural Views
Before I illustrate how to strategically align an enterprise architecture to a citizen-centered, services-oriented model, I present two contrasting architectural views: a capability-driven architecture and a horizontal subsystem view of an application architecture.
A capability-driven architecture models a set of technologies that support an agency's operations. Capabilities could include decision support systems, personalization and membership, document imaging, content management, or others. Capabilities are often mapped across another logical abstraction in an enterprise architecture to show their relation to a subarchitecture. Figure 1 illustrates a capability-driven architecture mapped across the tiers of a J2EE application architecture.
This agency's application architecture logically decomposes into five tiers across which I map four capabilities. Each of the tiersclient, presentation, business, resource, and integrationrepresents logical responsibilities, not physical subdivisions, in a J2EE application architecture. Each capability crosses one or more tiers. The cross-tier mapping indicates shared responsibility, and the oval shape of the capability enforces the soft nature of the division of responsibilities. Capability-driven architectures are common in enterprise architecture planning because they align well with product acquisition. In Figure 1 you can see the need to acquire a data warehouse, a portal, scanners, and a content management system.
Because capability-driven architectures don't directly communicate the value of information technology investments or the services citizens receive, we should consider them only for a supporting role in a strategic information asset base. It's not that capability-driven architectures are wrong, but there is a better choice to crisply abstract citizens and services in enterprise architecture to reflect the value of information technology investments.
Back to top
|