DRAFT BUILDING THE ONE GSA ENTERPRISE ARCHITECTURE VERSION 1.0 GS426T1 Carrie Boyle, LMI Ellen Dupuy, LMI Phyllis Hunter, LMI Rick Smith, LMI John Butler, Unisys Cory Casanave, DAT Tom Digre, DAT SEPTEMBER 2004 The views, opinions, and findings contained in this report are those of LMI and should not be construed as an official agency position, policy, or decision, unless so designated by other official documentation.
Contents Chapter 1 Introduction...1-1 Chapter 2 Development Approach...2-1 BENEFITS FOR GSA... 2-4 BENEFITS FOR SSOS... 2-5 BENEFITS FOR THE CUSTOMER... 2-5 Chapter 3 Building the One GSA Value Chains...3-1 Chapter 4 Basics of Modeling in Component-X...4-1 COMMUNITY PROCESSES... 4-1 ROLES... 4-1 PROTOCOLS... 4-2 ACTIVITIES AND CHOREOGRAPHIES... 4-3 Chapter 5 Transforming Value Chains into Component-X Models...5-1 CREATING PACKAGES... 5-1 CREATING MDA MODELS FROM THE VALUE CHAINS AND OTHER ARTIFACTS... 5-3 SPECIALIZING A PROCESS TO A SPECIFIC SSO... 5-4 Chapter 6 Executing the Models...6-1 Figures Figure 2-1. One GSA Development Approach... 2-2 Figure 2-2. Multiple Model Views... 2-3 Figure 3-1. One GSA Value Chains... 3-2 Figure 3-2. Segments and Processes of the One GSA Mission-Critical Value Chain... 3-5 Figure 3-3. FSS Implementation of a Generic Target Process in the Mission-Critical Value Chain... 3-6 Figure 4-1. Sample Community Process with Defined Roles... 4-2 Figure 4-2. Sample Community Process with Defined Protocols... 4-3 DRAFT 10/1/04 iii GS426T1
Figure 4-3. Sample Choreography of Activities... 4-4 Figure 5-1. Component-X Icons... 5-1 Figure 5-2. Drill Down into Mission Critical Packages... 5-2 Figure 5-3. Model of FSS Implementation of a Generic Target Process in the Mission-Critical Value Chain: Develop Market-Making Strategy and Goals... 5-3 Figure 5-4. Value Chain Community Process... 5-7 Figure 5-5. Decomposition of Mission-Critical Value Chain to Include Segments... 5-8 Figure 5-6. Choreography of Mission-Critical Generic Processes... 5-8 Figure 5-7. FSS Specialization of One Community Process: Develop Market-Making Strategy and Goals... 5-9 Figure 5-8. Choreography of Activities for Planning Role... 5-10 Figure 6-1. Simulation Engine for FSS Implementation of Mission-Critical Value Chain... 6-2 Figure 6-2. Simulation of the One GSA Models... 6-3 Figure 6-3. Simulation of Mission-Critical Value Chain... 6-4 FOLDOUT FIGURES Figure 3-2. Segments and Processes of the One GSA Mission-Critical Value Chain 3-5 Figure 3-3. FSS Implementation of a Generic Target Process in the Mission-Critical Value Chain 3-6 Figure 5-4. Value Chain Community Process 5-7 Figure 5-5. Decomposition of Mission-Critical Value Chain to Include Segments 5-8 Figure 5-6. Choreography of Mission-Critical Generic Processes 5-8 Figure 5-7. FSS Specialization of One Community Process: Develop Market- Making Strategy and Goals 5-9 Figure 5-8. Choreography of Activities for Planning Role 5-10 Figure 6-1. Simulation Engine for FSS Implementation of Mission-Critical Value Chain 6-2 Figure 6-2. Simulation of the One GSA Models 6-3 Figure 6-3. Simulation of Mission-Critical Value Chain 6-4 DRAFT 10/1/04 iv GS426T1
Chapter 1 Introduction To transform the General Services Administration (GSA) to an agency that is citizen centered, results oriented, and market based, Stephen Perry, Administrator of GSA, envisions a One GSA in which the GSA service and staff offices (SSOs) work together to service GSA s customers, suppliers, and other government agencies. One means for pursuing this vision is the development and utilization of a GSA enterprise architecture (EA) a business-based framework for agency-wide improvement. GSA has been developing its EA since 2002. In July 2002, GSA published its EA framework, which is based on the Federal Enterprise Architecture Framework (FEAF) and the Zachman Framework. In 2003, GSA began further maturing its EA by testing the use of the model-driven architecture (MDA) approach to transform its EA into an executable enterprise architecture (EEA). GSA completed the PortMan pilot test in August 2003, successfully demonstrating the use of MDA for business modeling. In addition, in July 2004, GSA completed the Federal Supply Service (FSS) MDA pilot test, which not only demonstrated the use of MDA for business modeling, but also demonstrated the simulation of a business architecture with an existing GSA legacy system. Because of the success of the MDA pilot test, GSA undertook the One GSA EA initiative. The One GSA EA is defined as a set of products that describe the current and desired relationships among and between GSA s business lines and the information technology (IT) that supports those relationships. The One GSA EA is a strategic asset that supports activities such as strategic planning, performance measurement, human capital planning, competitive sourcing, and IT capital planning. GSA asked an LMI team, consisting of personnel from LMI, Unisys, and Data Access Technologies (DAT), for assistance with the One GSA EA initiative. The One GSA EA initiative requires transforming the GSA value chains into MDA models using DAT s Component-X modeling tool. This report describes the LMI team s overall approach to building the One GSA EA and provides a high-level overview of the key methods used. The report is organized as follows: Chapter 2 describes the overall approach to and benefits of building the One GSA EA. Chapter 3 describes the approach to value chain analysis (VCA) building and decomposing the One GSA EA value chains. DRAFT 10/1/04 1-1 GS426T1
Chapter 4 describes the Component-X vocabulary and display of models. Chapter 5 describes the transformation of the value chains into MDA models using Component-X. Chapter 6 describes the simulation of the models using Component-X. DRAFT 10/1/04 1-2 GS426T1
Chapter 2 Development Approach To develop an EEA for GSA, the LMI team used an iterative approach that integrates multiple methods. Two methods formed the foundation of our One GSA EA development approach: Value chain analysis. VCA identifies and evaluates current business processes and information requirements that directly affect the customer from an enterprise perspective. The goals of VCA are to simplify and streamline those processes and to increase customer satisfaction. Model-driven architecture. MDA is an industry standard approach to architecture design and systems modeling. The MDA approach links business process analyses to IT systems design. For the One GSA EA, the models are represented in Component-X using the Enterprise Distributed Object Computing Component Collaboration Architecture (EDOC CCA). CCA specifies how to model collaborative processes in a way that is sufficiently well defined to drive the execution of models. (In this report, all references to MDA assume the use of CCA to represent the models.) These methods complement each other. VCA enables a business analyst to diagram business processes with multiple layers of detail and align them across an organization. MDA takes those business processes one step further, transforming them into executable models, independent of a specific technology, and making it possible to see how changes to processes and technology may affect the efficiency and effectiveness of the way the organization does business. Being able to forecast the effects of such changes enables the organization to improve its planning, design, and operations, along with its supporting processes and technology. The LMI team s One GSA EA development approach, depicted in Figure 2-1, had four steps: Finalize the One GSA current architecture. We identified and filled the gaps in the current One GSA architecture representing each of GSA s nine SSOs. The final current architecture includes a repository with links to multiple current architecture artifacts including System Architect encyclopedias, SSO strategic plans, GSA functional hierarchy, GSA organization chart, process maps, systems inventory, and data inventory and mappings to the Federal Enterprise Architecture (FEA) business reference model (BRM) and technical reference model (TRM). Develop value chains to standardize primary business activities across GSA. We developed seven generic target value chains to represent, in a DRAFT 10/1/04 2-1 GS426T1
consistent and integrated fashion, the business functions performed by GSA. At a highly aggregated level, the value chains represent current best practices and GSA s vision. The value chains are based on existing EA process documentation and are the foundation for the target architecture. (This is further explained in Chapter 3.) Build target business models using MDA. We transformed the target generic value chains into executable models using DAT s Component-X modeling tool. In addition, we referenced or incorporated existing architecture artifacts and models into the tool. We then added detail to the processes in the generic value chains to produce the target business model. (This is further explained in Chapter 4.) Complete a sequencing plan. Once the current and target architectures are completed, we will perform a gap analysis to determine the steps that GSA will need to take to achieve its desired target business state. Specific projects will be identified and linked to the target architecture. Each will be further detailed to describe resources, time frames, expected costs, and performance measures. Figure 2-1. One GSA Development Approach Current Architecture Finalize Current Architecture Existing artifacts Understanding the Current Environment GSA Interviews Develop Value Chains Defining the Future Value Chain Analysis Build MDA Models Target Architecture Projects, Timeline, Resources, CSF Business Case Analysis Implementing the Solution Sequencing Plan Building the target models using VCA and MDA leads to two different views of the models. One is a process-centric view focused on the decomposition of value chains. The second is a role-centric view, focused on the collaboration of roles. Figure 2-2 illustrates how these two views fit together. The collaboration view shows that the core collaborations (interactions between roles) stem from an DRAFT 10/1/04 2-2 GS426T1
Development Approach agency s business models. Within the core collaborations are generic roles, activities, and protocols. The decomposition of the value chains into processes is shown on the right. These processes have roles and activities specific to an SSO. However, the processes also have generic roles and activities to represent the One GSA architecture as a whole. It is at this point that the process-centric and rolecentric views are interconnected using VCA and MDA. This version of the report focuses on the process-centric view of the models. Figure 2-2. Multiple Model Views Collaboration View Business Models Core Collaborations Value Chain View Component-X Model Generic Value Chains Generic Processes One GSA Roles One GSA Activities & Protocols Informs & Validates FSS Roles & Activities FTS Roles & Activities PBS Roles & Activities VCA and MDA have proven to be the best approaches to supporting design for change at the GSA. Through VCA, an organization can identify a business problem, streamline processes to solve it, and outline changes needed to the current state to reach the desired future state. From there, MDA can help with building these models in an executable form, independent of a specific technology or system. It can also facilitate the mapping from the current to the desired state via execution of the models. Application of VCA and MDA produces a cohesive architecture that satisfies the customers needs and supports GSA s mission: We help federal agencies better serve the public by offering, at best value, superior workplaces, expert solutions, acquisition services, and management policies. If defined, maintained, and implemented effectively, the One GSA EA will assist with optimizing the interdependencies and interrelationships among GSA s business operations. This will benefit GSA overall, GSA s SSOs, and GSA s customers. DRAFT 10/1/04 2-3 GS426T1
BENEFITS FOR GSA One GSA is an agency-wide architectural framework representing all SSOs. With the One GSA EA, GSA will have a greatly enhanced cross-sso analytical capability. GSA will no longer be dependent on the SSO-by-SSO analyses that have characterized the resource allocation process in the past. Through the One GSA EA, with its perspective of customer services delivered, GSA will be able to identify redundancies, gaps, and opportunities for collaboration across the SSOs. The following are some of the key benefits of One GSA EA to GSA: Executable models that demonstrate the effects of process and IT changes within GSA An agile, full life-cycle approach that links requirements, analysis, design, test, documentation, and execution Elimination of investments in redundant IT capabilities, business processes, or other capital assets Reduction in total life-cycle cost, time, and labor due to automation and reuse Reduced risk of technology lock-in and obsolescence Increased ability to optimize the technologies and architecture before, during, and after deployment Reduced risk of project failure due to the fast, iterative process and increased flexibility in technology choices and business model evolution Use of standards integrated with existing processes supported by open and readily available resources Reduced lock-in to specific vendors or tools by using standards-based models Increased ability to evolve and adapt business models, rules, and processes Identification of common business functions across SSOs Integration of performance measurement with business processes. DRAFT 10/1/04 2-4 GS426T1
Development Approach BENEFITS FOR SSOS One GSA is not just for GSA, nor is it for any single SSO. One GSA is exactly what its name suggests an architecture for GSA as a whole. The One GSA EA will give each SSO a collection of new capabilities for defining and implementing their own target environments and will enable the SSOs to do the following: Save time and money by leveraging business processes, data, and IT components from other SSOs Leverage EA work products as a catalyst for business service delivery efforts Ensure that proposed investments do not duplicate those of other SSOs Visualize how their business functions and technology have been integrated into the One GSA architecture to achieve the desired target state Reduce spending on IT-related projects, allowing the focus to be on adding value to the customer. BENEFITS FOR THE CUSTOMER The true driver behind the EA effort is the need to improve GSA s delivery of services to its customers. The One GSA EA will enable GSA to increase its value to its customers by, among other things, doing the following: Implementing best practices and principles to empower SSOs to rapidly implement high-value solutions in response to changing customer needs Enabling the SSOs to focus on their primary activities, providing the most value to the customer as possible Minimizing the number of customer touch-points via elimination of redundant processes and systems. DRAFT 10/1/04 2-5 GS426T1
Chapter 3 Building the One GSA Value Chains A value chain represents a primary business function and can be one of three types: Mission critical. A mission-critical value chain describes an agency s primary value proposition. Support services. A support services value chain describes administrative, technical (guidance and health), and logistical support services that facilitate and enhance the agency s mission. Shared services. A shared services value chain describes services that are common across departments in an organization. Each value chain can be decomposed into multiple layers of information: Segments. A segment is a set of processes or events that create and build value. Processes. A process is a formally defined sequence of activities that targets a specific result. Activities. An activity is a self-contained work unit consisting of a cohesive collection of actions that are performed by one role when producing a set of related work products or providing one or more related services. Actions. An action is the fundamental unit of behavior specification in a process. By building its value chains through value chain analysis, an organization can identify and evaluate current business processes and information requirements that directly impact the customer. The organization can then identify a target state that simplifies and streamlines those processes and thus increases customer satisfaction. To help identify the One GSA EA ideal state, the LMI team developed generic target value chains to align GSA s primary business activities across all SSOs. Generic refers to the fact that at the top level, the processes are representative of GSA as a whole; however, at the SSO level, variations exist. Target refers to the desired future state with which GSA would like to align its business activities. DRAFT 10/1/04 3-1 GS426T1
Building GSA s generic value chains required analyzing the complex relationships of GSA s organizational units and the related business functions, business processes, business activities, and information that support them. That analysis enabled GSA s SSOs to identify what their primary business activities are and how they add value to the customer. VCA also enabled them to identify where each SSO s processes could be integrated into the One GSA architecture. This alignment will make it easier for GSA to achieve its desired target state. For the One GSA EA, the LMI team identified seven value chains: One mission-critical value chain that has three segments plan and design, develop and deliver, and provide after care Three support services value chains development of government-wide policy, marketing, and acquisition Three shared services value chains financial management services, IT services, and human capital services. Figure 3-1 depicts GSA s seven value chains. Figure 3-1. One GSA Value Chains Plan and Design Develop and Deliver Provide After Care Mission-Critical Value Chain Development of Government-wide Policy Marketing Acquisition Support Services Value Chains Financial Management Services I.T. Services Human Capital Services Shared Services Value Chains DRAFT 10/1/04 3-2 GS426T1
Building the One GSA Value Chains Figure 3-2 shows the segments and processes of GSA s mission-critical value chain. As the figure shows, the planning and design segment has four processes, the development and delivery segment has six processes, and the after care segment has four processes. Identification of activities and actions adds detail to a generic target process. For the One GSA EA, activities and actions reflect the specific ways that a particular SSO implements a particular process. Implementation of a process may be similar from SSO to SSO, or it may vary significantly. Because activities and actions are specific to a specific SSO, they are no longer considered generic, although they are still considered targets. Figure 3-3 shows the specific activities that FSS undertakes when implementing one of the generic target mission-critical value chain processes: develop marketmaking strategy and goals. The figure also decomposes one of the activities business lines perform strategic assessment into a series of actions that must take place before the next activity in the process occurs. These actions include perform strategic policy analysis, provide metrics input, perform market analysis, and coordinate business line and corporate strategic assessments. Once business line and corporate strategic assessments have been coordinated, FSS starts the next activity: Management Council performs strategic assessment validation and consolidation. To keep this example simple, we did not show a full decomposition of all activities into actions. DRAFT 10/1/04 3-3 GS426T1
Building the One GSA Value Chains Figure 3-2. Segments and Processes of the One GSA Mission-Critical Value Chain Mission-Critical Value Chain Generic Segment 1.0 PLAN AND DESIGN 2.0 DEVELOP AND DELIVER 3.0 PROVIDE AFTER CARE Generic Process 1.1 Develop market making strategy and goals 1.2 Establish products and services offered 1.3 Establish/ maintain marketplace 1.4 Provide product support, education and communication 2.1 Establish and manage contracts 2.2 Plan, manage, maintain, monitor inventories 2.3 Receive order/request for goods/ services 2.4 Respond to order/ request 2.5 Fulfill order/ request 2.6 Complete Billing/ payment 3.1 Provide problem management support 3.2 Provide contract/ schedules support 3.3 Maintain partner servicelevel performance 3.4 Provide customer care, manage mission response, and solicit feedback DRAFT 10/1/04 3-5
Building the One GSA Value Chains Figure 3-3. FSS Implementation of a Generic Target Process in the Mission-Critical Value Chain Mission-Critical Value Chain Generic Segment 1.0 PLAN AND DESIGN 2.0 DEVELOP AND DELIVER 3.0 PROVIDE AFTER CARE Generic Process 1.1 Develop market making strategy and goals 1.2 Establish products and services offered 1.3 Establish/ maintain marketplace 1.4 Provide product support, education and communication 2.1 Establish and manage contracts 2.2 Plan, manage, maintain, monitor inventories 2.3 Receive order/request for goods/ services 2.4 Respond to order/ request 2.5 Fulfill order/ request 2.6 Complete Billing/ payment 3.1 Provide problem management support 3.2 Provide contract/ schedules support 3.3 Maintain partner servicelevel performance 3.4 Provide customer care, manage mission response, and solicit feedback FSS Implementation Activity 1.1.1 Business lines perform strategic assessment 1.1.2 Mgmt. Council performs strategic assessment validation and consolidation 1.1.3 Business lines develop business plans 1.1.4 Mgmt. Council reconciles all business plans/ develops final business plan FSS Implementation Action 1.1.1.1 Perform strategic policy analysis 1.1.1.2 Provide metrics input 1.1.1.3 Perform market analysis 1.1.1.4 Coordinate business line & corporate strategic assessments DRAFT 10/1/04 3-6
Chapter 4 Basics of Modeling in Component-X For the One GSA EA, the LMI team built executable models using Component-X. Like many tools, Component-X has a distinct vocabulary and display of the models, based on MDA. The models may be described in terms of the context in which the process is executed (community process), the responsibility for performing an activity (role), the way in which information is exchanged by roles while performing an activity (protocol), and the activities and the sequence in which they occur (choreography). Each of these concepts is described below. COMMUNITY PROCESSES ROLES A community process, or collaboration, is generally tied to some purpose and identifies a closed set of roles that participate in achieving that purpose. To put it another way, a community process contains and gives context to a set of roles that serve the purpose of the collaboration. A closed set of roles does not depend on any other roles (except, perhaps, to implement one of the roles). Collaborations should be kept small, with as few roles as possible. As an example, a collaboration is the buying and selling of products and services, or the billing and payment for a service rendered. Within each of the community processes is a set of roles responsible for performing a specific function. A role one party in a community process has some responsibility in terms of achieving the process s purpose. For example, in a process for buying and selling a product or service, possible roles could be the buyer and seller. Something or someone an actor must play the role (i.e., exercise the responsibility) for it to be realized. An actor can be a specific individual, an organization, or a technology performing a function. For example, the role of a GSA customer may be played by the Department of Labor or the Department of the Interior, and the role of order manager could be played by a GSA procurement system such as ebuy. (A single actor may play roles in several community processes.) Figure 4-1 shows a sample Component-X community process with defined roles. The community process is brokered procurement, and it has three roles: customer, procurement broker, and supplier. DRAFT 10/1/04 4-1 GS426T1
Figure 4-1. Sample Community Process with Defined Roles PROTOCOLS A role may also be abstract; an activity or value chain is an example. For One GSA, we modeled the exchange of information between value chains and activities. We did this by defining value chains and value chain segments as roles. Therefore, value chains and segments play a role in the One GSA community process. To give meaning to roles within a community process, we identify the conversations, or protocols, that take place between the actors playing these roles. Protocols deal with two-way conversations between roles and may be as complex as nested conversations relating to the conversations between actors playing these roles. Protocols identify exchanges of information such as the document exchanges that take place in a process. The sending or receipt of requests for quotations (RFQs) and purchase orders (POs) are examples of such exchanges between customer and supplier roles in a procurement process. Component-X shows initiator protocols (protocols used by a role) on the right and responding protocols (protocols provided by a role) on the left. Figure 4-2 defines the protocols for the community process shown in Figure 4-1. Again, the roles are customer, procurement broker, and supplier. Each has a set of protocols. Customer has two responding protocols (order fulfillment and invoice) and one initiating protocol (purchasing). Procurement broker has two responding protocols (purchasing service and order status) and one initiating protocol (purchasing). Supplier has one responding protocol (purchasing) and three initiating protocols (order fulfillment, invoice, and order status). Each of the roles has protocols that are linked with lines showing the interactions between the roles. For example, the customer sends purchasing information to the procurement broker, the procurement broker sends purchasing information to the supplier, and the supplier sends invoice information to the customer. DRAFT 10/1/04 4-2 GS426T1
Figure 4-2. Sample Community Process with Defined Protocols ACTIVITIES AND CHOREOGRAPHIES In Chapter 3, we discussed how value chain processes can be decomposed into a series of activities and actions. Likewise, activities in Component-X can be decomposed. In Component-X, an activity is modeled only once, and then it is linked to any role that might perform it. Each role may perform multiple activities. It is essential to know the order in which these activities occur. In Component-X, we lay out the activities with transitions. This is called a choreography. A detailed choreography represents the sequence of activities for a specific role and the sending and receiving of information between roles. Figure 4-3 shows a sample choreography of activities. In this case, the customer project manager determines product needs, develops the RFQ, evaluates the quotes, manages schedules, and accepts goods and services. In many of these activities, information is exchanged with another role. For example, the dotted line coming from the RFQ development protocol connects to the RFQ development protocol on the outside of the choreography. This shows that the RFQ is being shared between the customer project manager and another role in the same community process. DRAFT 10/1/04 4-3 GS426T1
Figure 4-3. Sample Choreography of Activities DRAFT 10/1/04 4-4 GS426T1
Chapter 5 Transforming Value Chains into Component-X Models In this chapter, we discuss the process used to transform value chains into MDA models using Component-X. Transforming the value chains into models results in dynamic, executable models versus static diagrams that cannot interface with a chosen system or technology. Figure 5-1 shows the icons used in the models. Figure 5-1. Component-X Icons Value chain Element Component-X icon Value chain segment Value chain process Value chain activity Role Protocol Community Process CREATING PACKAGES The first step in creating the models in Component-X is creating the project and the packages used to organize project elements. A package is similar to a folder in Windows Explorer. Analysts can group related elements and organize them in DRAFT 10/1/04 5-1 GS426T1
whatever way they choose. These elements can be exchanged between different packages. We created packages for each type of value chain. And then within each type of value chain, we created a package for the value chain segment. Finally, within the value chain segment, we created a package for the process. Figure 5-2 shows the drill-down into the generic target mission-critical value chain package. Under the package labeled value chain are separate packages for each target generic value chain, such as finance management and mission critical generic. Within each target generic value chain package are packages for each value chain segment, including plan and design, develop and deliver, and provide after care (client support). Within each value chain segment package are a series of processes. Remember that these processes are still generic to all SSOs. This nested structure makes it possible to better organize model elements. Figure 5-2. Drill-Down into Mission-Critical Packages Value Chain Package Segment Package Process When we developed the generic target value chains, we stopped the decomposition at the process level. However, for each SSO, there are specializations of the target generic value chains at the activity level. For example, both FSS and the Public Buildings Service (PBS) have specializations of the mission-critical generic target value chain. Because each SSO has its own way of doing business, this method provides a way to link each SSO s specific set of activities to the target generic value chains, while still aligning them with the One GSA EA. DRAFT 10/1/04 5-2 GS426T1
Transforming Value Chains into Component-X Models Figure 5-3 shows the FSS implementation of the develop market-making strategy and goals process, as part of the mission-critical value chain. To illustrate the specializations of the target generic value chains, we created an additional package called breakout. Within the breakout package is a separate package for each of the SSOs showing their value chain implementations. In this example, under the breakout package is a package for FSS. Within the FSS package is an implementation package for the develop market-making strategy and goals process. Inside this implementation package is a community process that has been modeled to represent the FSS implementation, which has a set of roles, activities, and protocols specific to how FSS implements this process. The roles, activities, and protocols for PBS would be different. Figure 5-3. Model of FSS Implementation of a Generic Target Process in the Mission-Critical Value Chain: Develop Market-Making Strategy and Goals FSS Implementation Package Community Process CREATING MDA MODELS FROM THE VALUE CHAINS AND OTHER ARTIFACTS After EA artifacts and models have been loaded into Component-X, we built the value chains. Building value chains in Component-X is a decomposition process, much like that described in Chapter 3. We started at the top and worked our way down. First, we modeled each type of value chain as a role with specific interactions in the One GSA community process. Figure 5-4 shows the interactions between each type of value chain. For example, the mission-critical value chain is interacting with the mission support value, which is represented by the line connecting the two. This and the next level of detail results in a process-oriented view of the model. DRAFT 10/1/04 5-3 GS426T1
Next, we decomposed each value chain into more granular set of roles, the value chain segments, which also have information exchanges. Figure 5-5 shows the value chain segments for the mission-critical value chain. The three segments are modeled as roles called plan and design, develop and deliver, and provide client support (after care). There are also information exchanges, such as plan develop between the planning and design and the development and delivery roles. Each value chain segment is further decomposed into a choreography of generic community processes. Figure 5-6 shows the choreography of the generic processes that are part of the generic mission-critical plan and design value chain segment. SPECIALIZING A PROCESS TO A SPECIFIC SSO The next level of decomposition involves the specialization of a process by a specific SSO. At this level of detail, we develop the role collaboration view of the model. The roles become less abstract and can be envisioned to be played by specific actors. In addition, the protocols employed by the roles become more specific, and the activities in the role choreographies become more detailed. In Component-X, we modeled each generic process as a specialized community process containing roles and protocols. Figure 5-7 shows the FSS specialization of the develop market-making strategy and goals process within the mission-critical value chain and the planning and design value chain segment. Several roles have been identified, including planning, marketing, and finance. Each role exchanges some type of information with other roles. For example, the planning role exchanges financial information with the financial role. The next layer of decomposition involves the choreography of the activities associated with each of the roles in a process. Figure 5-8 shows the choreography of activities defined for the planning role in the develop market-making strategy and goals process. Here planning is responsible for several activities starting with performing strategic policy analysis and ending with developing an enterprise-level business plan. Also, you can see the information being exchanged with other roles via the green dotted lines. For example, metrics input and business line business plan are protocols sharing information with another role. In summary, our modeling approach includes the following steps: Build value chains to represent the business functions of an organization Decompose these value chains to include segments, activities, and actions Transform these value chains into MDA models using a community process to represent them DRAFT 10/1/04 5-4 GS426T1
Transforming Value Chains into Component-X Models Identify any specializations of the process Determine the roles that act within this community process and its decomposed layers Identify the information exchanges (protocols) between the roles within the process at each layer of decomposition Choreograph the sequence of activities using transitions. The next step is to execute the models, which is described in Chapter 6. DRAFT 10/1/04 5-5 GS426T1
Transforming Value Chains into Component-X Models Figure 5-4. Value Chain Community Process DRAFT 10/1/04 5-7
Transforming Value Chains into Component-X Models Figure 5-5. Decomposition of Mission-Critical Value Chain to Include Segments Figure 5-6. Choreography of Mission-Critical Generic Processes DRAFT 10/1/04 5-8
Transforming Value Chains into Component-X Models Figure 5-7. FSS Specialization of One Community Process: Develop Market-Making Strategy and Goals DRAFT 10/1/04 5-9
Transforming Value Chains into Component-X Models Figure 5-8. Choreography of Activities for Planning Role DRAFT 10/1/04 5-10
Chapter 6 Executing the Models The real value from the models comes from executing them so that business and technical personnel can better understand their business and the interactions, as well as potentially identify areas that could be more efficient. This understanding is particularly useful when business processes are being reengineered; through simulations, management can make sure that the process is valid and that all participants get and produce the information they need to fulfill the organization s mission. This chapter describes how we execute our models using the Component-X simulation engine. A simulation engine contains a view of the model that executes, or allows you to trace through the models step by step. This is similar to the process used to debug software. Figure 6-1 shows the simulation engine for the FSS implementation of the mission-critical value chain. Simulating a model requires some type of trigger to set it in motion. For example, the start of a procurement model involving customer and supplier roles might be the customer receiving an order request. In Component-X, the trigger is modeled using a send port. For the One GSA EA, we use the trigger that starts the mission-critical value chain. As shown in Figure 6-1, the trigger for the mission-critical value chain is the planning time frame for a new fiscal year. Clicking send starts the simulation and executes the models step by step. The point where the analyst is located in the models is highlighted in pink. Figures 6-2 and 6-3 show an example of walking through a simulation of the models. Figure 6-2 shows the planning function (role) and the series of activities assigned to it in its choreography. At this point, the planning function is just starting its activities, because it received the notice that the planning time frame has begun. Figure 6-3 shows the sequence of the model moving to the next activity in the choreography of the planning function. At this point, the planning function is responsible for providing metrics input. DRAFT 10/1/04 6-1 GS426T2
DRAFT [Click here and type report #)] 10/1/046-2 GS426T2_6a_Simulating Models
Figure 6-1. Simulation Engine for FSS Implementation of Mission-Critical Value Chain DRAFT 10/1/04 6-2
Figure 6-2. Simulation of the One GSA Models DRAFT 10/1/04 6-3
Figure 6-3. Simulation of Mission-Critical Value Chain DRAFT 10/1/04 6-4