Enterprise and Process Architecture Patterns

Transcription

1 Introduction Oscar Barros and Cristian Julio For more than 30 years, many authors have attempted to synthesize the knowledge about how an enterprise should structure its business processes, the people that execute them, the Information Systems that support both of these and the IT layer on which such systems operate, in such a way that they will be aligned with the business strategy. This is the challenge of Enterprise Architecture design, which is the theme of this paper. We will provide a brief review of the literature on this subject, with an emphasis on more recent proposals and methods that have been applied in practice. We also select approaches that propose some sort of framework that provides a general Enterprise Architecture in a given domain that can be reused as a basis for specific designs in such a domain. Then we present our proposal for Enterprise Architecture design, which is based on general domain models that we call Enterprise Architecture Patterns. The literature on Enterprise Architecture can be classified into professional produced by people for direct practical use in businesses, and academic developed by people in universities and other organizations without concern for immediate application. In the professional literature we have selected the following works: SCOR, which was originally centered on the supply chain and subsequently generalized to the whole enterprise [15]. This method has been developed by an association of companies and basically provides a structured classification, or it provides the general architecture of all the processes an enterprise of the type in the SCOR domain (enterprises with supply chain) should have. In Figure 1, we show the overall process structure [15] and, in Figure 2, some details of the Supply Chain SCOR. The method also gives, at the lowest level of process definition, metrics to measure performance and some information about links that connect processes. APQC, which is also a consortium of companies including IBM that provides technical support involved in the development of general architectures of processes in different domains, such as telecommunications, banks, automotive, and electric utilities that comprise a process classification framework [1]. A summary version of such a framework is given in Figure 3. 1

2 Supply-Chain Product M anagem ent Supplier processes Product Design DCOR Sales & Support CCOR Customer processes Supply Chain SCOR Level 0 A Value Chain With It's Supply Chain(s) Resources Line of Business Value Chain: E.g. Consumer PCs Supply Chain Process Customers Plan Source S1 Source Stocked Products Make M1 Make-to-Stock Deliver D1 Deliver Stocked Products Level 1 Processes and Level 2 Variations S2 Source MTO Products S3 Source ETO Proudcts M2 Make-to-Order M3 Engineer-to-Order D2 Deliver MTO Products D3 Deliver ETO Products Level 3 Activities for a single Level 2 Variation: S3 Level 1 Plan and Return Not Subdivided into Variations in This Diagram Return S3. Source ETO Product S3.1 S3.2 S3.3 S3.4 S3.5 Schedule Product Deliveries Receive Product Verify Product Transfer Product Authorize Supplier Payment 2

3 Figure 3. APQC General Framework FEA, which is an initiative of the government of the USA to provide an Enterprise Architecture for the whole of the public sector [18]. In Figure 4, the overall architecture is given and in Figure 5 we show some detail of the business architecture of FEA. Figure 4. FEA Overall Architecture 3

4 Figure 5. FEA Business Reference Model CBM of IBM [13], which is not branded as an Enterprise Architecture but as the structure of business components an enterprise should have. They have a general version, shown in Figure 6, and different versions for several industries. From such a figure is clear that the components of the structure can be assimilated to a process structure. TOGAF, which is a framework for developing an Enterprise Architecture, proposed by The Open Group and based on an initiative of the US DoD [16]. The Enterprise Architecture is composed of four architectures: Business, Applications, Data, and Technical, for which an Architecture Development Method (ADM) was proposed, as shown in Figure 7. We can appreciate that TOGAF is more a methodology than a general enterprise architecture. Even though Business Architecture is included in ADM, TOGAF is mostly oriented for use in Information Systems development. 4

5 Figure 6. IBM CBM Figure 6. IBM CBM Figure 7. TOGAF Architecture Development Method 5

6 We now review a few academic approaches: MIT s methodology, which links Enterprise Architecture with strategy, providing a conceptualization of different operating models that determine the architecture [14]; The classification of operating models is shown in Figure 8, from which four types of enterprise structures can be derived: Coordination, Unification, Diversification, and Replication. Then, depending on the operating model one chooses, a corresponding architecture is selected. Figure 8. Business Operating Models 6

7 ANSI/IEEE , which is a standard to describe the architecture of software intensive systems, developed by the IEEE Computer Society [12]: It establishes a conceptual framework, shown in Figure 7, for talking about architectural issues of systems, like the structure of its components, their relationship to each other and to the environment, and to the principles guiding its design or evolution. Figure 9. IEEE Conceptual Framework All of the approaches above attempt to describe an enterprise in terms of the structure of the process components needed to run a business. Most of them emphasize components classifications and do not explicitly consider relationships among them. Our experience in Enterprise Architecture and process design is that the most important factor is the design of the relationships that coordinate all the components of an architecture and make them perform as a system. For such a design, it is very useful to have a general architecture model that explicitly gives the relationships the processes and other elements they should have. The approach we will describe below provides such a model of Enterprise Architecture with relationships that we call an Enterprise Architecture Pattern. These patterns have been under development since 1995, independent of all the methods reviewed above, and several publications in Spanish, starting in 1998, have circulated them in Latin America [2,3,4,8,9]. Publications in English started in 2004 [5,6,7,10,11]. Our approach is a mixture of the professional and academic versions, since, although it has been developed at a university, it has been applied to hundreds of real life 7

8 projects. This has allowed the testing of the proposed methodology and its continued improvement, based on the generated experience. The Basis of our proposal Our proposal is based on the formalization of knowledge derived from many practical projects of business design, performed by graduate students of the Master in Business Engineering (MBE) at the University of Chile in collaboration with the most important Chilean firms. By 1998 we had posited that all processes performed in an organization are part of one of the following types [2,6,7]: Macroprocess 1 (Macro1): Collection of processes for the production of the goods and services the firm offers to its customers, which starts with their requirements formulation, and finishes with the satisfaction of the requests. We call this macroprocess Value Chain, adopting a definition slightly different from Porter s, which includes other processes inside it, such as the development of new products, which we include as part of another macroprocess. Macroprocess 2 (Macro2): Collection of processes for the development of new capabilities that the firm requires to be competitive, such as new products and services, including business models; necessary infrastructure to produce and operate those products, including IT infrastructure; and new business processes to assure operational effectiveness and value creation for customers, establishing, as a consequence, systems based on proper IT. Macroprocess 3 (Macro3): Business planning, which contains the collection of processes that are necessary to define the direction of the organization, in the form of strategies, materialized in plans and programs. Macroprocess 4 (Macro4): Collection of support processes that manage the resources necessary for the proper operation of the other macroprocesses. Four versions of these processes can be defined a priori: financial resources, human resources, infrastructure, and materials. We call these types macroprocesses because they contain many processes, subprocesses, and activities that are necessary to produce key products, such as the ones offered to clients strategic plans, new products, and so on. Recently and independently, several proposals of what we call macroprocesses have been made, almost identical to ours. For example, a process structure proposed by HP and shown in Figure 10, based on SCOR [15], has the following macroprocesses: Design Chain, similar to Macro 2; Business Development, to Macro 3; Enabling Processes, to Macro 4; and Supply Chain and Customer Chain that together form Macro 1. 8

9 Level 0. Organization Divided into 4 Major Domains Resources Organization Design Chain Enabling Processes Business Development Customer Chain Customers Supply Chain Process Level 1 Processes Plan Plan Plan Plan Integrate Deliver Contact Research Design Amend Source Make Return Analyze Develop Revise Relate Sell Assist Level 2 Variations Level 2 Processes: New Technology, New Product, Product Revision Level 2 Processes: Made to Stock, Made to Order, Engineered to Order Level 2 Processes: Expansion, Extension, and Creation Level 3 Subprocesses in Relate to Named Account Level 2 Processes: Relate to Intermediary, Relate to Grouped Account, Relate to Named Account Level 3 Subprocesses R3.1 Receive, Validate & Approve R3.2 Assign Account Team R3.3 Define Engagement Model R3.4 Obtain Customer Needs R3.5 Establish Customer Profile R3.6 Publish Business Rules R3.7 Release to Sell Level 4 Activities Specific to Particular process and company Metrics and Best Practices for Subprocesses Tables for Each Process and Subprocess Information on specific metrics and best practices to implement this subprocess Figure 10. HP process structure 1 1 Taken from a presentation by Paul Harmon 9

10 Also, the classification proposed by APQC in Figure 3 can be assimilated to our macros in the following way: Develop Vision and Strategy is similar to Macro3; Design and Develop Products and Services is part of Macro2; and Sell Products and Services, Deliver Products and Services, and Manage Customer Service conform to Macro1; and Management and Support Services is similar to Macro4. Our approach and proposals such as SCOR, APQC, and etom [17] have in common that they provide reference models and general process structures, in given domains, as a starting point to design the processes of a particular case. However, and as it was mentioned before, the main difference between our proposal and other approaches lies in the explicit specification of the relationships among the processes at different levels of detail that allows us to show with more realism and precision how the process model is expected to work in practice. For each of the macroprocesses defined above we have developed detailed process patterns, which give, in several levels of detail, the processes, subprocesses and activities they should execute in order to produce the required product. Patterns are normative in that they include what is recommended as best practices and what we have found that works in reality. They also include the relationships that should exist among processes, subprocesses and activities. These patterns have been documented in several books (in Spanish) [3,4] and papers (in English) [5,6,7,10,11]. They have been validated in hundreds of practical projects where they have been used as a starting point to perform process redesign. This has allowed us to gradually improve these patterns with the experience of more than ten years of projects [8,9]. The four macroprocess patterns can be combined into different structures depending on the business type. We call these structures Enterprise Process Patterns, and we will detail them below. Now an Enterprise Process Pattern is part of an Enterprise Architecture Pattern that can be modeled, in the style of ANSI/IEEE , as in Figure 11. In some of the designs of the processes in an architecture, the relationships of such a model are made explicit, which we will illustrate when we explain different Enterprise Process Patterns and apply them to the designing in specific cases. 10

11 Figure 11. Class Model for Enterprise Architecture Process Architecture Patterns The basis for any architecture pattern is in the relationships among the macroprocesses defined above, since any process structure, according to our premise, is a combination of such macros. At the most basic level the general structure of relationships among these processes, which we proposed in 1998 [2], is the one shown in Figure 12. All the architecture patterns we define below are based on this general structure that shows the interaction of the different macroprocesses with markets, customers, and suppliers by means of information flows and the internal flows, such as Plans coming from Macro3 that direct the behavior of the other macroprocesses; Needs that request Resources to Macro4; flow of Resources and feedback flows of Ideas and Results to monitor processes and initiate new plans in Macro3 and change in capabilities in Macro2. Since our patterns model business practice, they must represent different business structures, also called business architectures. For this, we define structure types as follows: Businesses with just one value chain of the Macro1 type. 11

12 Businesses with several value chains, each of which operates independently (Diversification of Figure 8). Businesses that have several value chains, each of which operates independently, but may share some supporting central services, such as business planning (Macro3), product design (Macro2), and financial, IT and human resources services (Macro1); they may also use instances of centrally defined processes in their operations (Coordination and Replication of Figure 8). Businesses that have several value chains that share several of their internal processes and that also share supporting central services (Unification of Figure 8). These Process Architecture Patterns types are shown graphically in Figure 13, where we represent, in a simplified way, the structure of the basic pattern of Figure 12, which is integrated in such patterns. These types can be mixed to form many other structures for example, an architecture that is partially of the Diversification type but has some business that follows the Unification type. Each of these structures will have different architecture patterns, some of which we will detail below. But the interesting thing is that they all can be derived from the basic structure we presented at the beginning of this section. Information Business Planning (Macro 3) Plans Ideas and Results New Capabilities Development (Macro 2) New Capabilities Information Enterprise Requirements Value Chain (Macro 1) Products or Services Customer Needs Customer Suppliers Inputs and other Resources Resources Ideas and Results Support Resource Management (Financial, HR, Infrastructure) (Macro 4) Resources Resources Figure 12. Basic Process Architecture Pattern 12

13 N of Value Chains Share of Services None Central Services Internal Services Macro 3 1 Macro 2 Macro 1 Macro 4 Diversification (Figure 8) Coordination and Replication (Figure 8) Unification (Figure 8) Macro 3 Macro 3 Macro 3 Macro 2 Macro 2 N Macro 1 Macro 4 Macro 2 Macro 1.1 Value Chain 1.1 Macro 3 Value Chain 1.N Macro 2 Macro 1 Macro 1.N Macro 4 Internal Shared Service j Macro 4 Macro 4 Figure 13. Process Architecture Pattern Types The case we have developed in more detail so far, because of its relevance to the projects we have worked on, is the Unification one. For this, we have the pattern of Figure 14, which we call Shared Services Architecture Pattern. The basic idea of this pattern is to factor out of the different value chains (i) several services (j) that can be centralized because of economies of scale or scope, transaction costs, agency advantages, and other economic reasons [2,4,10] for example, credit authorization for several banking business lines, supply management for several productive businesses, and IT support in any business with several product lines. We will show a case of application of this architecture in a sequel to this paper. We notice that some of the shared services can be externalized to suppliers. 13

14 Macroprocess 3 Information Business Planning Business Plans Information Enterprise Shared Services Process Architecture Macroprocess 2 Macroprocess 1 Customer Value Chains and Services Information, and Ideas and Results Requirements Results New Capabilities Development New Capabilities Value Chain i Internal Service Provided Service Request Action Plans Internal Shared Service j Needs and Information of Resources ing Actions and Responses to Clients Product or Service Customer Macroprocess 4 Resources Support Processes (Financial, HR) Resources Resources and Resources Information Suppliers External Service Request External Shared Service k Provided Services Information Service Provided Figure 14. Shared Services Process Architecture Pattern (Unification of Figure 8) Application and Experience The approach we have presented above has been applied to the architecture design of many enterprises among others, a large mining company, one of the leading telecoms in Chile, and an international airline. But the most important effort has been dedicated to developing an architecture for public hospitals in Chile, which has been used to define and execute several process redesign projects that have produced very significant results in terms of better service to patients and an optimum use of resources. This hospital case will be detailed in a follow up paper. References 1. APQC, 2. Barros, O. Modelamiento Unificado de Negocios y TI: Ingeniería de Negocios, Documento de Trabajo CEGES Nº 5, 1998, Departamento Ingeniería Industrial, Universidad de Chile. 14

15 3. Barros, O. Rediseño de Procesos de Negocios Mediante el Uso de Patrones. Dolmen, Barros, O. Ingeniería e-business: Ingeniería de Negocios para la Economía Digital. J. C. Sáez Editor, Barros, O. A Novel Approach to Joint Business and Information System Design, Journal of Computer Information Systems, Spring Barros, O. Business Process Patterns and Frameworks: Reusing Knowledge in Process Innovation, Business Process Management Journal, January Barros, O. Business Process Architecture and Design, BPTrends, May 2007,. 8. Barros, O. blog.obarros.cl 9. Barros, O Barros, O., C. Julio. Integrating Modeling at Several Design Abstraction Levels in Architecture and Process Design, BPTrends, Oct 2009,. 11. Barros, O., S. Varas, Frameworks Derived from Business Process Patterns. Documento de Trabajo CEGES Nº 56, 2004, Departamento Ingeniería Industrial, Universidad de Chile. Available Hilliard, R All About IEEE Standard /docs/all-about-ieee-1471.pdf. 13. IBM Business Consulting Services. The Component Business Model (CBM). www- 935.ibm.com/services/uk/igs/html/cbm-bizmodel.html. 14. Ross, J., P. Weill, D. Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business School Press. June Supply Chain Council, Supply-Chain Operation Reference Model The Open Group TOGAF Version 9, The Open Group Architecture Framework (TOGAF). Evaluation Copy. Document Number: G TM Forum, Enhanced Telecommunication Map (etom) White House E-Gov, Federal Enterprise Architecture, Author Dr. Oscar Barros (Ph.D.U.Wisconsin) is the director of the Master in Business Engineering (MBE) at the University of Chile and is a businessman in the IT industry in Chile. He has written ten books with more than 100,000 copies sold. He has also published widely in international scientific and technical journals. Dr. Barros has also been active in consulting, having directed many large-scale projects on Operations Research Modeling, Information Systems Development and Business Process Innovation. He is currently working on the development of business architecture and process patterns and supporting software; results of this work can be seen at and blog.obarros.cl. 15