BRM Draft01062003v1.doc

Extending and Expanding the Use of the Business Reference Models for Business

Design and Strategic Improvement

Industry Advisory Council Enterprise Architecture Shared Interest Group

January 2, 2003

This white paper is IAC EA SIG DRAFT and has not been approved by IAC.

Business Reference Model IAC EA SIG 01/07/2003

Preface

The Federal Enterprise Architecture Business Reference Model (BRM) in intended to be used for program and project business case development, and within the Enterprise Architecture activities. This paper recommends that it be used in defining cross-government business line architectures, guiding business process improvements and strategic improvements that cut government organizational boundaries.

The Federal Enterprise Architecture has defined a set of Lines of Business that can be used for defining business lines between and across Federal, State, and local government along with business partner communities. Development of an extended business process that integrates collaborative processes and information sharing along the business line architecture introduces many challenges. Some of the challenges include the management and governance structure, overcoming organizational inertia, along with the technical challenges and the need for cross-organizational financing and getting all to a “win-win” situation.

Taking on such challenges is difficult but is desperately needed. It is needed to transform government into e-government with the electronic delivery of services. But it is needed to fundamentally break down the functional, information, and time stovepipes between government entities and to allow the information sharing needed for Homeland Security. While the BRM has specific value and context within the Enterprise Architecture (EA), to tie in Agency IT investments, there are a number of complementary uses that extend it beyond the traditional aspects/outcomes of EA. The above areas are four areas where we see great opportunities to further extend the reach of the Federal BRM and its potentials for transformation of the Federal Government and its connection and integration with State and local government. This paper provides an industry perspective and specific recommendations on extending the BRM to improve government processes.

This white paper is IAC EA SIG DRAFT and has not been approved by IAC.ii


Credits

Contributors to this paper were: Dan Twomey, Altarum; John Dodd, CSC; Mike Tiemann, AT&T; Dave Mayo, Everware; Sandra Tuck, CSC; Elizabeth Cox,

BearingPoint; Susie Adams, Microsoft

This white paper is IAC EA SIG DRAFT and has not been approved by IAC.iii


Table of Contents

1 Introduction and Objectives........................................................................................11.1 Objective..............................................................................................................31.2 Audience..............................................................................................................31.3 Acknowledgements..............................................................................................31.4 References:..........................................................................................................3

2 Business Reference Model..........................................................................................42.1 What is the Business Reference Model (BRM)?.................................................42.2 Guidance to Make the BRM Transition Successful..........................................102.3 Business Line Architecture Challenges:............................................................102.4 The Relationship between BRM and PRM.......................................................112.5 Why use BRM-PRM: Mandates and “What’s the Benefit”!.............................11

3 How to use BRM- Creating and Evolving Business Processes...............................123.1 Using the BRM..................................................................................................133.2 Identifying and Using Business Line Channels.................................................153.3 Facilitating Business Line Architecture Process...............................................163.4 Creating Business Process Models....................................................................18

4 Conclusion................................................................................................................215 Key Facet Descriptions.............................................................................................25

5.1 Stage of standard e-government service delivery..............................................255.2 Goals met by the business service pattern.........................................................26

List of Figures

Figure 1: Business Analysis Activities Linked with Reference Models.............................2Figure 2: BRM Relationship Diagram.................................................................................5Figure 3: BRM – Core Diagram and Meta-Diagram...........................................................6Figure 5: Link Between BRM and PRM...........................................................................11Figure 6: Steps to Use the BRM and Link to Business Analysis and Improvement.........13Figure 7: Identifying Business Line Channels...................................................................15Figure 8: Business Line Architecture Process...................................................................17Figure 9: Operationalizing Business Process Models.......................................................18Figure 10: SBA One-Stop Architectural Concept of Operations......................................19Figure 11: Recommendations for Business Analyst Support to Transform Government. 23Figure 12: Conceptual Picture of Business & Analytical Portal.......................................24

This white paper is IAC EA SIG DRAFT and has not been approved by IAC.iv


1 Introduction and Objectives Today’s business environment for the Federal Government is dramatically different from the landscape of the last decade. Many external factors are forcing government agencies to become more open with and increasingly integrated in both business processes and technologies with other agencies at all levels of government and with commercial industry stakeholders, partners and customers/clients. As a result, government agencies are also increasingly finding that business processes, procedures and to some extent rules are similar to or have much in common with the same processes in other agencies as well as entities in the commercial and not for profit sectors. Government policy and decision makers are beginning to take advantage of the knowledge and experience gained in these other similar organizations. This vertical (with enterprises to aggregate information) as well as horizontal integration (across agencies and lines of business) is taking place in both functional and technical areas, meaning that people and systems are sharing information more frequently and with much greater continuity of mission, function and purpose than in the past.

At the highest level, the Federal Enterprise Architecture Program Management Office has developed the master set of business functions and processes for the Federal Government, called the Business Reference Model (BRM). Its purpose is to codify, at the highest level, the entire Federal Government’s “Lines of Business and its Services to the Citizens”, across the full range of functions performed. The BRM provides taxonomy, or logical grouping, of functionality without regard to performing agency or agencies. As a top-level model, the BRM does not address the step-by-step business processes that are performed under the responsibilities and legislative authorities assigned to each of the individual agencies. However, it does define approximately 137 sub-functions within the major business areas and functions. These are established without consideration for organizational agency boundary lines so that the full scope of cross-functional activities are included, but the agency-to-agency redundancy is eliminated or normalized.

The goal of this document is to define the approaches to and benefits of incorporating the BRM into an agency’s modernization and business process improvement efforts. In the pages that follow, we recommend a Business Process Integration approach within the context of key cyclical government activities, such as budget formulation, program and project scheduling, and other management initiatives. We also identify issues needing to be resolved to work from the BRM in a federal agency, with special consideration placed on contrasting these issues with comparable commercial initiatives.

This paper and the ideas in it are built around the starting points of the Business Reference Model (Version 1.0) and designed to contribute to the update the Federal Enterprise Architecture Framework (FEAF) from Version 1.1 to 2.0. The focus is on the business analysis and the business centric integration into the Enterprise Architecture teams within the Department or Agency and within Business Line Architecture teams and communities across federal agencies as well as across multiple levels of government. There are a set of business analysis activities that must be conducted and a set of reference models of the Enterprise Architecture and Business Line Architecture that must be linked together. The EA activities are no longer an IT function but are necessary for strategic improvement. The business analysts must learn about EA and

This white paper is IAC EA SIG DRAFT and has not been approved by IAC.1


their business analysis activities must be integrated into Enterprise Architecture Framework(s) and links must be established with State and Local organizations such as NASCIO.

The Business Analysts and leaders at all levels must participate in EA Activities and Business Line Architectures programs. An initial linking of reference models and Business Analysis Activities are shown in Figure 1. The primary focus of the business analyst is the creation of business models for the “as-is” and “to-be” business process. The business processes are driven by the desired strategic changes. The business cases provide financial analysis that includes the required and expected performance levels.

Figure 1: Business Analysis Activities Linked with Reference Models

Industry experience with business modeling, business patterns and value analysis provides much of the basis for the analysis and recommendations contained in this paper. The sidebars (to be added) present examples of techniques and enabling technologies that support the concepts discussed, including “prototyping” key business service patterns, building parametric and system dynamic models, and the application of visual business process languages. These approaches can identify business process integration levels along business lines and channels that cross governmental boundaries.

Creating these crosscutting business line architectures will require a significant amount of facilitation, sponsorship and stewardship within the Federal Government (involving perhaps the FEA-PMO, the CIO Council and its Committees, NASCIO and the President’s Management



Council). Further, many “leaders” will need to be identified and cultivated throughout multiple levels of Government to shepherd the transition to a business line approach that crosses traditional boundaries. Many of the steps described in this document have been done in pieces in government and in industry but further work must be performed to bring them together in one place.

1.2 ObjectiveAssist and provide guidance to agency enterprise architects, business and program analysts, and various supporting contractors, to design, build or evaluate processes, programs and projects within the organization in relation to the Federal Business Reference Model and in the context of the other four related Federal Enterprise Architecture Reference Models.

1.3 AudienceBusiness and Program Analysts, Agency Enterprise Architects, Budget Analysts, FEA-PMO and OIRA at the OMB, CIO Council, AIC and IAC and its members with professional interest in Business Modeling and Enterprise Architecture.

1.4 Acknowledgements James Champy- Perot Systems Howard Smith- CSC

1.5 References:1. Haim Kilov; Business Models: A Guide to Business and IT, Prentice Hall, 20022. Howard Smith and Peter Fingar, Business Process Management-The Third Wave: The

breakthroughs that redefines competitive advantage for the next fifty years, 2003

3. Janis Putman, Architecting with RM-ODP, 20014. James Champy, X-Engineering the Corporation: Reinventing Your Business in the

Digital Age, 2002

5. www.bpmi.org- Business Process Management Initiative

6. www.ebpml.org- Enterprise Business Process Management Language web site 7. Enterprise Architecture Planning, Steven Spewak and Steven Hill. A Wiley-QED

Publication. 8. Constructing Blueprints for Enterprise IT Architectures, Bernard H. Boar, John Wiley

and Sons, 1999.9. The Federal Enterprise Architecture Framework, Chief Information Officers Council,

Version 1.1, September 1999.10. (http://www.cio.gov/Documents/fedarch1.pdf)11. Architecture Alignment and Assessment Guide, Chief Information Officers Council,

Version 1.0, October 2000.12. (http://www.cio.gov/documents/arch_align_assess_oct_2000.pdf)13. A Practical Guide to Federal Enterprise Architecture, Chief Information Officer Council,

Version 1.0, February 2001. (http://www.cio.gov/Documents/bpeaguide.pdf)


http://www.cio.gov/Documents/bpeaguide.pdf

http://www.cio.gov/documents/arch_align_assess_oct_2000.pdf

http://www.cio.gov/documents/arch_align_assess_oct_2000.pdf

http://www.cio.gov/Documents/fedarch1.pdf


14. E-gov Enterprise Architecture Guidance (Common Reference Models), Chief Information Officers Council, Version 2.0, July 2002

15. (http://www.cio.gov/documents/E-Gov_Guidance_July_25_Final_Draft_2_0a.pdf)16. Information Technology: Enterprise Architecture Use across the Federal Government

Can Be Improved, United States General Accounting Office, Report to Congressional Committees, GAO-02-6, February 2002. (http://www.gao.gov/new.items/d026.pdf)

17. C4ISR Architecture Framework, Department of Defense, C4ISR Architectures Working Group, Version 2.0, 18 December 1997. (http://www.c3i.osd.mil/org/cio/i3/AWG_Digital_Library/pdfdocs/fw.pdf)

2 Business Reference Model

2.1 What is the Business Reference Model (BRM)? There are three primary elements of the BRM that are essential to its being understood and used. The first is the core model -- the descriptive picture or diagram and constructs of relationships as shown in Figure 2. The second is the process that is used to explain the relationships as shown Figure 3(i.e., the meta-diagram) to bound and scope the parts or components. The third is the set of definitions that detail all of these parts in a common language, in such a manner that they are fully normalized and validated. The model elements are the pieces that agencies compare against while the process or methodology underpinning of the model forms the guidance for its growth and maintenance. Many of the Federal IT Investments have not been linked to the mission/business value they should support, because of a lack of proper Enterprise Architecture efforts or methods.

EA problems include the lack of solid linkages to a business case and the lack of visibility into the commonalities of processes and solutions. Because the EAs produced by agencies have typically not crossed organizational lines, the business models have produced unnecessary redundancy, hampered consistency of communication, and generally prevented the integration of business processes across many organizational or legislative lines. “Modernization” or transformation initiatives where a business-value first approach is emphasized have generally been more successful whether in government or business.


http://www.c3i.osd.mil/org/cio/i3/AWG_Digital_Library/pdfdocs/fw.pdf

http://www.gao.gov/new.items/d026.pdf

http://www.cio.gov/documents/E-Gov_Guidance_July_25_Final_Draft_2_0a.pdf


Figure 2: BRM Relationship Diagram

Enterprise Architecture, to be more than just IT Architecture with an invalid label, requires a change in focus, starting with defining the business layer or architecture. For the Federal Enterprise Architecture this is represented by the BRM and its complementary Performance Reference Model. The business processes within the BRM and their agency versions are comprised of services designed to provide value to citizens, internal government customers, or related business partners. The value provided by each process must be measured. These measures can assist an organization in meeting its goals or, where changes are needed, new “achievement” goals and maintenance goals may be needed. Integrating and aggregating the goals and measures of performance is the purpose of the PRM. The integrated use of the BRM-PRM is discussed in this paper with more detail provided in a companion paper.



Figure 3: BRM – Core Diagram and Meta-Diagram

The BRM is focused on the virtual integration of business processes around key topic areas. The BRM is a “template” of a “to-be” state in the terms of the Federal Enterprise Architecture Framework and must be adopted by each organization by referencing and indexing agency initiatives and investments to the BRM areas and sub-functions. Figure 3 establishes the taxonomy of government functions (primarily the non-Defense/ Intelligence sectors). It also is



integrated with the Performance Reference Model. An explicit extension to the BRM are the access channels to the citizens, other government organizations, and mission stakeholders which create the means to tie into their various BRM’s (whether explicit or in the case of customers, implied in how they approach the various business functions).

Industrial Engineering Related Reference Models

The RM-ODP approach and other frameworks such as the Purdue Enterprise Reference Architecture (PERA) come from the industrial engineering-manufacturing engineering perspective. They have developed an Enterprise Architecture and Enterprise Engineering approach that define what elements of the manufacturing, distribution, and other processes are done with automation and that are done manually. The human functions are described along with the expected impacts on the roles, responsibilities, skills, and knowledge. These models and the “human” change reports have been very useful in both understanding the return on investment and in staff planning, as well as in presenting the changes to Management-Labor Boards that are involved at the plant and corporate levels. Many of those same principles may allow the business process change impacts to be determined and can be applied to significant changes efforts such as e-government transformation and Homeland Security. .

The question is what an agency should do to apply the BRM in its initial EA efforts. We suggest the initial steps include:

1. Identify the BRM elements that the organization supports, participates in or has a specific mission in (also identify any missing ones the BRM may not cover).

2. Create an appropriate list of business areas and business functions within your Enterprise (or the business lines) with specific definitions and related supporting information (linkages to laws and regulations, linkages to agency specific strategic goals, for example).

3. Evolve (through the applied agency EA process) a set of to-be business process models and related business modernization or improvement plans. For example, one means to achieve this would be by following the business process integration approach presented later in this paper.

A set of Enterprise Models (Business areas and business functions) must concurrently and iteratively support processes evolving - normally following the annual budget and performance tracking cycle. This cycle provides the context for the agency EA transition plans. As such, the business processes change to meet new achievement goals, to take advantage of new enabling technologies, to link to new partners and stakeholders (within the Federal and/or at the state and local governmental layers), or to meet requirements from new customers. The BRM and set of increasingly common agency enterprise models will affect all aspects and levels of the government. Aggressively implemented, all parts of the government can be positively impacted by the improvements to quality, costs or cycle times that will occur. Table 1 depicts some of these impacts and the related constraints or barriers to their achievement. It is not intended to be comprehensive but rather illustrative.



2.1.2 Sample Roles and Business Activities with Impacts and ConstraintsRole Activity Positive Impact ConstraintsEnterprise ArchitectureProgram

Stronger involvement of the business/mission experts and management.

The BRM (and PRM) compel greater business involvement in the EA development and they become increasingly relevant as agency transformation plans rather than justifying and supporting IT plans. EA’s are not just for the CIO to be concerned with and create.

Getting the attention of the business owners and thinking past the “functional stove” pipes requires at a minimum leadership focus and attention or at maximum direct involvement.

Department Leaders

Must be actively involved in the business modernization or transformation using the EA as a mechanism for change.

EA can become the overall business process blueprint for change with significant business modernization efforts being done within the EA (top down or bottom up. EA metrics will be translated to business improvements

IT oriented EA staff may not be able to communicate effectively in business terminologies or relate IT to business metrics.

Governance The EA is utilized more effectively in the context of budget and resource allocation decisions.

The EA becomes a major management mechanism to ensure that investments fit into the strategic business objectives and the projects are measured on business results.

Both factions within the enterprise, the rogue and independent IT and business leaders will try to get exceptions or exemptions to bypass the new processes.

Common Models and Terminologies

The EA will be a leveler across the agency or enterprise or across the government making it much easier/legitimate to consolidate processes and systems.

Common models increasingly linked to specific services and services components are developed and implemented. These models extend the EA reach and range and improve the efficiency of the architecture processes.

The up front efforts to define the common models and reusable components to a consistent standard and to get buy-in throughout a particular business line and sub-function takes significant focus, management, stewardship and effort.

Human The EA when used The relationships between the The resultant



Resources as the central enterprise design repository can identify areas where human resources are needed and where new or different skills will have to be developed or acquired.

organization structures, the business rules, the staffing resources and the technologies used become explicit and therefore cannot be fabricated or obfuscated. This means that a wide array of decisions can be made to handle the human resource issues resultant from any business process changes.

impacts could be such that some sets of employees may not be able to be retrained or given alternative roles commensurate with their expectation and or seniority. Options may not always be broadened.

IT LeadershipCIO, CTO, Chief Architects

The EA becomes a major IT program project initiator linking all the various initiatives and setting the specific management agendas for the CIO, CTO and Chief Architect.

The CIO, CTO and Chief Architect (as well as others in IT) will have a clear picture of their near term objectives with the assurances that the strategic goals are not being compromised. There is a clear linkage from the technologies to the various business models being implemented.

The EA itself can become overly unweidly to manage and update such that it loses its positive value as an organizing and directive mechanism within the enterprise. The IT management must guard against this happening.

Organizational Improvements Realignments

Changes to organizational structures will present themselves as logical extensions of the EA based on information developed.

Realignments in organizational structure can create additional efficiencies and increase effectiveness as well as allow resource reallocations.

No all of the possible and seemingly logical restructurings will be feasible or prudent especially in areas where various sensitivities may exist.

Customer Advocacy

The focus of all or most of the initiatives resultant from the EA can be oriented towards customer advocacy. This would include all customers of the Federal government.

Increased customer advocacy will result in increases in the quality, quantity or timeliness (or combinations thereof) of services and products delivered to citizens, organizations, businesses and other entities.

Internal efficiencies and areas where no real customers exist may lag or even worsen because of the effect of lack of focus.

Operational Values

The EA can be directly used in the

The use of the EA in this manner will go a long ways

There may be desired operational



management and operations of the on-going infrastructures and existing capabilities. Incremental enhancements can be implemented with surety of interoperability and compatibility

towards rectifying errant positions that EA analyses and modeling is wasted effort, time and money. Increasingly checking the EA will be an operational change prerequisite and updating it a requirement.

enhancements and other implementations which will be outside the current EA and may be negatively impacted by deferral until an update occurs. Other similar impacts may result from misalignment or non-standard

A key value of the business reference model is its focus across government creating a common mapping that not only supports the budget analysis and business case processes but goes beyond that to act as the catalyst to breakdown the functional silos. It will facilitate stepping back and focusing on the citizens need for service around a given business area. The 33 business areas have been reviewed extensively with large and small agencies but only the specific use of the model wile ensure that it is all encompassing and applicable across the entire governmental spectrum and like many things of continuing value it will change.

2.2 Guidance to Make the BRM Transition Successful Even as the initial BRM was being rolled out and updates to BRM 2.0 are in process agencies have deployed it and provide success stories and lessons learned. We have examined the early use of the BRM as applied to Business Processes, metrics, and business case efforts by the Department of Education, the Environmental Protection Agency, the Department of Labor as well as plans underway by the Internal Revenue Service to use the BRM. Other notable uses of the BRM include Department of Homeland Security because of the close ties to the FEAPMO will be designing its EA around the BRM. (Sidebars needed from Early Adopters).

Related industry initiatives that cross organizational boundaries include recent Industry initiatives within areas such as Health Care. The Concurrent Engineering and Virtual Enterprise Projects within Aerospace, Automotive and a series of European industry initiatives have provided insights into the Extended Enterprise. Also the use of Trading Partner networks such as Rossettanet and Verticalnet have identified useful processes and trends. These collaborative interactive processes and the trusted relationships fit well the concepts of a business line architecture that crosses government boundaries. Many of the concepts were derived from those experiences enumerated in a set of references and cases studies listed in the references.

2.3 Business Line Architecture Challenges:

2.3.1 The business line architecture introduces many challenges such as: 1 Defining a Business Line Process that the Federal, States, and Local government agree on2 Breaking the stove-pipe mentalities and taking a Business Line approach3 Sponsorship and Funding that crosses organizational boundaries



4 Coordinated Planning across multiple organizations5 Fostering trust and participation across a business line e.g. building Business Line Partner

Community6. Agreement on information technology and integration standards

2.4 The Relationship between BRM and PRMThe reference models, PRM, BRM, SCRM, DRM and TRM are a set and ultimately are intended to be used together to influence the ways in which policy is formulated, resources are applied and process are implemented across all levels of Government both horizontally and vertically. The approach is significantly different enough from the core body of knowledge within Enterprise Architecture that there are bound to be some new lessons learned.

The tight coupling of the PRM with the BRM, as presented by the OMB, begs the question of course. Why have two models? Why not follow the common knowledge of the profession that says the performance metrics are core to establishing the Business architecture layer and therefore should be consolidated into the BRM (or at least identified as a subcomponent thereof). The remainder of the models link to the BRM but are distinct from it.

Figure 5: Link Between BRM and PRM

2.5 Why use BRM-PRM: Mandates and “What’s the Benefit”! There are a number of mandates and directives including expectations that the business cases and budgets be linked to an Enterprise Architecture.



The new e-government 2002 legislation has strengthened the mandates within the Clinger-Cohen Act as defined in the OMB A-130, A-11 guidance. A business driven enterprise architecture process can be drive a stronger citizen centric approach that will improve the efficient and effective agency operations. But one of the greatest benefits is to breakdown the organizational stovepipes and provides a consistent delivery of services. Organizational stovepipes can take many forms from functional isolation and redundancy to data islands that result in information not be shared or identified as existing. There are also timing stovepipes where information is updated and delivered at different frequencies. Using the BRM as a “reference” target that everyone must align with can act as a Unifying Foundation for cross-agency and cross government information sharing and collaborative cross-organizational process interactions. The relationships are shown in Figure 5 BRM Relationship Diagram.

The business process models and management approaches can provide a strategic and customer focus to your initiatives. This new business process focus allows changes to be managed from the citizen standpoint. It can allow you to present your business case in terms that Congress and your advocates can understand. It allows you to organize your functions and to link to related functions of the government around the citizens interest, It allows the delivery of customized information and access around a business communities needs. It allows e-service delivery to be integrated into your enterprise and not treated as a standalone activity. Coupled with web technologies such as portals and one stops will allow the citizens to transition across organization boundaries transparently.

The BRM-PRM operationalizes and makes visible the President’s Management agenda (PMA) and other strategic directives within your organization. Through mapping of the BRM-PRM a change in the business process can from a strategy or an opportunity for improvement from the government staff or contractor involved organization that can be linked to a goal. As agencies link to the BRM and identify common-shared processes, joint improvements can be more systematically made. Today there are many joint initiatives that have been identified but in an ad-hoc fashion.

The lines of business and the service areas can be treated as portfolios to manage and improve value around. Portfolio management by business line can allow the many competing priorities to be put into perspective using a return on equity approach. The lines of business can have their own strategic improvement plan where a continuous stream of incremental changes can create a revolution. The business line can research and experiment a little, share the implementation, and watch the value to the citizen and business community grow. The business reference models will be the basis of budget estimates but can be used to discover opportunities for improvements, to monitor the performance, to optimize the service delivery, and to analyze the benefits for budget submissions.

3 How to use BRM- Creating and Evolving Business Processes

The BRM model must be tied to business processes at a level of detail such that real change can happen. Each business process can be completely within one organization or more likely it can span a number of organizations. The BRM will let all organizations map or compare to a common baseline - a “reference”. It is a high level Federal Enterprise Model that can be used to



evolve business process specifications and designs that will allow commonality of processes that have the same or similar customers and focus.

It provides a common top tier enterprise architecture business layer that can be linked to a series of services, business line channels, components, with shared or commonly recognized performance goals. The business processes will be developed in an iterative fashion but it is critical that a consistent “terminology” and approach be defined. The Federal Enterprise Architecture Framework and the related set of guides need to be updated, expanded and inculcate new and emerging standards for business process design notations and business process analysis and modeling language and terminology.

3.1 Using the BRMAlso the organizations (agencies) need a similar starting point for their use of the BRM. Based on some limited experience in government and use in commercial application a simple iterative Business Process Integration and Evolution model, which may prove useful in this regard, is shown in Figure 6.

Figure 6: Steps to Use the BRM and Link to Business Analysis and Improvement

1. The initial starter steps for a suborganization (1) is to learn about the BRM’s and how it fits with the missions of a Department or Agency and the related business lines. The Reference Models are target architectures that must be mapped to (or if a gap is found changes to the BRM’s recommended). BRM’s will evolve as the government



processes are defined in greater detail. Expect that an updated set of Reference Models will come out on a cyclical basis. One of the activities can be done is to create a Annual Calendar of Enterprise Architecture and Business Line Architecture that can act as your roadmap. This schedule can link with the government budget cycle and include the specific Agency and Business Line events such as conferences where work sessions for business line planning can be conducted.

2. The second step (2) involves developing a similar, yet enhanced, more detailed reference model for a suborganization. This will take some iteration and will ultimately become iterative with the other steps. In this example model there is a general service layer with a small number of key mission areas. These are top-level business functions which may contain a number of processes and related support delivery services, internal operations and infrastructure elements. It would be expected that there could be extensive reuse among those areas. During this stage, expect that there will be discussion around what are the primary mission functions of the organization. There are within an agency a number of levels of business process but getting the top layer right can be difficult for political, cultural, legal and other reasons. The Federal, Departmental and sub-agency models will also evolve as their usage increases.

3. The third step (3) is really two activities that are done in parallel. One is to understand the customers and business communities that are involved participate in and the second is to identify opportunities for improvement in establishing collaborative processes. Any agency may be a leader in a context of one business community, usually that organizations primary mission area and at the same time may have critical roles in other business contexts. In summary certain problems that agency owns and is responsible for solving, and in others it may just be a member, getting information from or sharing some, within a non leadership or primary process/business context, as only a participant. Defining the many organizations roles is challenging especially those where an organization may only be a stakeholder. Understand current expectations and extending them to include future scenarios, including the operational concept of how processes will work in the future, requires that the BRM be integrated into the strategic planning processes as well. The resultant vision developed from the business lines should point the Enterprise Architecture to fundamental reasons for the agency’s existence- service to and for the citizens, the public, businesses, organizations and other entities. Additionally adding value for process stakeholders and supporting internal efficiencies can also result. Further understanding roles in processes should trigger new service approaches defined in business process specifications and design levels (like web services components in lieu of sub-processes).

4. This is step four (4). These targeted business processes represent a string of services that start with some events and result in one or more outcomes. The current associated goals and outcome levels represent the baselines where achievement and maintenance metrics can be established. Steps 4, 5, and 6 are really running



concurrently in an iterative fashion. There are often three or more reviews of the products from those stages.

5. In step 5 new performance levels of achievement based on business process changes are established. Defining, integrating, describing and translating these performance metrics (from technology to business or vice versa) are presented in more detail in a companion paper.

6. Lastly in Step six, the concepts and process enhancements (including any proposed channels or web services components) are translated into a business plan and the related underpinning required analyses and alternatives are completed.

3.2 Identifying and Using Business Line ChannelsTaking an outside in perspective for the business layer of an agency’s Enterprise Architecture and using a business line approach (referred to in the FEAF as business segments) with collaboration across the business communities (segment participants and stakeholders) could facilitate development of a series of business line channels. In turn these channels could become Federal EA endorsed Web services components.

Clearly this approach is different enough that it will take time to adjust to thinking of Governmental organizations and their processes differently (internally and externally-both horizontally and vertically). One recommendation is that a number of specific targeted cross cutting functions, perhaps including several of the existing E-Governmental initiatives be selected and prototypically architected using the above approach, with the end goals in addition to the specific project goals being Federally endorsed business channels with reusable or subscribeable web services components. Another by product would be further detailed guidance on these processes within the context of existing architectural practices, some of which may be useful and others may be replaced or eliminated.



Figure 7: Identifying Business Line Channels

For agency architects it may prove useful to map a department or agency as in Figure 7. Look at the organizations Strategic Plans or performance agreement with the President. Review the FEA Reference Models and the President’s Management agenda. Include other directives from Department and Agency heads. Relate these things to the primary missions which are described in the in the BRM within the Business Lines. What are some of the other responsibilities? Look at the organization chart and envision the various roles that are potentially replicated, duplicated or paralleled. Maybe there are two to eight or nine areas that an agency or its subunits are involved in with other agencies. Some portions of those business community processes are either owned or operated as a steward. Just this exercise should illustrate and begin the thinking required for identification of areas where improved consolidated or collaboratively managed processes could be pursued. The activities within Step 3 can consist of the following subactivities:

1. .Understand your organizations role and responsibilities. Some of the steps will be obvious especially your primary role.

2. Define your current channels. These channels can be defined in terms of Government to Citizen, Government to Government, Government to Business, and around key topics of communication. Channels of communication have existed for years- just putting them down in a table Channel-Descriptions-Opportunities and Obligation can be a first step.

3. .Define a list of possible improvement opportunities along those channels. Many of them are being done but making them visible is an initial first step.



4. Define your current obligations. We are responsible to send this type of information to this agency when these events occur or periodically.5. A Business Line workshop can be convened- which is discussed in the next section.6. New obligations based on changing needs may be defined and the opportunities and obligations can be prioritized.7. The most important step is to commit to changes that are a “win-win” situation for all members of the business community.8. The next step is to take actions. Select one or two areas that can be improved and work them into both organizations Master Plans.9. Assess progress and integrate into performance reports while also creating a “success story” and recognition that worked to cross-the-organizational boundaries.

As we look to the future a business line architecture process that is facilitate the transformation of government at the Federal, State, and local levels. The move to business line architecture across government will take major facilitation and stewardship from the FEA-PMO in collaboration with the Federal CIO Council, its committees and other organizations including NASCIO but it will have significant returns. Pursuit of this approach in a more formalized plan may present business segments that form more natural groupings than the current E-Gov portfolios of G2C, G2G, G2B, IEE and result in more significant reuse, consistency, and delivery of service to the citizens (and other customers mentioned above). Many business lines may in fact have components ultimately focused across these portfolio areas making the assignment to any one arbitrary.

3.3 Facilitating Business Line Architecture ProcessOne of the steps that can be taken is to create a series of facilitated Business Line Workshops as mentioned in the previous section.

Figure 8 shows the high level set of steps related to forming Business Line Architectures, creating Business Communities, and defining the Business Line Channels. These steps will allow for strategic changes to be aligned across the business lines. It may be premature to recommend at this stage that all 30 or more business lines should go through a process like this, but a recommended first step would be to pilot and test it on “volunteer” areas and possibly within some of the critical areas such as Homeland Security and related potential business line channels such for disaster management support.



Figure 8: Business Line Architecture Process

The FEA-PMO with the assistance and support of the CIO Council and its committees can select (or ask for and nominate volunteer) “business lines” (FEA segments) and the associated business communities to be formed. To some extent there are already some such crosscutting groups across the government, such as in the scientific research community or the already strong Federal Emergency preparedness area with 13 Federal agencies as leads or participants and with the many state and local jurisdictions as stakeholders and participants. The FEA-PMO would require support from a small team of Business Analysts/Facilitators to do much of the upfront preparation work on each of the selected business lines. This would include answering questions like: Who are the members of the business line? What agency is/should be the lead? Who are they supporting? What are the lines of communication now? What is the level of information sharing? How the effort should be scoped and framed such that it is fully normalized and appropriately targeted at an area (or segment) that could realistically result in a business channel(s) and reusable/subscribeable web services components.

Early adopter agencies have used facilitated sessions to define information sharing in the Global Justice Network and the Environment data exchange process. Some of the basic elements from those experiences can define a series of workshops be held to link the partners together and develop a strategic direction for making significant changes to processes and to identify and develop action plans. These early business line experiences can be refined on projects within e-government integration projects or Homeland Security.



A key in these will be defining a visionary concept for operations and a series of actions that will improve the delivery of service to the citizens taking advantage of enabling technologies to provide a quantum leap with regard to performance measures (quality, costs or cycle times) which translate to unprecedented improvements in the processes of the mission-business area supported.

3.4 Creating Business Process Models The refining and defining of the use of the BRM and applying it to Federal Business Line Process improvements will take extensive planning and innovative, visionary thought. A simple representation of the type of process that can be used is shown in Figure 9. Elements of note are the process design, including a process discovery step which does not have to start from scratch but can rely on a library or repository of service and business patterns that are evolving quickly. Over the last 7 or more years various common business patterns, have moved from a small communities of experience users to a widely reused practices. The inherent reuse of business process models embedded in COTS software is but one example. This approach started as low level technical concepts built around the same ‘building architecture” patterns and have evolved where business patterns, such as those from various companies have become tools for wider use. The sidebar describes just this case as provided by one particular company.

(See sidebar…Business Service Patterns-To be supplied)

Figure 9: Operationalizing Business Process Models



One of the ongoing experiments of the concepts in this and other papers is to try the ideas on the SBA compliance One-Stop, the concept of which is shown in Figure 8. The approach used is to identify and design a series of services that borrow heavily from the Web Service movement using Web Services Description Language to define. The SBA One-Stop and many other cross cutting Federal business lines or segments have common service patterns that can become part of a “tool kit” for business analysts. Figure 7 is an example of the small business process divided into a set of interlocking services. Some of the types of Web Services may be very common such as those to discover the functions and information needed, create a plan of actions or complete the filling in of information once that will go in multiple forms in multiple Federal, state and local organizations.

(Sidebar…… Business Process for Web Services-to be provided).

Figure 10: SBA One-Stop Architectural Concept of Operations

Business Process Standards and Products for Service Oriented Architectures:A new breed of software has emerged that facilitates the integration of business processes—Business Process Management Systems. These systems are able to provide end-to-end process management and integration, extending within enterprises and between enterprises. Much of the integration that’s done occurs at the systems level (making systems interface or exchange data) or workflow. Both of these approaches have their limitations. Consequently, little progress has been made. The advent of an initial set of business process standards promises to change this



situation. These standards have served as the catalyst for development of a new class of products and the extension of existing product sets. Its focus is on reducing the cost and complexity of business process integration using service and information integration layers below the business process layer including Web Service access technologies. These tools address the business processes from an enterprise perspective and support collaboration across the extended enterprise. These systems can address the business line architecture needs of the government to government channels and take an end to end business process perspective.

The initial B2B and net markets focus resulted in standards such as ebXML and the partner to partner trading agreement process that is defined within the Business Process Specification Schema (BPSS). Over the last two years the Business Process Management Initiative (BPMI) coalition with over 160 companies has developed the Business Process Management System (BPMS) Language. Release 1.0 was completed and June 2002; products based on this standard have already been released. BPMS has been written to be compatible with ebXML and work with Web Services Choreography standards. BPMS address previous weaknesses found in workflow management systems and is based on strong theory called action calculus. There are other competing and compatible technologies under development such as that coming from the IBM Research Web Services Flow Language (WSFL) and Web Services Transaction (WTx) that show strong backing from industry leaders IBM, Microsoft, and others. These initiatives are addressing key challenges that the government faces in defining and developing business line architecture capabilities. The Web Service-Interoperability effort shows great cooperation between the industry giants and close interactions with a set of standards organizations. Activities such as the W3C- Web Service Architecture effort and the OMG Model Driven Architecture effort are starting to hear the push to business-driven service architectures. A common business vocabulary is being created by OASIS with Universal Business Language (UBL) vocabulary. These initiatives complete many of the basic business line architecture as defined in section Business Process Features for Business Line Architecture based on the “integration” of best features of these efforts. If each agency and their contractors try to define their own business process models and languages there will be much wasted time and effort. The industry has been debating many of these same concepts for a number of years. This commonality is essential to allow the business processes to be integrated and shared and allow a consistent delivery of service. It allows the business analyst to talk the same language as the IT technologies. It will allow personnel to move from industry to government or between agencies and still be using the same core modeling and language constructs with a few “organization specific extensions”. The next step is to take the model driven architectures and bridge to service and model driven integration. There is rapid progress and regular analysis that can be done once and shared widely by an emerging technology working group. For example, the XML Working Group and Web Services Working can track new Web Security and XML Security standards and companion Design Notation that is being developed by the enterprise tool vendor community and the query language standard. There may be unique extensions for government; some of those are being addressed in standards groups but there has not been a focus for those efforts.

One of the key steps of the e-government emerging technologies effort is to identify these needs and to “shepherd” the initiatives to meet the needs of the e-government business line participants. Government participation and leadership is necessary to assure that standards and technologies mature to meet these critical needs.



The question is will all the initiatives converge to meet the end to end government business process and information sharing needs? One way is to actively participate providing the government focus, such as through NIST in the newly formed task forces within the OMG and OASIS groups that are focusing on these types of business process support for business line architectures.

4 Conclusion Today, government civil servants are thinking about the citizens and communities they serve and taking steps forward. This paper recommends that those grace roots, doing their job kinds of changes continue but that those good ideas and processes be fostered in a more systematic way. The ideas here are based on observing and participating in many of those initiatives and the attempt to capture them. Creating a framework and environment where each business line is making one or two improvement each year and committing to other improvements in the future. Those improvements need to cross boundaries and a more “systematic” framework based on business-centric needs and values is recommended.

Existing frameworks provide the agencies with the ability to pick and choose between the best strategies for meeting the stated purpose of their architectures, but they may not always fit as efficiently or provide required guidance for quickly deploying technology (yet still architected) in cases where new or evolving agencies missions or critical cross-agency initiatives demand new approaches. Looking at the reality of the new Department of Homeland Security, the challenges to integrate functions across existing sub agencies causes decision-makers difficulty in identifying where to start the process. Enterprise Architecture and the use of the BRM and PRM (and other reference models) must provide transformational support to improving and consolidating processes.

o The BRM framework was intentionally designed to be flexible in supporting an agency’s architecture objectives, and it should be used as the starting point in defining any business sub-architectures. It is the starting point in defining an agency’s high-level business functions because it defines the Federal Government’s overall business model, and every federal agency must fit within this structure. As an agency’s mission evolves or its organizational boundaries move, the business functions will change. The existence of a defined and actively managed Federal Enterprise Architecture is the new standard for Federal Government and its partners and stakeholders, like the states and local governments.

o A strategic Human Capital element is to have government Business Analysts with a deep understanding of the government. They should have skills in Business Process and Value Modeling. They have the ability to work across organizational boundaries and build trust and present the value of creating a collaborative processes and sharing information. Skills in facilitation will also be needed along with the ability to create strategic business line agreements and prioritize many competing and sometimes conflicting cases for actions. This skill will include using a set of Business Analysis tools and in some cases directing proofs of concepts and prototypes to prove the business case and balance the value with the risks.



o Recommendations linked to Figure 11:o Update FEAF 2.0 with BRM & BLA Processes included and add the detailed

processes to either by the Practical Guide or develop a separate Guidebook (after pilot).

o Create some sample BSM's and then capture Business Service Models and Patterns and repository.

o Extend the Solution Development Life Cycle to address the processes used to discover the business line common needs, support rapid piloting and prototyping, define the information and functions shared, perform development and continuous integration and deployment

o Common Business Analyst Tools need to be defined including a Portal to tie the BRM-PRM with Patterns, Business Models and link to the Capital Investment and other business will need personnel to staff and share the knowledge and tools.

o Define Business Process-Notation and Language Standard. Define Common Modeling approaches that the business analysts can use and if not available recommend changes to the Business Process Notation, UBL Language or other Business Modeling Standards. With active participation in standards organizations the government can influence Enterprise level business process modeling tools and related integration and execution technologies.

o Business Analysis Competency Center and Portal. Assimilating these technologies and training the business analysts will be a critical element in transformation and must link to the Human Capital Strategy. There are many existing activities that must be linked to the reference models as shown in Figure 2. A conceptual picture of a portal that integrates existing tools such as I-TIPS and EAMS with collaborative tools and Business and Value Modeling and Multidimensional Decision Support tools as shown in Figure 12.

o Provide Portfolio Manages that can act as referees and facilities for BLA and create strategic Business Line Change agreements. Each business line needs a governance process that must work at both the strategic and tactical level. A business line owner (sponsor) should be defined by the President’s Management Council based on OMB recommendations. A three to five year plan and priorities can be established with the highest priority being the business line around Homeland Security.



Figure 11: Recommendations for Business Analyst Support to Transform Government



Figure 12: Conceptual Picture of Business & Analytical Portal



Appendix A

E-government Business Service Patterns and Categorization FrameworkAs government agencies develop a service oriented architecture it is speculated that there will a family of business service patterns that can be reused. One of the first steps is to define the facets for pattern collection. An initial set of patterns can be defined and compared with the initial set of e-government projects. Each business line as they go through the Business Line Architecture process can extend and refine the business service patterns.

There are some basic dimensions or facets that can be used to categorize these e-government business service patterns:

Stage of standard e-government service delivery Type of Service provided Goals meet by the business service pattern Business line use General Service support Links to Components and Implementation Experience

Each business service pattern can be created, peer reviewed or as they say in the pattern culture shepherded for shared use across the e-government environment. Some of the business service patterns will gain wide scale use and others will have a limited user community but there can be tremendous value of providing starter ideas at the Business Service level.

5 Key Facet Descriptions

5.1 Stage of standard e-government service deliveryThe users of e-government business services maybe individuals, businesses, other government entities or government employees or communities of these members all with one or more focus areas. Those focus areas can map to lines of business in the business reference model. The users can go through stages of support. The stages of support may include the following:

Discovery phase, which can include information discovery and mapping to services and arriving at and sharing the intent of the user. Disclosure of user and connection with prior information and personalization (in permitted) can be involved in this stage).Information phase: can include obtaining information based on previous discovery phase or an ongoing notification and subscription service for information that maybe of interest and value to the userInteraction phase: may involve the refinement and clarification of the information gathering phase, sometimes this can be answered with frequently asked questions, or a recommendation feature may support the interaction and more detailed exploration but in many cases it may take finding and talking or e-mailing with a real government service provider (or contractor).Transact phase: is the fulfillment of the plans that have evolved from the previous phases. This could include the filling out of multiple forms or the collection of the information into a personalized plan. Aftercare, evaluation and feedback phase: often with service there are follow-up steps that could involve additional steps or verifying that the recommendation worked. This could be to check that a recommendation worked or to verify that the service was successful. This phase also allows the series of service processes to be continuously being improved.

Type of Service provided



There are many possible types of services but we have defined seven generic types: Routine services- these are basic services that can be provided by a single

organization or type Composite services- are complex and come from multiple government entities that have

been aggregated together to meet the combined needs of the e-government user. Individualized case services- can either represent the life-events of an individual such as

birth, starting at school, entering the country, retiring, getting benefits, becoming disabled, marriage, residence change, passport, visas, taxes, death benefits) or business situations or episodes such as starting a business, reporting profit/loss or taxes, customs, building permits, employment of workers, and many more). There are also many internal services between government agencies that support the collective needs of the citizens. Each of these areas can be treated as a case.

Negotiation process- there are many activities from contracting to permits to rules and regulations that involve the negotiation and arbitration between conflicting demands and the value that each alternative provides.

Weakly structured or non-structured process such as the legislative process has limited “e-government” opportunities beside posting and e-mail.

Business line architecture where crossing the boundaries can involve a set of interorganizational patterns that allow the cross organizational collaboration.

Other services can be delivered on an ongoing basis through the end user requesting entering a subscription for a notification when a certain type of event has occurred. These events are along with alerts often are called publish and subscribe.

5.2 Goals met by the business service patternEach business service must meet a goal. It must have value. The range of value proposition can include items such as effectiveness, efficiency, satisfaction, learnability, memorability, innovate, etc. The business service must be connected to these parameters of the Performance Reference Model.

Other Facets for consideration:The business service pattern can also be linked to how it is used within one or more business lines or as a generic service capability. The business services can be linked or mapped to the appropriate component or managed service that is meeting this need.

The business service patterns can be described with a basic template or with a description language such as Web Service Description Language. It is envisioned that the business services would be stored in a repository and tools would be available to search and create new business services from existing business services or their fragments.


BRM Draft01062003v1.doc

Business

business lines

business design

business reference models

business process models

business process improvements

business line channels

extended business process

evolving business processes