An Introduction to Proact s Framework, Methodology, and Modeling Tool for Enterprise Architecture Management. Version 1.8

Transcription

1 Proact Business Transformation Toolkit Overview An Introduction to Proact s Framework, Methodology, and Modeling Tool for Enterprise Architecture

2

3 COPYRIGHTS AND TRADEMARKS Copyright 2005 Proact Business Transformation Inc. All information that is proprietary and specific to Proact Business Transformation Inc. is the sole property of Proact Business Transformation Inc. Proact Business Transformation Toolkit is a registered trademark of Proact Business Transformation Inc. Photocopying, electronic distribution or foreign language translation of this document is permitted, provided this document is reproduced in its entirety. QUESTIONS AND COMMENTS All questions and comments concerning this document should be directed to Art Caston at (905) i

4

5 TABLE OF CONTENTS Copyrights and Trademarks... i Questions and Comments... i Purpose... 1 The Proact Approach...1 The Proact Value Proposition... 2 What are the benefits of adopting Proact?...2 The Proact Advantage...2 Holistic Approach...2 Service-based Orientation...3 Reference Models...4 Shareable Repository...5 Overview of the Proact Framework and Reference Models... 6 The Business View Reference Models...6 The Market Model...7 The Product Model...7 The Enterprise Relationship Model...7 The Enterprise Resource Model...8 The Operational View Reference Models...8 The Service Function Model...8 The Enterprise Information Model The Create/Use Matrix The Systems View Reference Models Systems Families Spider Diagrams Reference Systems The Technology View Reference Models Technology Services Reference Model Technology Devices Model a

6 Overview of The Proact Methodology...21 Reference Modeling Baseline Assessment Opportunity Assessment Target Architecture Development Migration Strategy Planning Overview of the Proact Modeling Tool and Repository...28 Enterprise Architecture Team...29 Summary...31 Appendix A Summary of Proact Models by Proact Framework View...32 Business View Operational View Systems View Technology View b

7 TABLE OF FIGURES Figure 1. Four Views of an Enterprise... 3 Figure 2. The Proact Framework... 6 Figure 3. Five Major Functions for a Retail Company... 9 Figure 4. Example Service Flow Model for Customer Experience Sales & Service Figure 5. Example of Basic Service Function Figure 6. Enterprise Information Model Top Level Figure 7. Partial Create Use Matrix for Customer Experience & Sales Support Figure 8. Systems Families for a Retail Enterprise Figure 9. Reference Spider Diagram for Sales Support System Family Figure 10. Reference Systems Within the Sales Support System Family Figure 11. Technology Services Reference Model Structure Figure 12. Technology Services Within Foundation Services Figure 13. Basic Technology Services in Systems Figure 14. Example of End User Devices Types Figure 15. The Proact Methodology Figure 16. Plot of Basic Service Functions for Opportunity Prioritization Figure 17. System Information Exchange Model for Sales Support System Family Figure 18. System Technology Model for the Product Information System c

8

9 PURPOSE This white paper introduces the Proact Business Transformation Toolkit (Proact Toolkit), a formalized framework, methodology, and modeling tool for establishing an Enterprise Architecture Practice within Global 2000 businesses, governments, and military institutions. The paper provides an overview of the Proact philosophy, framework, methods, and tool. It is intended as introductory reading for new practitioners within the Enterprise Architecture Practice as well as the clients and users of the enterprise architecture models and methods who wish to understand more about the capabilities of the Proact Toolkit. It also provides a useful summary of the features and capabilities of Proact for those considering establishing an Enterprise Architecture Practice or evaluating Enterprise Architecture tools. THE PROACT APPROACH Proact employs a very comprehensive approach for building and maintaining an Enterprise Architecture Practice within the Global 2000, large-scale organizations and management consulting companies. Enterprise Architecture is a capability for using model-based planning techniques to simplify and focus complex decision-making for strategic investments during business transformation. Enterprise Architecture delivers opportunity assessments (business cases), target architectures (blueprints), and migration strategies (roadmaps) to govern enterprise transformation programs. The Proact approach is embodied in the Proact Business Transformation Toolkit. The Proact Toolkit is comprised of four key components: The Proact Framework provides four different views of the enterprise through models, elements and associated relationships built around an underlying Meta-model ; The Proact Methodology supports the development of reference and target architecture models, assessment of baseline capabilities, identification of transformation opportunities, and creation of migration roadmaps; Reusable Reference Models accelerates Enterprise Architecture initiatives by providing an evolving set of generic and industry-specific models that identify essential capabilities and relationships that are crucial to value generation; and A flexible multi-user Modeling Tool and Repository enables the capture and navigation of models, stores associated element attributes, performs matrix analyses, and generates Web and document-based deliverables. This tool consists of Proact s unique Framework, diagrams, business elements, matrices, and reports implemented on System Architect from Popkin Software Inc. The Proact Framework and Methodology is the creation of Art Caston, the co-author (with Don Tapscott) of the international best-seller Paradigm Shift: The New Promise of Information Technology. Over the last ten years the Proact Framework and Methodology have been evolved, developed, and verified, through Enterprise Architecture engagements with leading organizations in the Retail, High Tech Manufacturing, Telecommunications, Finance and Insurance, and National Defense and Security Industries. Proact is also the abbreviation for the company, Proact Business Transformation Inc, that produces and provides the Proact Toolkit, along with the training, and facilitation 1

10 services to assist customers with the implementation of an Enterprise Architecture Practice. THE PROACT VALUE PROPOSITION WHAT ARE THE BENEFITS OF ADOPTING PROACT? In a phrase Enterprise Agility. In today s dynamic business environment, it is impossible to plan and predict (or control) the future. How, then, does an enterprise prepare to react to changing and unpredictable market and economic conditions, new product opportunities, new channel opportunities, partnering and merger and acquisition opportunities, systems and technology opportunities, etc.? The answer by using the Proact Toolkit to identify and define the complete set of enterprise capabilities as modular service components of the business that can be developed, reconfigured, scaled up (or down) as required. These enterprise capabilities are independent of organizational silos and politics, providing strategists, architects, and planners the means to drive for high performance across the enterprise, regardless of the shifting set of strategic business drivers. Building and implementing new or improved capabilities, adjusting business volumes, and integrating with new partners or acquisitions is greatly facilitated through common views of these building blocks and through reusing solution components. In other words, Better, Faster, Cheaper projects. THE PROACT ADVANTAGE The Proact Toolkit embodies principles learned through practical experience as Enterprise Architecture. There are a number of key features of the Proact Toolkit that capture these learnings. Holistic Approach The essence of architecture is the practice of identifying and structuring components to achieve a planned result. Architecture must take into account the environmental context and the interrelationships of components, both external and internal. Architects deliver blueprints and roadmaps to designers, engineers, and program managers to enable the construction or acquisition of the intended capabilities in a given timeframe. Enterprise Architecture applies these practices to the planning of capabilities required by a business or institution. Architecture is most often associated with technical or engineering applications and, indeed, it is the Information Technology area of businesses where Enterprise Architecture has its roots. However, the practices are equally applicable to other areas of the business where complex structures and interrelationships are prevalent. The Proact Toolkit has been designed to leverage a holistic Enterprise Architecture Methodology and Tool, applying the practice of architecture to all areas of business planning, from the most strategic (e.g., market repositioning strategies, merger and acquisition evaluations) to the most technical (e.g., how to roll-out wireless local area networks). With this approach, it is possible to create models that link and trace the impact of opportunities and transformation programs across various levels of planning. The Proact Toolkit provides a well-structured framework for organizing these interlinked planning models based on Four Views of the Enterprise as shown in Figure 1. 2

11 Figure 1. Four Views of an Enterprise The Business View caters to the strategists and planners involved in assessing market opportunities, expanding product portfolios, leveraging partnering opportunities, and other key areas of strategy development. The Operational View describes the essential functions of the enterprise and is used to design effective business processes and welldefined organizational accountabilities. The Systems View defines how information management applications can be used and linked to automate business process workflow and transaction management. The Technology View contains the architecture models that are used to design the underlying information technology infrastructure, including user devices that access these applications, the computers that run the applications, and the networks that connect it all together. The Proact Framework is further described in the next section. Service-based Orientation Another key feature of the Proact Toolkit is the use of service-based orientation for enterprise modeling. A fundamental principle of good architecture is to define modular components or building blocks that have well-defined capabilities and interfaces that can be decoupled. A service-based orientation takes this principle another step by using Services to describe the capabilities represented by these components. These services can then be called upon as needed to support new scenarios and changing demands. The Business View creates relationships between business partners (suppliers, channels, shippers, customers, etc.) that are described based on the services that flow between them (i.e., provision of goods, selling of goods, transport, installation and repair). This approach is very useful in identifying cross enterprise collaboration opportunities, in evaluating in-sourcing and out-sourcing scenarios, and in assessing integration synergies with merger and acquisition candidates. The Operational View is based on functional representations of essential operational capabilities. These functions are linked by the services they provide to other functions or external entities. This provides a powerful way to view the internal 3

12 capabilities of the enterprise since the services focus on the purpose and results of the function. These Service Functions provide clean delineations for designing process interfaces, establishing meaningful performance metrics, and aligning functional accountability throughout the organization. The Systems View identifies systems and their components that can also be represented by the services they provide. For example, an Order System will provide services such as capture new order, provide order status, and update shipping instructions. This technique for architecting systems supports rapid assembly and integration of new capabilities and allows for dynamic changes to operational scenarios through the automation of selected workflow management. The Technology View is also modeled as a set of components that provide services to applications and users of the IT Infrastructure, as well as to each other. Examples include messaging services, directory services, authentication services, encryption services, and print services. This provides a rich and deep set of reusable services that are shared across the community of applications and users. This service-based orientation applied throughout the Proact Framework is the basis for creating enterprise agility. The vast majority of the required services can be preplanned and managed as modular capabilities. These capabilities can then be assessed based on services provided and service delivery performance. New or changing requirements or shifts in demand can then be traced to the affected capabilities. Reference Models One of the greatest challenges in Enterprise Architecture is knowing where to start. The complexity of modeling the entire enterprise seems overwhelming. Unfortunately many practitioners fall into the trap of building as-is models as the starting point for understanding requirements and assessing opportunities. This approach is fraught with disaster. Typically the same activities are conducted in many different ways across organizational silos, whether different lines of business, different departments, various locations or even individuals). It is both impossible and unnecessary to document all these variations. Proact uses Reference Modeling as the starting point for Enterprise Architecture. Reference models are generic representations of capabilities. Proact uses reference models in all four views of the Framework. For instance, categories of products in the Business View, service functions in the operational view, reference systems in the Systems View and technology services in the Technology View. The components in these reference models provide a taxonomy for all related enterprise architecture steps. They are used to introduce a common vocabulary across the enterprise. A given capability is represented once and only once within the reference model, regardless of how often that capability is used or exists across the enterprise. Reference Models show linkages and inter-relationships within and across models. For example the Service Function Models in the Operational View are linked to the Information Models in the Operational View through the representation of create and use relationships. These relationships are then used to identify Systems Families in the Systems View. Fortunately, these Reference Models are very common across specific industry sectors. Once developed, they are highly reusable and relatively stable. Proact maintains a library of reusable reference models to jump-start Enterprise Architecture initiatives for its customers. These Reference Models provide the basis for rapid assessments (not modeling) of current or baseline capabilities and for describing scenarios that reflect the strategic 4

13 directions and priorities of the enterprise. This leads to early identification of key strategic opportunities for business transformation. They also provide a wealth of insight for creating target architectures in each of the four views, since they embody sound principles of well-defined but decoupled components. Shareable Repository Another key challenge for Enterprise Architecture practitioners is what to do with all the models they create. Most end up in various drawing tools and, at best, get assembled into shared files. The Proact Toolkit is implemented on a very flexible modeling tool and repository. This tool contains all of the models and components represented in the Proact Framework. This tool and repository is the mechanism used to convey the reusable reference models. The Proact Toolkit supports the entire enterprise architecture community (architects, designers, and planners) by providing a collaborative environment for model development and review. All models and components are stored in an active repository and have associated attributes that can be populated by users or imported from other tools or systems. It also provides a powerful analysis capability through matrix generation and browsing features. To extend the use of these models and descriptions, the tool provides web publishing and document generation capabilities that can be maintained through the shared repository. 5

14 OVERVIEW OF THE PROACT FRAMEWORK AND REFERENCE MODELS The Proact Framework, as depicted in Figure 2, provides the superstructure for all models, their elements, and their relationships. Enterprise requirements flow downward through the four framework views, starting with the external market opportunities and stakeholder interests. The capabilities flow upward in response to these requirements, starting from the arrival of new technologies. The key determinant of business success is how well an enterprise can align their capabilities with the constantly changing requirements in all four views. Figure 2. The Proact Framework Proact s Reference Models provide the basis for identifying the complete set of enterprise capabilities based the requirements of the business with the incorporation of the impact from new technology. New technology capabilities can impact the business in a significant fashion, for example, the arrival of the web as a network technology providing capabi lities for interlinking systems and users for business collaboration through e-commerce. The reference models in each of the views are further described in the following sections. THE BUSINESS VIEW REFERENCE MODELS The Business View contains four different, but inter-related reference models. The Market Model is used to describe the relevant industry sector and classify the types of segments, solutions, and providers. The Product Model defines classes of products and possible sales and service channels. The Enterprise Relationship Model identifies the possible types of partnerships affecting enterprise structure and in-sourcing and outsourcing options. The Enterprise Resource Model identifies the types of workers, classes of facilities, equipment, and supplies, and any other assets required by the business. 6

15 The Market Model The Market Reference Model provides the taxonomy for market analysis. It begins by identifying the market sector and possible specialization (e.g., Consumer Products Retail) in which the enterprise operates. Within that sector, the target markets are broken into Market Areas (typically by geography, but technology reach may also be useful) and Market Segments (according to various demographic factors). For these segments, a set of Needs is identified, such as access to entertainment and interpersonal communications. These needs can be further qualified by defining various Environments where they occur, such as on the person and in a vehicle. The next component of the Market Reference Model specifies the types of Solutions available to meet these needs in these environments. For example, portable games, CD players, DVD players as solutions to providing access to entertainment on the person. Finally, the types of Providers of these solutions are identified, for example, Consumer Electronics Specialty Stores, Department Stores, Discount Outlets, Webbased Distributors, etc. With this taxonomy of market components and the ability to cross-reference these components, it is possible to structure various types of strategic use which include: Structuring demographic analyses and needs/preferences assessments; Tracking and predicting the market acceptance cycle for various product solutions; Assessing competitive strategies and directions; Evaluating possible merger and acquisition candidates; and Developing or refining market positioning strategies. The Product Model The Product Reference Model describes classes of Products (including services) to be considered for the enterprise. These product classes are related to the Solution types defined in the Market Reference Model. The Product Model provides a top-down classification to organize product portfolios. A second key element of the Product Reference Model is the type of Channels that are possible considerations for selling and servicing the associated products. For example, for consumer products, possible types of channels include Retail stores, Web-based Shopping, Call Center, Mail Order, and Door-to-Door. The Product Reference Model has numerous uses within the Proact Methodology, including: Developing Product Portfolio Strategies and Plans; Developing Product/Channel Strategies and Plans; Assessing Product Assortment; Conducting Competitive Analyses; Evaluating M&A Candidates Products; and Structuring Organizational Accountabilities for Product The Enterprise Relationship Model The Enterprise Relationship Reference Model provides a structure for describing partnering opportunities as well as obligations to shareholders and regulators. It identifies classes of Suppliers, External Channels (such as distributors or agents), Associations, Governments and Regulatory Bodies, Stakeholders, and other types of 7

16 external entities that require relationship management. This Reference Model, along with the Customers in the Market Segments of the Market Reference Model, defines the external relationships that must be addressed in the Operational View. The Enterprise Relationship Model has the following uses within the Proact Methodology: Identifying Partnering Opportunities and Candidates; Identifying Outsourcing Opportunities and Candidates; Defining Relationship Roles and Responsibilities; and Setting the Business Context for Operational Functions. The Enterprise Resource Model The Enterprise Resource Model provides a structure for describing the assets that are required by the enterprise. These assets include human resources, described in terms of worker classes, and physical resources, described in terms of facilities and work center classes, equipment, and supplies. This Resource Reference Model is used throughout the Proact Methodology to link functions, organizations, systems, and technology to their allocated resources. Specific uses include: Allocating People and Physical Resources to Service Functions; Performing Service Function Cost Analyses; Linking People to Work Centers to Functions to Systems; and Facility and Work Center Structure for Reusable Technology Templates. THE OPERATIONAL VIEW REFERENCE MODELS The Operational View has three important reference models that describe the essential capabilities required to operate in accordance with the Business View. The Service Function Model identifies the functional requirements, the Enterprise Information Model defines the information resources, and the Create/Use Matrix pulls together the end-to-end flow of information across the enterprise. The Service Function Model Functional Models are the central component of the Operational View of the Proact Framework. They provide a structured definition of all essential operational capabilities using a service-based approach. These Service Functions are: Independent of organization (cut across silos); Independent of where work is performed or who performs it; and Independent of how the work is performed i.e., process. Functions are grouped or clustered using functional affinities starting with the major functions of the Enterprise. Figure 3 shows the five Major Functions for a Retail Company. 8

17 Retail Enterprise, Inc. 1 Strategy & Planning 2 Demand Creation 3 Demand Fulfillment 4 Customer Experience Sales & Service 5 Enterprise Support & Resource Figure 3. Five Major Functions for a Retail Company These major functions are decomposed into Service Functions. For example, Major Function 4 Customer Experience Sales and Service, consists of five Service Functions: Channel Operations, Sales Creation & Solution Support, Customer Sales & Order, Customer Service Order Fulfillment, and Customer Retention. The other major functions are broken out in a similar manner. Each Function is defined as a Service Producing Entity not as a step in a process. Service Functions describe what capabilities are required not how they are performed. There is only one instance of a particular Service Function for the entire enterprise; regardless of how often that function exists throughout the organization or across geographic locations. Service Functions are created using Service Function Models. These models provide for the addition of External Entities, representing other enterprises, customers, or institutions with which the enterprise interacts. Service Functions and External Entities are linked by Service Flows. Figure 4 shows an example of the Service Flow Model for Major Function 4 Customer Experience Sales & Service 9

18 4.2 Sales Creation & Solution Support Configuration Generation Product & Solution Support Product Performance Intelligence Vendor/Provider Performance Customers Product & Solution Knowledge Transfer Custom Solution Configuration Lead Generation Product & Solution Profitability 2.1 Consumer Demand Creation Asset Loss Insurance Sales Intelligence Target Consumer Traffic Generation Return Approval/Denial Customer Returns Authorization Needs Qualification & Solution Proposal Determination of Solution Availability Solution Availability Assessment Sales Generation Solution Proposal Availability to Promise Service Availability to Provide/Deliver Merchandise Customer Order Processing Service Order 3.8 Fulfillment Sourcing Figure 4. Example Service Flow Model for Customer Experience Sales & Service Service Functions provide and receive services to/from other Service Functions as well as external entities. All Services are unique to only one function, resulting in minimal ambiguity and no duplication. These Service Functions can then be decomposed into Sub-functions where appropriate. Decomposition continues until Service Functions can no longer represent the capabilities; that is, when whats become hows. The Operational Reference Model only defines the whats. At their lowest level (typically 3 to 4 levels), Service Functions provide a set of Basic Service Functions (generally from 130 to 160). For example, the Service Function 4.2 Sales Creation & Solution Support shown in Figure 5 is decomposed into five Sub-functions: Needs Qualification & Solution Support, Configuration Generation, Product & Solution Support, Solution Availability Assessment, and Customer Returns Authorization. These are all Basic Service Functions. Later, during Target Architecture Development, Process Models are created for selected Basic Service Functions. For each Basic Service Function, information flows are added to link functions to the information subjects that they both create and use. Figure 5, shows an example of a Basic Service Function Model, Product and Solution Support, showing both Service Flows and Information Flows. 10

19 Products U U Product/Solution Prices & Rates Product Pricing Constraints U U Product Warranty Information Product Support Materials U C Customer Solutions Support Log Solution Templates U C Vendor/Provider Product Support Issues Product & Solution Support Product Performance Intelligence Vendor/Provider Performance Product & Solution Knowledge Transfer Customers Lead Generation Needs Qualification & Solution Proposal Figure 5. Example of Basic Service Function Service Function Reference Models have many uses, including: Generating the Create/Use Matrix for use in identifying Systems Families and Reference Systems; Defining Service-Oriented Performance Metrics; Assessing Operational Performance uncovering Best Practices; Providing Structure and Context for Process Modeling, an ideal starting point for introducing BPM; Providing Clear Delineation for Assigning Organizational Roles and Responsibilities; Conducting Structured Analysis through Resource Allocations (by Service Function); and Evaluating Merger and Acquisition candidates through use as a Capabilities Assessment Framework. The Enterprise Information Model The Enterprise Information Reference Model is the second model in the Operational View. It is used to define and cluster the information subjects that are required to operate the Business. The Information Model starts off by identifying major Information Domains based on information affinities. For example information pertaining to Markets, Customers, Products, Stores, etc. are grouped under respective domains, as represented in Figure 6. 11

20 Enterprise Information Model Enterprise Architecture Enterprise Strategy & Programs Enterprise Performance Stakeholder Relations Governance, Regulatory & Legal Markets Sales & Service Channels Product Design and R&D Products & Solutions Marketing & Advertising Forecasts Product Orders Transport & Warehousing Inventory Vendors/ Providers Logistics Customer Customer Orders & Payments Sales Creation & Solution Support Channel Operations Product Sales, Service & Parts Financial Real Estate & Facilities Suppliers Human Capital & Training Business Process & Organization IS/IT Requisitions, Equipment & Supplies Assets Printing & Photography Figure 6. Enterprise Information Model Top Level Each domain is then decomposed into its information subjects. This process is continued for three or four levels until the definition of subjects is about the same granularity as the Service Functions typically about 300 basic Information Subjects. Note that this is not a data model, but simply a structuring and definition of the information resources of the enterprise as seen from an operational perspective. As described above, these basic Information Subjects are then used on the Basic Service Function Model diagrams to graphically link the creation and use relationships between functions and information. The Create/Use Matrix The Proact Toolkit provides powerful analytical knowledge with matrix generation features using information contained on diagrams and stored in the repository. The Create/Use matrix is a good example of this analytical power. Each Basic Service Function contains the graphical connection of functions to the information subjects using connectors that indicate a create, use or modify relationship. From these connections, Proact automatically generates the Create/Use Matrix, listing all Basic Service Functions in the rows and all Basic Information Subjects in the columns. It places a C, U, or M in the cells corresponding to the connection between the Service Function and the Information Subject. The Create/Use Matrix is the critical link between the Operational Reference Models and the Systems Reference Models. The Proact Toolkit sorts the columns of the matrix by sequencing create relationships. This provides the basis for identifying clusters of functions and information that have a high affinity. From this analysis, Systems Families are discovered. They represent the automation potential for a unique group of Basic Service Functions and Basic Information Subjects, as represented by the partial create use matrix in figure 7. 12

21 Figure 7. Partial Create Use Matrix for Customer Experience & Sales Support THE SYSTEMS VIEW REFERENCE MODELS The Systems View contains three important reference models used to describe the capabilities for automating the information processing, management, and exchange in support of the Operational Capabilities described in the Operational Reference Models. The three models are the Systems Families, the Spider Diagrams that show information exchange between Families, and the Reference Systems that define the applications within Systems Families. Systems Families The Systems Families are extracted from the Create/Use Matrix. They form the toplevel structure for classifying systems. Figure 8 shows the 28 Systems Families for a Retail Enterprise grouped by the Major Service Functions. 13

22 Reference Systems Families for a Retail Enterprise Strategy, & Planning Demand Creation Strategy Systems Family Enterprise Architecture Systems Family Market Analysis Channel Development Relationship Resource Planning Business Operations Planning Systems Family Performance Product Marketing & Advertising Systems Family Demand Fulfillment Customer Experience - Sales & Service Supply Chain Planning Systems Family Supply Chain Operations Systems Family Channel Operations Sales Support Customer Sales & Order Vendor/Provider Fleet Services Execution Customer Retention Enterprise Support & Resource Business Operations Development IS/IT Operations Staffing Systems Family Compensation & Benefits Administration Facilities Supplier Asset Financial Systems Family Legal Office Administration Training Support Figure 8. Systems Families for a Retail Enterprise Systems Families provide the basis for developing Reference Spider Diagrams that show the information exchanges between Systems Families and the Reference Systems Models that define the individual applications that exist with the. Spider Diagrams The Systems Families contain all of the create relationships for their set of functions and information. However, there are many use relationships that fall outside of the 14

23 System Families on the Create/Use Matrix. These relationships translate into opportunities to exchange information between Systems Families. The Spider Diagram captures these information exchange opportunities between Systems Families. It places the in the center and shows all of the in-bound and out-bound information exchanges with other System Families around the periphery. An example of the System Spider Diagram is shown in Figure 9 for the Sales Support System Family. Supply Chain Operations Vendor/Provider Inventory Allocation Requests Transport Allocation Requests Inventory Available to Promise Inventory Levels Vendor/Provider Product Support Issues Product Product/Solution Financing Plans Product/Solution Rebates Product/Solution Prices & Rates Solution Templates Transport Available to Deliver Sales Support Vendor/Provider Product Catalog Customer Gift Registry Marketing Events Marketing & Advertising Product Pricing Constraints Product Support Materials Products Product Warranty Information Solution Template Configuration Rules Customer Requirements & Expectations Transport Allocation Requests Inventory Allocation Requests Customer Master Service Allocation Requests Customer Gift Registry Customer Sales & Order Customer Solution Environment Customer Solution Support Log Service Allocation Requests Service Resource Availability Services Execution Customer Loyalty Account Rainchecks Tax Rates Rainchecks Unallocated Service Capacity Customer Retention Relationship Channel Operations Figure 9. Reference Spider Diagram for Sales Support System Family These System Spider Diagrams have two important uses within the Proact Methodology: Representing the information exchanges between Systems Families as derived from the information exchanges between Service Functions; and Providing the input for developing Information Exchange Architectures between Systems Families in the Target Systems Architecture. Reference Systems The second part of developing reference models for the Systems View is to identify specific Reference Systems within each. These Reference Systems are distinct systems capabilities required to support the automation of the associated Basic Service Functions supported by that. Since each has an assigned and independent set of Information Subjects, these Reference Systems constitute the required set of Systems of Record for creating and maintaining these Information Subjects. 15

24 Like service functions, Reference Systems are generic. There is only one for each distinct System of Record regardless of how many different instances of that system exist in the current inventory. The Figure 10 shows an example of the Reference Systems for the Sales Support System Family. Product Information System Customer Gift Registry System Customer Return Authorization Product & Solution Availability Solution Availability System Returns Processing System Customer Return Rejection Vendor/Provider Product Support Issues Rainchecks Customer Product Configurations Solution Proposal Pricing System Solution Proposal Generation System Proposed Solutions Proposed Pricing Customer Requirements & Expectations Customer Gift Registry Interactive Demonstration System Selling Knowledge System Customer Solution Environment Figure 10. Reference Systems Within the Sales Support System Family Reference Systems have the following uses in the Proact Methodology: Providing the taxonomy for further classification of current systems within Systems Families; Providing the basis for determining where diversity is required and justified, based on different requirements (goal is to eliminate nonessential diversity from current systems); Providing the basis for determining the distribution or instance strategy for each target system, based on operational and systems requirements for replication and placement of information within the physical business operations; and Providing the foundation for Target Systems development to reflect this diversity and distribution, and creating the resulting information exchange architectures and migration strategies. THE TECHNOLOGY VIEW REFERENCE MODELS The Technology View contains two reference models. The Technology Services Reference Model is used to identify and classify the complete set of technology capabilities within the IT infrastructure, represented as services. The Technology Devices Reference Model is used to define the various types of physical and logical platforms that house these Technology Services. 16

25 Technology Services Reference Model The Technology Services Reference Model defines the relevant technology capabilities that the IT Infrastructure intends to provide. It becomes the base from which specific technologies are selected and defined as standards or target architectures for implementation. The Technology Services Reference Model is organized into categories that are layered in support of one another. Figure 11 shows the structure of the Technology Services Reference Model. Technology Services Model 5 Application Services 6 User Productivity Tools 4 Foundational Services 2 Server Platform Services 3 User Platform Services 1 Network Services Figure 11. Technology Services Reference Model Structure In the Technology Services Reference Model, connections to higher views in the Proact Framework occur through two service points support for applications and support for people. These are categorized as Application Services (5) and User Productivity Tools (6). Underlying these two categories supports both of them Foundational Services (4). These three categories define the set of Technology Services that are made available to Systems and Users. Underlying this set of services are additional Technology Services providing capabilities that are more oriented to the types of platforms and networks within the IT Infrastructure. Server Platform Services (2) and User Platform Services (3) define the underlying services needed to support Application Services (5), User Productivity Tools (6) and Foundational Services (4). These categories are, in turn, supported by Network Services (1), which include Local Area Networks (LAN), Metropolitan Area Networks (MAN) and an Enterprise Wide Area Network (WAN). This organization of the reference model allows the architect to take a service view of technology from top to bottom. Technology Services are defined within each category. Where there are many services, they can be clustered into a hierarchical decomposition structure. The lowest level services are known as Basic Technology 17

26 Services. The following two figures show this decomposition. Figure 12 shows the set of Technology Services within Foundation Services (4), some of which are basic. Figure 13 shows the decomposition of 4.01Systems. It contains only Basic Technology Services. 4 Foundational Services 4.01 Systems 4.02 Database 4.03 Clustering 4.04 Enterprise Directory 4.05 Access Control 4.06 Data Backup & Recovery 4.07 Data Integration 4.08 FTP Service 4.09 HTTP Service 4.10 Remote Computing 4.11 Encryption 4.12 Web Application 4.13 Data Replication 4.14 Conferencing 4.15 Messaging 4.16 File Compression 4.17 Task Scheduling 4.18 Runtime Environment 4.19 Web Services Platform 4.20 Context Filtering 4.21 Streaming Media 4.22 Storage Figure 12. Technology Services Within Foundation Services 18

27 4.01 Systems Change Configuration Event Monitoring Event Correlation Remote Shell Remote Consol Incident Intrusion Detection License Metering Performance Monitoring Release Security Auditing Software Distribution Output System Diagnostic Tools Threshold Monitoring Virus Protection Problem Quota Figure 13. Basic Technology Services in Systems Basic Technology Services are used for the following: Categorizing existing technologies within the IT Infrastructure; and Establishing target technologies for each service and rationalizing the choice of standards and related vendor products. Technology Devices Model The second reference model in the Technology View is the Technology Devices Reference Model. There are three primary categories of devices in the IT Infrastructure: User Devices, including all types of personal computing and communications equipment as well as output and display devices; Computing Devices, including many different types of server environments for applications; and Network Devices, including various types of switches and routers and associated transmission control equipment. Each of these categories can be decomposed into their respective types of devices. Figure 14 shows such a breakdown for User Devices. 19

28 Figure 14. Example of End User Devices Types These can be further broken down to identify specific Device Types, such as desktop computers, laptop computers, PDA s, etc. for User Computing Devices. Technology Devices have the following uses within the Proact Methodology: They become the physical platform for supporting combinations of Target Technology Services configured to provide a specific role within the IT Infrastructure; These Target Devices can be built on common basic platforms such as many server types built on a basic Windows or Unix platform; These Target Devices can also be clustered into standard Work Center templates, providing a highly reusable and scaleable technology architecture for distribution across similar work areas with common requirements; and They provide the building blocks for assembling Systems Technologies to support the full range of requirements of specific Application Systems and related Infrastructure Systems, such as , e-commerce, and video conferencing. With this complete set of Reference Models, built on the Proact Framework, Proact provides a holistic, integrated structure for analyzing and assessing the capabilities of the enterprise and for developing effective business solutions that are driven by strategic requirements. The next section explores the overall methodology behind the use of these reference models to create meaningful roadmaps for transformation programs. 20

29 OVERVIEW OF THE PROACT METHODOLOGY The Proact Methodology is a very comprehensive approach for using model-based planning techniques to simplify and focus complex decision-making for strategic investments during business transformations. The Proact Methodology leverages Reference Models to deliver opportunity assessments (business cases), target architectures (blueprints), and migration strategies (roadmaps) to govern enterprise transformation programs. The Proact Methodology is summarized in Figure 15. Figure 15. The Proact Methodology The Proact Toolkit provides support for the Proact Methodology to enable users to leverage reference models, develop target architectures, assess baseline capabilities, identify transformation opportunities, and create migration roadmaps. Each of the five major steps in the Proact Methodology is described below. REFERENCE MODELING Reference Modeling involves the customization and validation of any or all of the reference models to jump-start the enterprise architecture development process. Proact has developed an extensive library of reusable Reference Models ranging from Retail, Manufacturing, and Service Industries to Governments and Military Institutions that are provided with the initial license of the Proact Toolkit. Reference Modeling leverages the appropriate reference models to define the nature of the business and establish the context for all enterprise architecture activities. The Reference Models are used to focus the enterprise architecture activities. The Proact Toolkit is extremely flexible in applying various model-based planning methods to meet the specific organizational needs, priorities, and timeframes. Enterprise Architecture Programs may range from a major enterprise-wide target architecture development (such as a major systems and technology overhaul) to a very focused opportunity based on improving a specific area of operations. Enterprise Architecture Programs are positioned in both dimensions within the Proact Framework, vertically; depending on the range of business versus technical involvement and horizontally; depending on the scale of expected coverage, for instance, range of organization, functions, systems and/or technologies. 21

30 It should be noted that although Reference Modeling is important in launching the program, the real intended outcome of any Enterprise Architecture initiative is to produce well-developed road maps and associated blue prints (target architectures). These blue prints are used to define high priority transformation projects that will direct the Program Office and provide the governance necessary to ensure effective implementation to new or improved capabilities. These expected improvements are defined using the appropriate reference model components and relationships. Whatever the scope of the engagement, it is highly recommended that it include a representative set of models so the benefits of Enterprise Architecture can be demonstrated. BASELINE ASSESSMENT Baseline Assessment involves analyzing the current state of capabilities within a designated area of the reference model that is pertinent to the engagement. In all cases, current capabilities should be aligned with and categorized in accordance with the associated reference model. The Proact Toolkit allows for the capture of current capabilities under many of the reference models, particularly where diverse and overlapping solutions exist. As stated earlier, the Proact Methodology does not encourage nor require the creation of as-is models in order to proceed with assessment and Target Architecture Development. It is usually sufficient to characterize the current situation and use the knowledge of subject matter experts (SMEs) to map the current state to the structure and classification represented by the reference models. The Service Function Model is extremely useful for organizing baseline assessments. Each Basic Service Function (for those in scope) can be used as a point of reference for its defined capabilities. Appropriate performance metrics and measures can be established to focus efforts on areas where large improvements are possible or are demanded by business imperatives. This can lead to assessing the clarity of organizational accountabilities; consistency or reuse of business processes or best practices; availability and quality of required information; or effectiveness of related systems in supporting functionality and communicating outputs. Resources, (including people, equipment, and facilities), can be loaded against Basic Service Functions to create a quick and useful cost analysis. Similar techniques can be applied to other areas of the reference models. Baseline assessments are done to identify and qualify opportunities to improve on capabilities that are under-performing. They also provide input for considering the reuse of existing capabilities, where appropriate, to develop target architectures. OPPORTUNITY ASSESSMENT Opportunity Assessment flows hand-in-hand with Baseline Assessment. The Proact approach is to leverage the Reference Models to focus on highly productive areas for transformation. This involves assessing Basic Service Function capabilities against two criteria: Strategic Driver Relevance and Opportunity to Improve. Strategic Driver Relevance involves analyzing each Basic Service Function in terms of its ability to support the Strategic Drivers of the enterprise, which may change rather suddenly in dynamic business environments. 22

31 Basic Service Functions will contribute differently depending on whether the driver is improving customer service or reducing operating costs. Companies can place a higher focus on business growth or on margin improvements. Sometimes protecting the customer base from erosion to new competition becomes more important than the bottom line. Whatever the changing economic, market and competitive conditions, a small number of strategic drivers will emerge to provide guidance in prioritizing functions based on strategic impact. The second criterion is Opportunity to Improve. This comes from the Baseline Assessment of those same Basic Service Functions. The degree to which performance is deemed sub par (either to expected targets or to outside competitive benchmarks) will create a further ranking of Basic Service Functions. These two criteria can be charted using the convention 2X2 grid as shown in Figure 16. Those Basic Functions that score the highest in combined Strategic Driver Relevance and Opportunity Improvement scores are the ones on which to focus all energies. Figure 16. Plot of Basic Service Functions for Opportunity Prioritization Opportunities for impacting a given Basic Service Function are explored for all four views of the Proact Framework using the appropriate Reference Models. These opportunities may include: mergers and acquisitions (to acquire needed resources, market access, products or services, etc.); introducing new e-business channels; reorganizations; process re-engineering; new systems capabilities; upgrading IT infrastructure capabilities, performance and availability; and many others. 23

32 Once these opportunities are defined, the development of associated business cases as well as target architectures can proceed in parallel, with the impacts and costs of these target solutions prioritizing the business case development for the opportunity. TARGET ARCHITECTURE DEVELOPMENT The Proact Toolkit supports the development of target architectures from two different perspectives, proactive or opportunity-driven. An enterprise can choose to be very proactive and develop a set of Target Architectures, including Operational, Systems, and Technology based on the complete understanding of capabilities as reflected in the reference model. In this case, we are driven primarily by the implicit opportunity to clean up the complex and disorganized solutions that have evolved in the silo-based and relatively unplanned world before Enterprise Architecture. By removing unnecessary redundancies and simplifying interfaces (through using decoupled architectures) a more agile and cost effective means of supporting operational capabilities can be planned. Business priorities and available funding (supported by business cases) will drive the rollout of these new capabilities. The second perspective is more opportunity driven. An opportunity may pre-exist at the time of launching the Enterprise Architecture initiative. In this case, the target architecture is catching-up to the needs of the program; essentially reverse engineering the Reference Modeling, Baseline and Opportunity Assessment steps. This means a focus on quickly defining boundary conditions and assumptions for all of the capabilities that are in-scope. For opportunities that are generated by the Opportunity Assessment activity, all of the contextual information is provided. Target Architecture Development then proceeds with finding the best solution for the defined capabilities. The Proact Toolkit provides an extended set of models to support Target Architecture Development. Target Architectures are always linked back to their appropriate root capability in the associated reference model. In most cases there are specific models to support Target Architecture Development. Appendix A contains a summary of all of the models in each of the Proact Framework views. It describes their uses by Stage in the Proact Methodology. The various models used in creating Target Architectures are shown in the Target Architecture column. For example, in the Operational View, Process Models are used for creating Target Operational Architectures. The Systems and Technology Views provide a number of specific target models used for creating and navigating through the planned future capabilities. The Target Systems models identify the information exchanges between Target Systems, Data Stores and include the use of Integration Systems, such as Hubs, Workflow Systems, Business Objects, Data Warehouses and Portals. Figure 17 shows an example of a System Information Exchange Model. 24

33 Sales Associate Portal Customer Portal Integration Hub Query Input Set-up or Modify Registry Registry Status Query Integration Hub Relevant Pricing & Rates Sales Support Inventory Availability Request Product Information Requests Product Support Materials Relevant Product Updates Product Information System_T Input Gift Registry Data Store Query Customer Gift Registry System_T Gift Registry Purchase Pull_Information_Exchange_1 Product/Solution Rebates Product/Solution Financing Plans Product Pricing Constraints Transport Available to Deliver Product Information Requests Inventory Available to Promise Input Solution Proposal Generation System_T Local Product Information DS Solution Availability System_T Inventory Availability Request Unallocated Service Capacity Prior Order Info Request Cust Order & Raincheck Hold Request Customer Loyalty Accounts Customer Information Request Sales Tax Request Marketing Events Customer Needs & Solutions DS Solution Proposal Pricing DS Solution Proposal Pricing System_T Product Information Requests Customer Information Request Customer Requirements, Expectations & Env Feedback Customer Feedback ETL Selling Knowledge System_T Query Selling Techniques Games Library Interactive Demo Gaming System_T Query Customer Kiosk Pull_Information_Exchange_2 Query Interactive Demo Audio Visual System_T AV Library Computer Demo Library Interactive Demo Computer System_T Query Figure 17. System Information Exchange Model for Sales Support The Proact Framework contains a corresponding Target System Technology Model comprised of standard Target Devices and associated Networks. The work on Target Architectures for the Technology View starts with identification of target technology services for the IT infrastructure as a whole. It may be focused on a specific set of services needed for a given system program, however, it is critical that Technology Services and Devices be chosen as infrastructure components, usable across the broadest range of systems possible. Figure 18 shows an example of a Systems Technology Model for a specific Target System. 25

34 Figure 18. System Technology Model for the Product Information System It is important not to take enterprise target architecture models too deep. As the above examples illustrate, the role of enterprise system and technology architects is to create high level blueprints that focus mostly on external interfacing. The job of engineering these solutions is left to the systems engineers and designers as part of the Program Design, Acquisition, and Implementation activity. MIGRATION STRATEGY PLANNING This final step deals with merging high priority opportunities with associated target architectures, taking into account pre-requisites and business constraints. The creation of transformation programs should be driven from strategic business priorities and the associated business cases for identified opportunities. Many opportunities are associated with simplification programs that reduce the diversity of solutions in any given capability area. These can be process, system and technology standardization programs, all requiring a planned migration approach to achieve the desired level of convergence. The Proact Toolkit provides a Migration Model that can be used to show both Systems and Technology migration paths along with related dependencies. Other opportunities are associated with implementing new capabilities. In either case, it is essential to understand the full impact of all proposed changes to capabilities as traceable through the Proact Framework views and related target models. Complex transformations will require multiple stages of migration, perhaps involving transitional states. 26

35 The architects must define a set of inter-related target architectures in all four views for each migration stage. This involves determining all inter-dependencies so that any decisions to adjust program mix or manage any slippages in program delivery can be made with full awareness of the impact to other programs. The Migration Strategy leads to the formation of Programs and related Projects that are aligned with the Target Architectures, for the next stage of migration. Any changes to these target architectures or to staging of any dependent capability must be reviewed for architectural and business impact. In this way, Enterprise Architecture plays a valuable role in supporting the governance function for the Program Office. The handoff to the Program teams consists of a road map, created using the Migration Model, that explains the planned changes in capabilities and related solutions over time. A related set of Blueprints in the form of Target Architectures is also provided. 27

36 OVERVIEW OF THE PROACT MODELING TOOL AND REPOSITORY The Proact Modeling Tool and Repository provides a powerful technology environment for users of the Proact Methodology and related models. Proact has currently released Version 4.0 of the Proact Toolkit that addresses the needs of Enterprise Architects. This includes the development and update of all reference models, target architectures, and migration plans as discussed in the previous sections, including support for baseline and opportunity assessments. This capability is known as the Architect s Workbench. The current tool provides the modeling capabilities to create the Shared Enterprise Architecture Information Base that will serve as a repository for expanded uses relating to Program Planning and Solutions Design, through both extensions to the Proact Toolkit and by linking with other complementary tools. The current toolkit offers many advanced capabilities for supporting the environment for enterprise architecture. These include: A shared, networked-based environment; Support for all of the Models in the Proact Framework; Imbedded rules for Model creation; Flexible navigation within and between these Models through the Proact Portal; Ability to populate attributes of all items in all models through various means; Viewing of models and items with their attributes through various means; Ability to include graphics and images for improved presentation; Ability to extend, customize and tailor these Models; Advanced matrix generation and analysis; Automated report generation in PDF and Word formats; Automated Web publishing with search capability; and Various import and export capabilities to link with other databases and tools. These features combine to provide developers, reviewers, and users of the various Proact Architecture Models a very integrated environment for Enterprise Architecture. It is Proact s goal to extend the Toolkit capabilities so that the needs of Planners and Designers can be seamlessly integrated with those of enterprise architects to provide a complete environment for Business Transformation Planning and. 28

37 ENTERPRISE ARCHITECTURE TEAM The Architect s Workbench has been designed to support the Enterprise Architecture function across the entire client organization. To achieve the full impact and benefit of Enterprise Architecture, it is critical to establish a coordinating organization with enterprise-wide responsibilities. This Enterprise Architecture team need not be large, but requires that the production of architectural deliverables and resulting governance processes has a single point of coordination and accountability. The typical Enterprise Architecture Core Team consists of an overall manager who also can perform the role of Master Architect who oversees the change program to adopt Proact and staff and manage the Enterprise Architecture Team. The team itself consists of: Lead Business Architect; Capability Area Architects (typically five); Lead System Architect; Lead Technology Architect; Proact Methodologist and Team Support; and Proact Toolkit Systems Administrator and Model Support. Some of these roles may overlap so that the initial Enterprise Architecture team size may range from 6 to 10 key people. As the organization s use of enterprise architecture expands, so does the need for delegating accountability for the creation and management of specific capability area diagrams. This usually results in the enterprise architecture team to grow to as many as 30 to 50 people. A number of these additional staff are SME s that will be involved in the development and review of Enterprise Architecture deliverables, but they are usually drawn from existing Business and IS/IT organizations that may be dispersed throughout the enterprise. The Lead Business Architect takes ownership of the Business View and provides guidance and leadership to the Capability Area Architects. The Capability Area Architects are responsible for the Operational and Systems Architectures for their assigned Capability Areas. They will in turn form small teams to assist in producing the various deliverables at the different stages of methodology as well as establish review teams for participation in workshops and walk-throughs. This capability area approach works very well in combining the operational needs and opportunities with the corresponding system capabilities and opportunities, bringing the systems community into operational planning and vice versa. The Lead System Architect supports the Capability Area Architects in development of Target Systems Architectures, and, in particular, the use of Integration Systems. This role also includes integrating common system requirements for Technology environments and middleware for resolution with the Lead Technology Architect. The Lead Technology Architect is responsible for the Technology View deliverables. The development of Technology Service and Device standards is usually done in conjunction with SMEs drawn from the IT organization for the different technology areas. The Enterprise Architecture Methodologist becomes the in-house Proact expert on the team, understanding the Framework, Models and Methods and how to use the advanced features of the Proact Toolkit to product custom reports, web publishing, matrices and queries. 29

38 The Systems Administrator is responsible for managing the network Proact Toolkit operational environment. This includes assigning User IDs and Passwords, overseeing back-up procedures and regular report or web generation activities as well as resolving or reporting any operational problems or issues. This role also includes providing maintenance of the contents of the diagrams, items and attributes in support of the Capability Area Architects and other users to ensure consistency and quality of models. 30

39 SUMMARY The Proact Business Transformation Toolkit provides a unique capability to all enterprises that need to establish an Enterprise Architecture practice. Proact s holistic approach to Enterprise Architecture, built around the Proact Framework, provides that important linkage between the disciplines of business and IT planning. By applying the comprehensive reference models provided with the Toolkit, enterprises can jump-start their Enterprise Architecture programs and produce impressive quick results. The proven methods of producing the Enterprise Architecture deliverables for all steps in the Proact Methodology are captured in associated Practice Guides and related Training Materials. The Tool environment ensures that all architects are working around a common repository of models, items, and attributes providing an efficient and effective means of collaboration and communication of results and status. The report and web publishing capabilities of the tool provide the necessary outreach for the Enterprise Architecture deliverables beyond the development and review teams. The Proact capabilities are constantly evolving. An expansion to our library of reference models occurs with every engagement. New Toolkit features are added with every release. Our ability to link with other tools in the design and simulation areas is a key feature. Proact is committed to providing the most effective and practical environment for Enterprise Architecture and model-based planning. 31

40 APPENDIX A SUMMARY OF PROACT MODELS BY PROACT FRAMEWORK VIEW Proact Model Proact Methodology Stage Reference Assessment Target Migration Business View Market Used to classify market elements Current analysis using attributes and relationships Used to show desired future market positioning Related strategies to achieve target market positioning Product Used to define brands, product categories and classes, and channels Current analysis using attributes and relationships Used to show future products and relationships Related product strategies to achieve business goals Enterprise Relationship Used to define types of external business entities Current assessment of business partnerships and relationships Used to define desired partnerships and relationships Related merger, acquisition, partnership, and outsourcing strategies Resource Used to classify types of resources Current analysis using attributes and relationships Used to establish future resource levels and allocations Related resource development, acquisition, and funding strategies Business Transformation Projects Possible use for mapping current projects Used to identify B level programs and relationships Used to establish program timeframes and milestones 32

41 Proact Model Proact Methodology Stage Operational View Reference Assessment Target Migration Service Function Used to define essent ial operational capabilities and related service and information flows generates create/use matrix (Three representations) Population of attributes and evaluation of performance and relationships. Basic Service Functions are used as navigation points to Process Models (Reflected in Process and Target Systems Models) Information Used to classify and define required information subjects Possible use for assessing current information management capabilities (Reflected in Process and Target Systems Models ) Organization Used to describe current organization and relationships Used to describe future organizational structures and accountabilities Operational Scenario Used to validate operational reference models Used to illustrate breakdowns or shortfalls in current operational capabilities Used to define desired future operational capabilities Operational sequence Alternate representation for operational scenarios using UML techniques Alternate representation for operational scenarios using UML techniques Alternate representation for operational scenarios using UML techniques Business Component Alternate representation for operational requirements used only to map existing competing models Hierarchy Hierarchical representation of Service Function Model showing levels of decomposition Extended hierarchical representation to include process steps and work activities Process (BPMN) Possible use for assessing current processes Used to design target processes Gap analysis used for change management Service Design Represents current break-out of services by organization Used to design service delivery models for new orgs Operational Transformation Projects Used to identify O level programs and relationships Used to establish program timeframes and milestones 33

42 Proact Model Proact Methodology Stage Reference Assessment Target Migration Systems View Reference Spider Reference Systems Used to capture Systems Families identifies in create/use matrix. Serves as navigation point into other Systems View models Used to represent information exchange requirements between Systems Families as derived from create/use matrix Used to define Reference Systems and related information subjects within a Used as navigation point to current systems (Migration Model) Target Systems Families Exchange Target System Target Integration Systems Information Exchange Systems Sequence Possible use to map current systems information exchange architecture Used to identify desired information exchanges across Systems Families including use of Integration Systems Used to identify desired target systems and data stores including need for diversification and distribution Used to identify desired target Integration Systems, including Business Objects, Data Warehouses, Integration Hubs, and ETL Systems Used to identify desired information exchanges between target Systems and their Data Stores including use of Integration Systems Used to validate and demonstrate capabilities of the proposed target systems architecture to support operational scenarios Systems Migration Used to capture and assess current systems of all types based on Reference and Integration Systems Used to show changes in Systems occurring between stages in the Migration Plan, including convergence and retirements Systems Projects Used to identify S level programs and relationships Used to establish program timeframes and milestones 34

43 Proact Model Proact Methodology Stage Reference Assessment Target Migration Technology View Technology View Used to present classes of Technology Services. Serves as navigation point into other Technology View models Reference Technology Services Used to classify and define essential technology services for the IT infrastructure Used as a navigation point to current technology services Used as a navigation point to target technology services Reference Technology Devices Used to classify and define various types of devices required for the IT infrastructure Used as a navigation point to current device types Used as a navigation point to target device types Technology Services Used to capture current technology services Used to define target technology services Technology Device Relationship Used to capture current device types and service relationships Used to capture target device types and service relationships Network Used to establish target technology architecture templates for various network implementations, including facility specific networks Technology Used to establish target technology architecture for various work center templates and Systems Technology implementations Technology Migration Technology Projects Used to identify T level programs and relationships Used to show changes I Technologies occurring between stages in the Migration Plan, including convergence, retirements, and dependencies Used to establish program timeframes and milestones Proact Business Transformation Inc Updated March 31, 2005 Proact Business Transformation Toolkit Model Summary 35