Enterprise Architect  
 
 

Align Your IT Initiatives With FEA Reference Models
Discover how the FEA framework can help you measure the effectiveness of your IT investments.
by Brent Carlson

December 1, 2004

Most of you are probably familiar with the old joke punch line that goes something like this: "We're from the [pick your favorite government bureaucracy], and we're here to help," implying that help via government involvement is the last thing you should expect. Although you might find this true in some aspects of life, a federal government initiative called the Federal Enterprise Architecture (FEA) promises to help IT organizations—both inside and outside of government—establish a reference structure across their existing applications and their new business process–centric initiatives (see "Enterprise Architecture by Legislation").

What is the FEA?
To quote from the Federal Enterprise Architecture Program Management Office (FEAPMO), "The FEA is a business and performance-based framework to support cross-agency collaboration, transformation, and government-wide improvement. It provides the Office of Management and Budget (OMB) and the federal agencies with a new way of describing, analyzing, and improving the federal government and its ability to serve the citizen." The OMB leads the FEA initiative. The OMB Circular A-11 Section 300, "Planning, Budgeting, Acquisition, and Management of Capital Assets," establishes a requirement of all federal agencies to describe and align their major IT projects in the context of the FEA's constituent reference models, which are defined as follows:

  • Performance Reference Model (PRM), which focuses on measuring the performance of major IT investments and their contribution to program performance.
  • Business Reference Model (BRM), which organizes and describes the day-to-day operations of the federal government.
  • Service Component Reference Model (SRM), which classifies business and application services and components within horizontal and vertical service domains to support discovery and reuse of those service and component assets.
  • Data and Information Reference Model (DRM), which, when defined, will describe the data and information structures that support federal program operations.
  • Technical Reference Model (TRM), which describes the standards, specifications, and technologies to support the construction, delivery, and exchange of services and components.

Structurally, you can view the Federal Enterprise Architecture's reference model layers as follows (see Figure 1):

  • The PRM provides a vehicle for executive and management oversight of IT initiatives.
  • These initiatives are delivered through applications composed of components and services organized under the SRM and aligned with one or more business capabilities defined by the BRM.
  • Each component and service, in turn, is supported by technical and information elements selected from the TRM and DRM.

Why Should I Care?
You might be thinking, "Well, that's interesting, but I don't work for the federal government, so what does this information have to do with me and my job?" Naturally, if you don't work in a federal department or agency, the specific information contained within the BRM won't have much relevance to your IT environment, but the principles defined by the FEA across its various reference model layers are certainly relevant to any IT organization. In addition, you can directly apply the PRM, SRM, and TRM to your organization's enterprise architectural efforts, either intact or as a starting point for your own organization-specific reference model development. Let's take a more in-depth look into the PRM, SRM, and TRM to explore their relevance to your organization.

The Performance Reference Model
The FEA's PRM establishes a framework for measuring the effectiveness of IT initiatives across six major measurement areas:

  • Mission and business results specify the key strategic objectives of the organization—a primary means of driving high-level business objectives into IT projects. These business objectives should be directly reflected as elements of the associated BRM.
  • Customer results define the qualitative customer outcomes produced by an agency/line-of-business initiative (for instance, the filing process for taxpayers electronically filing their tax returns is simple and results in a good customer satisfaction rating). Aspects such as customer benefits, coverage, timeliness and responsiveness, quality, and accessibility are part of this measurement area.
  • Processes and activities deal with the quantitative processes supported by an agency/line-of-business initiative (such as electronic filing of federal tax returns), measured by aspects such as productivity and efficiency, cycle time and timeliness, quality, security and privacy, and management and innovation.
  • Technology describes and measures the direct IT-related activities resulting from an agency/line-of-business initiative. Often described as the "-ilities" associated with an IT project, this area covers aspects such as quality, efficiency, reliability, availability, financial effectiveness, and information management.
  • Human capital measures the effective use of personnel within the initiative; this area is not fully specified in the current version of the PRM.
  • Other fixed assets measure the effective use of non-IT assets within the initiative; this area is not fully specified in the current version of the PRM.

You shouldn't necessarily tailor these measurement areas to represent agency-specific (or, in the commercial arena, line of business–specific) goals and objectives as specified by measurement categories and their underlying measurement indicators. As you can see, any organization can use the overarching framework established by the PRM to define broadly applicable and measurable goals by which any IT initiative can be evaluated. In effect, the PRM can serve as the vehicle by which executive and management commitment to an enterprise architecture initiative is communicated, and its effect on the organization's IT project development process is enforced.

Service Component Reference Model
The FEA's SRM lays out the major business-independent and cross-domain capabilities required by IT applications. Its objective is to establish clear mappings from these capabilities to potentially reusable services and components that already exist or can be implemented or acquired within the agency or enterprise. The SRM defines these service domains:

  • Customer services describe IT services directly available to customers, such as customer preferences, customer relationship management (CRM) capabilities, and customer-initiated assistance.
  • Process automation services specify services that support the automation (either full or partial) of processes and related management activities, including tracking, workflow, routing, and automation activities.
  • Business management services define IT capabilities required to support the management and execution of business functions. This domain area addresses aspects such as process, organization, supply chain, and investment management.
  • Digital asset services address the generation and management of electronic media the organization produces. Services covered by this area include content, knowledge, and document and records management.
  • Business analytical services provide capabilities that support information processing for presentation to management and executive decision makers. Services such as statistics generation, business intelligence, reporting, and visualization are part of this domain.
  • Back-office services support enterprise planning activities such as data management, human resources, asset management, financial management, and workforce management.
  • Support services provide cross-domain functions such as authentication, forms processing, collaboration, search, and communication.

As you can see from the above list, the capabilities described by the SRM are applicable to any enterprise, and the underlying service and component assets supporting these capabilities can and should be organized for easy discovery and retrieval by mapping their functions against SRM elements.

Technical Reference Model
The FEA's TRM establishes and categorizes the technical landscape upon which applications and their underlying components and services are defined, designed, implemented, deployed, and maintained. It consists of these service areas:

  • Service access and delivery describes the standards and specifications by which services and their underlying components deliver functional capabilities for use in application development and other means of access. Areas addressed by this domain include access channels (Web, wireless, etc.), delivery channels (Internet, intranet, peer to peer, etc.), service requirements (authentication, hosting, etc.), and service transport (networking and underlying transport mechanisms).
  • Service platform and infrastructure establishes the server, network, and client device environment upon which applications, services, and components are deployed, as well as the software engineering processes by which these software development assets are produced and maintained. Specific topics addressed within this area include support platforms (servers and client platforms), database and storage, delivery servers (Web, media, portal, and application servers), hardware and infrastructure (physical server, client, and networking devices), and software engineering (IDEs, SCM, and processes and models).
  • Component framework defines the languages and mechanisms by which applications, services, and components are developed. This service area is subdivided into business logic (programming languages), data management (database connectivity and reporting), data interchange, presentation (user interface and other media interface mechanisms), and security.
  • Service interface and integration lays out the approaches by which services can be assembled into applications and otherwise integrated. This service area addresses topics such as integration mechanisms (MOM, ORBs, transaction processing), interoperability approaches (data formatting, validation and transformation), and interface delivery (service discovery and interface description).

The FEA TRM not only defines these service areas but also establishes knowledge assets that directly reference and define the various standards and specifications by which executable assets are developed and deployed. It's quite obvious from the above list that the TRM is broadly applicable to any IT organization, whether that organization's primary responsibility is to deploy, integrate, and manage packaged applications, develop custom line-of-business applications, or mix integration and new development.

How Do I Get Started Using the FEA?
At this point you're convinced that the FEA can help you in getting your in-house enterprise architecture initiative underway, or giving your already-established initiative a big jump-start. Where do you go from here? There are a few techniques you can use to apply the FEA to your own organization's architectural activities, including:

  • Reference architecture definition
  • Software development asset inventory
  • New initiative evaluation and refinement

Reference Architecture Definition
The FEA's SRM and TRM provide a useful and complete coarse-grained pair of reference architectures your organization can use as is or extend. Typical TRM extensions include defining a more detailed prescriptive technical architecture that lays out specific technical choices made by the architecture team (such as J2EE vs. .NET, preferred or mandated IDE, authentication and SSO architecture, and supporting technologies and applications), often accompanied by a reference application architecture with reference implementations for key architecture elements (typically tiered in nature and exploiting a component-based development model with overlaid services to support application integration and orchestration). You can use the SRM as is in the asset inventory and new initiative evaluation phases of enterprise architecture execution.

Although it is not directly applicable to nongovernment organizations, you can use the FEA BRM as a model to develop your own business reference architecture. A coarse-grained approach that identifies major functional subdomains as components with underlying services grouping major functional capabilities with those functional capabilities identified through business process analysis can be an effective approach for developing and documenting an enterprise business reference model.

Once a business reference model (see Figure 2) is in place and placed side by side with your SRM and TRM, you can proceed to the next stages of enterprise architecture development: software development asset inventory and new initiative evaluation and refinement. Keep in mind that you can and should define your BRM in an incremental fashion, focusing on those areas that require immediate attention because of rapid business process change or competitive advantage.

Software Development Asset Inventory
Selectively aligning your existing applications, services, and components against the BRM, SRM, and TRM serves both to give your organization better understanding of its current IT landscape and to determine which existing elements you should continue to use in new initiatives (either implemented using modern component-based and/or service-oriented techniques, or encapsulated to expose existing capabilities into the newly defined application architecture).

You should map your existing line-of-business software development assets to the overarching BRM functional elements that they support. You can then populate the SRM with designated packaged and internally implemented components and services that provide cross-application functionality to the enterprise. Depending on how far you have specified your TRM and associated application architecture, you might have already completed the technical asset specification and mapping process, or you might have a few gaps to complete to fully describe your technical environment. Again, don't try to map every single application currently deployed in your environment. Instead, pick and choose the areas that will have the most impact in moving your organization's business objectives forward.

New Initiative Evaluation and Refinement
At this point, you can use your existing reference models and mapped assets to evaluate new IT initiatives. Requirements flowing from business process definition to BRM help you to select and identify existing assets that can support the initiative and also identify functional gaps you should fill. SRM-mapped assets support specific cross-domain needs such as reporting, workflow, and CRM support. And, your TRM and application architecture and associated reference implementations describe the design, implementation, and deployment approaches your development teams will use in executing the initiative. All of the above activities can occur under the review and evaluation processes specified by your PRM or equivalent evaluation and rationalization techniques.

Delivering Your Enterprise Architecture
Once you've established an enterprise architectural baseline going forward, you need to make that architecture relevant to the broader IT organization. Many a fine architecture has foundered upon the rocks of static content and inadequate delivery tools and techniques.

Processes such as well-defined review checkpoints throughout the IT project development lifecycle (in particular, at the requirements definition and design-complete phases of a project) can help to ensure that architectural content and supporting software development assets are being used effectively. Software development asset management tools (more formally referred to as asset metadata repositories or libraries) can also provide an environment for dynamic and interactive delivery of enterprise architecture content, as well as long-term traceability of project-specific asset usage to enable effective impact analysis and change management going forward. When considering an asset metadata library, deep tool (IDE) integration, user collaboration (notifications, subscriptions, and discussion forums) capabilities, and flexibility to support multiple technical environments should weigh heavily in your decision-making process.

Ultimately, executive and management support is crucial to the success of any enterprise architecture initiative. With that in mind, the FEA can serve as a useful framework for your organization as it executes the objectives defined by that executive and management commitment.

About the Author
Brent Carlson is vice president of technology and cofounder of LogicLibrary, where he drives the development and delivery of the company's products. He is a 17-year veteran of IBM, where he served as lead architect for the WebSphere Business Components project and held numerous leadership roles on the "IBM SanFrancisco Project." He is the coauthor of two books: SanFrancisco Design Patterns: Blueprints for Business Software (Addison-Wesley, 2000) and Framework Process Patterns: Lessons Learned Developing Application Frameworks (Addison-Wesley, 2002). Carlson holds 16 software patents, with eight more currently under evaluation.