Structuring software cities a multidimensional approach

Transcription

1 Structuring software cities a multidimensional approach Andreas Hess, Bernhard Humm 1, Markus Voß, Gregor Engels 2 sd&m AG, Carl-Wery-Str. 42, München, Germany {Andreas.Hess, Bernhard.Humm, Markus.Voss, Gregor.Engels}@sdm.de 1 B. Humm also Darmstadt University of Applied Sciences, Germany 2 G. Engels also University of Paderborn, Germany Abstract. IT application landscapes alias software cities of large enterprises comprise tens or even hundreds of IT applications. Structuring software cities into domains is an important task of enterprise architects. The quality of the resulting domain model is crucial for the success of enterprise architecture management and an important tool for the governance of the development of an enterprise s application landscape. This paper presents a method for constructing domain models based on business functions, business objects, and business dimensions. The method has been validated in numerous industrial projects. Keywords: Enterprise architecture, enterprise architecture management, application domains, application landscape, business architecture, value chain, service oriented architecture. 1. Introduction The quality of software architecture in the large determines the structure of an enterprise s application landscape. Application landscapes for large enterprises sometimes consist of hundreds of applications. If one equates the architecture of an individual software system with the architecture of a building then the architecture of an application landscape equates to the structure of a city. Like real cities, software cities need city planning to provide high quality support for the enterprise s business processes and flexible adaptability to changes in the enterprise s ecosystem. Software city planning and the development of zoning maps for software cities are the tasks of enterprise IT architects. As a discipline, enterprise architecture management addresses the structure of an application landscape (software city) as well as the management processes needed to govern the development of an application landscape from an as-is situation to a target structure. Fig. 1 shows the application landscape of a bank as an example. It shows the applications as components of the application landscape with their interfaces, but also a base structure (the colored boxes) used to group the applications. In this paper these colored zones of an application landscape are called domains. They define a high

2 2 Andreas Hess, Bernhard Humm, Markus Voß, Gregor Engels level structure for the application landscape, the domain model that can be used as a tool in enterprise IT architecture management. In this paper, we present a method for constructing domain models for application landscapes that uses multiple dimensions (customers / markets, products, vertical range of manufacture, access channels to customers) to deduce the domains. This method has been proven in industrial practice. Fig. 1. Domain model and IT components of a bank This work is part of the research effort Quasar Enterprise which has been conducted at sd&m Research and sd&m IT Consulting for more than three years. Quasar Enterprise distils the experience from enterprise architecture management and systems integration in numerous industrial projects with a total effort of more than 100 person years. The paper is structured as follows: in Section 2, we introduce domain models. Section 3 defines the input for the method for constructing a domain model. This method is then presented in Section 4. Section 5 gives an example, followed by project experience (Section 6) and related work (Section 7). Section 8 concludes this paper.

3 Structuring software cities a multidimensional approach 3 2. Software cities and domains 2.1 Terminology Application domains are the districts and suburbs of software cities. We use the term domain knowing that (like component) it is heavily used in different contexts with various meanings (e.g. domains in data modeling, domain specific languages, domains in component models like.net, or business domains like banking). We chose to stick to it since it is widely established in the enterprise architects community [1], [2], [3]. The terms software city and application landscape are often used in publications on enterprise architecture as synonymous metaphors for the structure of an enterprise s IT application portfolio. Examples are [4], [5]. For the rest of this paper we will use the term application landscape. Application domains represent clusters of services and managed information. They provide the top level structure of the application landscape. Domains may be refined by sub domains. In Fig. 1, the application domains are represented by the differently shaded areas of the application landscape. Domains group logical components that are bundles of services the white boxes in Fig. 1. The logical components are implemented using physical applications (commercial off-the-shelf or custom built) that are integrated using an appropriate integration infrastructure, e.g. an enterprise service bus (ESB). The structure of the domains forms the application domain model of the enterprise. Depending on the industry and the individual enterprise a domain model typically consists of approximately top-level domains. In this paper we do not address groups of application landscapes, which would be a possible option for enterprise architecture management for multinational corporate groups. We also focus on the top-level domain structure. Domain / sub domain structures and component / subcomponent structures are possible and the presented method applies accordingly for the different levels of granularity. 2.2 Why is an application domain model important? Domain models can be used by enterprise architects as a tool to define the target application landscape at the enterprise level. Large Enterprises like Credit Suisse [1] or Deutsche Post [2] follow the strategy of a managed evolution of their application landscapes from an as-is situation to defined target. The managed evolution approach aims to define smaller IT projects with positive business cases and limited scope, so as to provide short-term business benefits while complying with a standard target. The evolution is managed, because enterprise architects govern the development of the application landscape. In this way domain models are used for strategic planning as well as for the operational management of an enterprise s IT project portfolio.

4 4 Andreas Hess, Bernhard Humm, Markus Voß, Gregor Engels A domain model also helps to establish business ownership for applications and services as it links the business process architecture and the IT application architecture of an enterprise: domains represent sets of applications and databases that are managed as units for business reasons, instead of organizing them, e.g., by types of IT platforms. Documenting application landscapes, another central part of enterprise architecture management, relies heavily on graphical and intuitive visualizations. Planning, deciding, and controlling with respect to measures on the application landscape all benefit from such visualizations, called software maps [6], [7]. Similar to the concept of maps used in cartography, a software map is composed of a base map and several layers. Fig. 1 is an example of such a software map. Based on a defined domain structure, software maps can be used to visualize the delta between an as-is situation and the target situation defined by the domain model: The target domain model is used as a base map together with a mapping of the as-is application components on an individual layer. Domains can also be helpful for more technical aspects of architecture management as they provide the starting point for the definition of rules for the design of components, e.g., components must not span domain boundaries the design of interfaces, e.g., loose coupling for interfaces used across domain boundaries the use of technologies for application integration, e.g. mandatory use of an enterprise service bus for the integration of components in different domains 3. Required input for constructing an application domain model The method for constructing an application domain model deduces the domains from a set of input parameters that are part of the enterprise s operating model. 3.1 Business functions Application landscapes are structured according to the business of an enterprise not according to technology. Hence, the most important input for modeling domains are the business functions of the enterprise. By business functions we understand a toplevel grouping of the main business activities that can be found in the value chain of an enterprise. Identifying business functions is the task of business analysts. They can be derived from the top level business processes and the enterprise s organization. We distinguish between core business functions and management & support functions. Core business functions directly facilitate the business strategy of an enterprise whereas support functions only indirectly facilitate it. Business functions can be structured hierarchically. We aim at about 5-10 top-level core business functions. Figure 2 shows typical business functions of a bank.

5 Structuring software cities a multidimensional approach 5 Core Business Functions Product Development Marketing Sales & Advice Operations Support Service Order Order Execution Settlement Custody Accounting & Booking & Support Fcts. ERP Risk Compliance Treasury Accounting Controlling Human Resources Fig. 2. Business functions of a bank (examples) A bank comprises the following core business functions: Product development, e.g., the development of new products and services Marketing, e.g., performing campaigns Sales & advice, e.g., advising retail customers on home loans Operations, e.g., selling stocks on the stock exchange (order execution) Support service, e.g., sending monthly account statements to customers & support functions are classic enterprise resource planning functions (e.g., accounting, controlling, human resources), as well as risk management, compliance, treasury etc. Since business functions are top-level and coarse-grained, they are similar for different businesses. For example, an automotive manufacturer also performs the business functions of product development, marketing, sales & advice, operations (production), and support service. 3.2 Business objects Business objects are the most relevant top-level information items of an enterprise. In our banking example we identify the following: Business Partner, e.g., a retail banking customer Product, e.g., savings, checking accounts, loans Account, e.g., the account used for booking of payments Contract, e.g., the result of opening a checking account Order, e.g., a bank transfer from one account to another Top-level business objects are coarse-grained. We aim at about 5-10 business objects.

6 6 Andreas Hess, Bernhard Humm, Markus Voß, Gregor Engels Business objects are typically used throughout the enterprise. However, some business objects are particularly relevant for individual business functions. These associations between business objects and business functions need to be analyzed. In Fig. 3, this is visualized with a tick at the cross-over between business object and business function while the simple usage of a business object by a business function is represented by a bar symbol. Product Development Marketing Sales & Advice Operations Support Service Business Partner Product Contract Order Account Fig. 3. Business objects and business functions The business objects product and order are particularly relevant for the business functions product development and operations, respectively. The other business objects are particularly relevant in more than one business function. Identifying the main business objects and assigning them to business functions is the business analysts task. As for business functions, similarly named business objects are used in different businesses. For example, an automotive manufacturer also has business partners, products, contracts, and orders. 3.3 Business dimensions The operating model of an enterprise is typically shaped by the following question: Which products are sold to which customers / markets using which vertical range of manufacture? A bank may answer this question in the following way. The portfolio comprises the following products: Account-based products, e.g., savings bank accounts Loans, e.g., home loans Securities, e.g., stocks, bonds Payments, e.g., bank transfers Products are sold to the following customers / markets: Retail banking customers, i.e., private customers Corporate customers, i.e., companies

7 Structuring software cities a multidimensional approach 7 The following value-creating operations are / are not carried out by the enterprise: Product development, marketing, sales, and support service are completely performed within the enterprise. Payment transaction banking is not performed within the enterprise but is being outsourced to a partner corporation. Credit administration and securities settlement and custody are candidates for possible process outsourcing in the future. Both are subtasks of operations. Often in this context, the term business value creation chain or shortly value chain is being used. The length of the value chain defines which value-creating operations are carried out by the enterprise and which are carried out by partners. Categories like products, customers / markets or length of the value chain we call business dimensions. See figure 4 for the banking example. Customers / Markets Retail banking customers Corporate customers Branch Self-service E-banking Call Centre Products Account-based products Loans Securities Payments (depending on business function) Customer Access Channels Fig. 4. Business dimensions of a bank Length of Value Chain The dimensions customers / markets, products and length of value chain are relevant to most businesses. Additionally, there may be business-specific dimensions. For a bank, the following customer access channels may be relevant: Branch, i.e. agencies where clerks directly service customers face-to-face Self-service, e.g. automatic teller machines E-banking, i.e. offering banking products via internet portals Call-center, where clerks service customers via telephone Again, identifying the relevant business dimensions and their values is the task of a business analyst. We aim at about 3-5 business dimensions with about 2-5 values each. The values of the dimensions are directly linked to the business strategy of the enterprise. E.g., a direct bank s strategy is to focus solely on the customer access channels e-banking and call center.

8 8 Andreas Hess, Bernhard Humm, Markus Voß, Gregor Engels Business functions, business objects and business dimensions of the operating model form the input parameters for our method to deduce the domains. It is presented in the next chapter. 4. A method for constructing a domain model Structuring application landscapes by domains is the task of enterprise IT architects. Finding a domain model of high quality is crucial for enterprise IT architecture management. It requires a high level of expertise, both in the business and in domain modeling. Constructing a domain model in practice is a highly incremental process. It is top-down from the business strategy as well as bottom-up from the existing application landscape. It requires a lot of communication and alignment since the final domains and their names must be understood and used by numerous stakeholders. Insofar, there cannot be a method for constructing a domain model which can be applied mechanically and in an uninformed manner which nevertheless leads to a domain model of high quality. However, the experience from numerous domain modeling projects shows that there are common patterns, particularly in the top-down driven parts of the process the bottom-up driven parts are usually specific to the application landscape under consideration. The following method for constructing domain models comprises those patterns in form of concrete steps. The input for this method comes from business analysts as described in the last chapter: Business functions, divided between core business functions and management & support functions Business objects and their associations with business functions Business dimensions and their values according to the business strategy Given this input, the method is as follows. 1. Core business functions: Take the top-level core business functions as initial domain candidates. 2. Business dimensions: Split domain candidates according to the characteristics of one or more business dimensions if their handling substantially differs from a business point of view. Iterate this step as long as the business strategy demands further differentiation. 3. Business objects: Take the top-level business objects as domain candidates. Assign the handling of business objects that are mainly associated with a particular domain candidate (from a business function) to this domain candidate. Make new domains for all business objects that are not associated with a particular domain candidate (from one or more business functions). 4. & support functions: Make domains for all management & support functions. They usually follow the structure of modules that enterprise resource planning (ERP) software uses. 5. Finalize: The domain candidates become the final domains. Find meaningful domain names that are understood and accepted throughout the enterprise if not already done during the iterations. Find a meaningful and intuitive graphical

9 Structuring software cities a multidimensional approach 9 representation of the domain model. Check for completeness of the model by mapping the physical as-is applications to the domains. 5. Example We demonstrate the method for constructing a domain model using the bank example. Step 1: Core business functions In the first step, the top-level core business functions form the initial domain candidates. See figure 5. Product Development Marketing Sales & Advice Operations Support Service Fig. 5. Step 1: Core business functions Step 2: Business dimensions The second step is the most difficult step since it requires fundamental knowledge of the business strategy of the enterprise. According to the business strategy of the bank, the business function sales & advice is to be performed differently along the business dimension customers / markets, e.g., for retail banking customers and for corporate customers. Therefore, the domain candidate sales & advice is split into two domains. The resulting domain candidates are named retail banking and corporate banking. See figure 6. Sales & Advice Business dimension customers / markets Retail banking customers Corporate customers Retail Banking (sales & advice for retail banking customers) Corporate Banking (sales & advice for corporate customers) Fig. 6. Splitting sales & advice according to customers / markets The business function support service differs according to the business dimension customer access channels. The resulting domain candidates are named branch systems, self-service, e-banking, and call centre. See figure 7.

10 10 Andreas Hess, Bernhard Humm, Markus Voß, Gregor Engels Support Service Business dimension customer access channel Branch Self-service E-banking Call centre Branch Applications (Support service via branch) Self-Service (Support service via self-service facilities) E-Banking (Support services via e-banking) Call Centre (Support service via call centre) Fig. 7. Splitting support service according to customer access channels Additionally, the business function operations differs according to both business dimensions value chain and product. See figure 8. Business dimension length of value chain Operations Order Order Execution Settlement Custody Accounting & Booking Business dimension product Accountbased products Loans Securities Core banking (Order management, order execution, settlement, and custody for account-based products) Credit Approval (Order management and order execution for loans) Securities Trading (Order management and order execution for securities) Credit Administration (Settlement and custody for loans) Securities Custody (Settlement and custody for securities) Accounting & Booking (Accounting and booking for all products) Payments Payments Order (o.m. for payments) Payment Transaction (Order execution, settlement and custody for payments) Fig. 8. Splitting operations according to product and length of value chain The business function operations differs substantially for the different products and therefore different horizontal domain candidates are introduced. However, accounting & booking can be treated identically for all products. Therefore, one vertical domain candidate is being introduced. The split of the execution of payments along the value chain is motivated by the business strategy to outsource the payment transaction banking to a partner corporation. For similar reasons the processes chains for loans and securities are each split into two domains. Step 3: Business objects In this step, new domain candidates are introduced for business objects that are associated with more than one top-level business function. So, the new domain candidates business partner management, contract management, and account management are introduced. See figure 9.

11 Structuring software cities a multidimensional approach 11 Business Partner (handling business partner objects) Contract (handling contract business objects) Order (handling order business objects) Account (handling account business objects) Fig. 9. New domain candidates for business objects The business object product is used by various business functions but also particularly associated with the business function product development. Therefore, both aspects the business function product development and the management of the business object product are assigned to the same domain candidate, which is simply named product. See figure 10. Fig. 10. Domain candidate product Product (product development and handling product business objects) Step 4: & support functions The management and support functions become domain candidates. See figure 11. ERP Compliance Treasury Risk Fig. 11. Domains for management & support functions Step 5: Finalize The domain candidates identified so far become the final domains. Meaningful names have been found during the iterations. Figure 12 shows the final domain model.

12 12 Andreas Hess, Bernhard Humm, Markus Voß, Gregor Engels Customer-facing domains Branch Applications Self Service E-Banking Call Centre Core Banking Core business Product Marketing Retail Banking Corporate Banking Credit Approval Securities Trading Payments Order Credit Administration Securities Custody Payment Transaction Accounting & Booking Enterprise Resources Business Partner Contract Order Account & Support ERP Compliance Treasury Risk Fig. 12. Final domain model The final domain model shows customer-facing domains at the top of the diagram. The centre shows domains for the core business functions, along the value chain. Then, domains managing enterprise resources are listed. At the bottom of the diagram, domains for management & support functions are shown. 6. Project experience sd&m has analyzed and / or constructed over 20 application landscapes of large corporations of different industry sectors. In some of those projects, the method for constructing the domain model has been applied explicitly, in others implicitly. We have analyzed 18 of the resulting domain models according to the usage of business functions, business objects, and business dimensions. The analysis demonstrates convincingly that business functions, business objects, and business dimensions play an important role and, hence, give evidence of the validity of the method described. Fig. 13 gives an overview of sample domain names from 9 application landscapes in the industry sectors automotive, banking, insurance, public, telecommunication, and tourism. Industry sector Business functions Business objects Automotive Supply Order Order Mgmt Production Logistics Banking Advice Customer Sales Product Account Value chain Customers, markets Securities outsrc. Products Passenger cars Trucks Bus Loans Payments Channels & support Quality mgmt Finance & controlling Customer & bank frontends Accounting Controlling

13 Industry sector Banking Business functions Support service Operations Business objects Business partner Value chain Customers, markets Payment Retail TXN customers central Corporate bank customers Banking all are split Partner Order mgmt. Securities settlement Credit approval Credit admin. Life Insurance Insurance Public Telecommunication Tourism Product devel. Acquisition & advice Conclusion Payments Service Analysis Customer care & advice Cash benefit Sales & marketing Invoicing Product mgmt & design Booking Contract mgmt. Claims Customer mgmt. Contract Partner File mgmt. Personal data mgmt. Supplier & partner Customer Contract & resource mgmt. Retail Private Corporate Structuring software cities a multidimensional approach 13 Products Investment banking Financing Account products Complex credits Life insurance Life insurance Property insurance Monetary service Programs Channels & support Branch Bank mgmgt mgmt. Customer Regulatory interaction reporting Risk controlling Market data supply Financing Sales mgmt. Office comm.. Planning Customer Personnel channels Administrative (face-toface, services phone, ) Business Multichannel services Fig. 13. Selected domains from application landscapes in different industry sectors Monitoring & ERP 7. Related work There is not much work known by the authors that addresses concrete methods for application domain modeling in software architecture. Approaches to service oriented modeling of architecture like [8] describe domain decomposition as an important step for the identification of services, but confine themselves to stating that a combination of top-down, bottom-up, and middle-out techniques must be applied. In [9] Ambler et al. describe an extension of the Rational Unified Process for enterprise architecture that treats Enterprise Domain Modeling as a subtask of the discipline Enterprise Business Modeling distinguished from the Enterprise

14 14 Andreas Hess, Bernhard Humm, Markus Voß, Gregor Engels Architecture discipline. In [10] Ambler suggests that for some organizations it might be fine to combine both disciplines in a domain engineering approach where highlevel domain concepts are implemented in a reusable manner, perhaps as domain components or collections of web services. This approach requires significant sophistication within your organization, including a strong approach to enterprise business modeling as well as to enterprise architecture. Domain engineering represents the pinnacle of strategic reuse. In his article A methodology for service architectures, Jones comes close to the methodology we describe [11]. He also starts out with business functions (in the article termed level 0 services ). Since his article focuses on the identification of services, the succeeding refinement steps differ from our method for identifying domains. Fundamental works on the separation of concerns and modularization like, e.g., [12] are, as a matter of course, the basis of our method. Particularly the works of Parnas (e.g., [13], [14]) have laid out the basics for designing components in the small. Our method can be seen as an application of Parnas principles in the large. Our approach has similarities with different forms of organizational structures of enterprises, e.g. matrix organizations that combine functional and divisional structures where divisions are defined by products, markets or customer groups. 8. Conclusion We summarize the following key aspects: 1. Software cities (application landscapes) are extremely complex. One important tool of enterprise architecture management is structuring them into application domains. 2. Application domains are used for strategic planning as well as for the operational management of an enterprise s IT project portfolio that is the driver for the evolution of the application landscape. Because of this, finding a good domain model is crucial. 3. Application domains are always structured following the business of an enterprise. The structure takes into account: business functions, business objects and businessspecific dimensions like customer groups, product groups / markets, customer access channels and the length of the value chain. 4. Designing a domain model is always an iterative, top-down & bottom-up process, involving a lot of communication and reconcilement. We present a method with a multi-dimensional approach and concrete steps within this process 5. Finding a good domain model requires a lot of experience and knowledge of the business. In so far, method does not replace expertise. However, experience from numerous domain models in industry show the validity of the multi-dimensional approach.

15 Structuring software cities a multidimensional approach 15 References 1. Anella, M., Strategy & Architecture, 2. Berner Architekten Treffen (2005), Vortrag.pdf 2. Deb M., Helbig J., Kroll M., Scherdin A., Bringing SOA to Life: The Art and Science of Service Discovery and Design, also 3. J. Laartz, E. Monnoyer, A. Scherdin: Designing IT for business, The McKinsey Quarterly 3/2003, 4. J. Laartz, E. Sonderegger, J. Winckler: The Paris guide to IT architecture, The McKinsey Quarterly 3/2000, 5. Keller W.: Managing Application Portfolios in Merger Situations, in: Dadam P., Reichert, M. [eds.]: INFORMATIK Informatik verbindet, Band 1, Beiträge der 34. Jahrestagung der Gesellschaft für Informatik e.v. (GI), a.pdf 6. Lankes, J., Matthes, F., Wittenburg, A.: Softwarekartographie: Systematische Darstellung von Anwendungslandschaften. In: Wirtschaftsinformatik 2005, Bamberg, Paper.pdf 7. Ernst, A., Lankes, J., Schweda, C., Wittenburg, A.: Using Model Transformation for Generating Visualizations from Repository Contents - An Application to Software Cartography. Technische Universität München, Institut für Informatik, Lehrstuhl für Informatik 19, Technischer Bericht TB0601, 2006, 8. Arsanjani, A.: Service-oriented modeling and architecture, IBM DeveloperWorks, SOA and Web Services, 9. Ambler, S. W., Nalbone, J., Vizdos, M. J., The Enterprise Unified Process: Extending the Rational Unified Process, Pearson Education (2005) 10. Ambler, S. W.: Extending the RUP with the Enterprise Business Modeling Discipline Jones, S.: A methodology for service architectures. Capgemini white paper, hitectures%201%202%204%20-%20oasis%20contribution.pdf 12. Ghezzi, C., Jazayeri, M., Mandrioli, D.: Fundamentals of Software Engineering. Prentice Hall (1991) 13. Parnas, D.L.: On the Criteria To Be Used in Decomposing Systems into Modules, Communications of the ACM 15(12), (1972) 14. Parnas, D.L.: Designing software for ease of extension and contraction, IEEE Transactions on Software Engineering 5(2), (1979)