Applying Architecture and Ontology to the Splitting and Allying of Enterprises: Problem Definition and Research Approach Martin Op ’t Land Delft University of Technology, Netherlands Capgemini, P.O. Box 2575, 3500 GN Utrecht, Netherlands
[email protected]
Abstract. Organizations increasingly split off parts and start cooperating with those parts, for instance in Shared Service Centers or by using in- or outsourcing. Our research aims to find the right spot and the way to split off those parts: “Application of which organization-construction rules to organizations with redundancy in processes and ICT leads to adequate splitting of enterprises”? Architecture and ontology play a role in the construction of any system. From organizational sciences we expect specific construction rules for splitting an enterprise, including criteria for “adequately” splitting an enterprise. We intend to find and test those construction rules by applying action research to real-life cases in which ontology and architecture are used. Keywords: Splitting enterprises, Architecture, Ontology, Shared Service Center, BPO, action research, DEMO, Modern Sociotechnique.
1 Introduction Organizations increasingly split off parts and start cooperating with those parts, for instance in Shared Service Centers (SSC) or by using in- or outsourcing. Hackett (2006) shows that for the Finance and Accounting business in 2006-2008, the use of outsourcing is expected to more than double. Reliance on shared service centers will increase slightly, and shared services is expected to remain the preferred sourcing alternative. The use of offshore shared services will double over the next 3 years. Organizations want to be able to offer more complex products in a shorter time or to participate in complex product-offerings of another party. Splitting their organization in specialized parts makes those organizations more agile to recombine those parts time and again in the capability to deliver new products and to timely drop current products. Umar (2005) introduces the notion of Next Generation Enterprises (NGE), which conduct business by utilizing innovative new business models. He claims such a NGE (known by names like virtual enterprise, networked enterprise, real-time corporations etc.) will be the standard way of doing business, given its agility and ease of set up. Agility has become a business requirement in many lines of business, from the US army (schedules for combat systems from 8 years to 2 years) R. Meersman, Z. Tari, P. Herrero et al. (Eds.): OTM Workshops 2006, LNCS 4278, pp. 1419 – 1428, 2006. © Springer-Verlag Berlin Heidelberg 2006
1420
M. Op ’t Land
via the US car industry (from thought to finish for a new model in a few months instead of 6 years) to the Dutch banking industry (time to market for a new product from 9-12 months to a few weeks (Arnold et al 2000)). Setting up new businesses has become a matter of hours, including online purchasing and payment systems. Friedman (2005) states that businesses are being formed not based on the core competency they have, but instead on their ability to provide services by clever combinations of outsourcing and renting through service providers around the globe. Internally, organizations want to reduce redundancy in processes and ICT in order to save costs, simplify operations and make them more manageable. Splitting their organizations in units with clear customer-supplier-responsibilities, clear competencies and geo-flexibility in operations and ICT improves those current operations, stimulates entrepreneurship and gives those units a customer-oriented focus, with the potential to broaden the customer base. According to Straten (2002), common motives for Business Process Outsourcing (BPO) are (1) cost reductions, by increased efficiency and economies of scale; (2) focus on core competencies; (3) access to additional resources and capabilities; (4) creating incentives and stimulating entrepreneurship. Travis and Shepherd (2005) find comparable benefits for using shared services and add to it (1) improved control and reduced regulatory compliance costs and (2) faster time to upgrade processes, applications and technology. When we say splitting enterprises, we mean the activity which results in assigning roles and responsibilities to a separate organizational entity, which may (but does not need to) be a separate legal entity. Typical results of splitting are a SSC, a BPO-party or just a centralized department in an organization. The roles and responsibilities may concern any business function, from “secondary” (like catering and housing) via “primary back-office” (like mortgage back-office processing) to “primary front-office” (like sales). Take for example Mario’s pizzeria, for which Fig. 1 shows the DEMO Construction Diagram. Mario could outsource or share the sales function with a Fig. 1. Construction diagram pizzeria (DEMO-notation) national call-centre. Together with his next-door neighbors, Giovanni’s pizzeria and Antonio’s pizzeria, he could found a Shared Service Center Baking. And also the transportation could be outsourced to a logistics provider or shared with his neighbors. The question where to split the enterprise is not easy to answer. Take for example the sales function of pizzeria “Mario”: should he outsource his sales function to a national call-centre? To retain his personal contacts with customers may be he shouldn’t. On the other hand, the ability of handling payments of phone orders for his anonymous customers could be attractive. In that case, would it be wise to outsource only the payments-part of his ordering and not the ordering itself? For another example, would it be wise to found a Shared Service Center baking, enabling him to cooperate in the baking to make this more efficient, while competing in the frontage? If
Applying Architecture and Ontology to the Splitting and Allying of Enterprises
1421
so, should common purchasing and stock control be part of it, may be even including the financial administration? Already in this simple example we see motives of customer intimacy, efficiency, product uniqueness, broadening the product portfolio, cost control and equalizing capacity emerge. And even if the (functional) priorities chosen in those motives are clear, it is not immediately clear how this mix of priorities leads to choices in the construction of the enterprise. In real-life cases, like in banks, public or industry, this is even more complex. According to our literature search, almost no research has been done in this area. Gulledge and Sommer (2004) make clear how the SAP Blueprinting methodology (ASAP) can be misleading if cross-functional business processes and organizational alignment are not considered part of the project scope. The costs of a wrong choice for splitting the enterprise, even if restricted to the software changes, can be huge. Fig. 2 shows the added value of a competence for “right-splitting enterprises”, summarizing the common motives for SSCs and BPO’s mentioned before. N offer complex products
diversity of operations N
N width customer-base
quality of operations N
time-to-market competence for "right" splitting enterprises N
scalability of operations N adequate splitting decision
(incl cheap & simple starting / stopping)
N
CashFlowin N
P P costs of commercial product-failure
CashFlowout P
(a/o make-or-buy)
P redundancy in processes & ICT
N use geo-flexibility of operations cheap availability advanced ICT N
Fig. 2. Partial benefits logic for the competence of “right-splitting enterprises”
2 Currently Available Solutions Splitting enterprises fits in the disciplines of organizational sciences and enterprise engineering. Mulder (2006) gives a broad overview of organizational science schools and what they have to say about enterprise engineering. He concludes the Language Action Perspective (LAP-) school currently to be the most attractive option for enterprise engineering, given (1) the increased focus on external behavior of an organization; (2) the (dramatically) increased ability to work independently of location and time, enabled by ICT; (3) the need for constructional (instead of functional) guidelines for
1422
M. Op ’t Land
enterprise engineering; (4) the need for an integral design of business processes, information systems and ICT-infrastructures. Dietz (2006) has transformed the LAP-vision into the DEMO-method. This method aims to deliver an Enterprise Ontology, which is a constructional model of an enterprise that is fully independent of its implementation; it is only dependent of the product (structure) the enterprise delivers. Dietz elaborates mainly how to derive this ontology from descriptions about already implemented organizations and procedures, but does not cover the "brand new creation" of an enterprise from market and customer demands (Dietz 2006 p 77), although he briefly shows how to derive an ontology from a product structure. Actually drafting an organization structure based on an enterprise ontology is not in his scope; DEMO itself does not contain criteria or construction rules for constructing an organization. Furthermore, he claims (p 184) an Enterprise Ontology to be a stable starting point for defining information systems. In his ROOD-case Mulder (2006 pp 85-116) demonstrates how to apply DEMO on organization design. Especially DEMO’s transaction concept appeared to be a suitable unit for the stakeholders to decide about the new organization structure (p 110). The construction rules for that did appear bottom-up while discussing several organization alternatives for the same ontology. The content of those construction rules and its influence on constructing the organization have not been explicitly researched. Modern SocioTechnique (MST) is a proven method for structuring organizations. As Sitter (1994) and Amelsvoort (1999) indicate, MST starts top-down from a product structure, builds steering and information bottom-up and prescribes design- and design-sequence-principles. Those design-sequence principles are: (1) start with a strategic orientation; (2) first design production structure, after that steering structure; (3) design the production structure top-down; (4) design the steering structure bottomup; (5) finally, design the information and communication structure and other supporting systems. The design of production structure starts from product-market combinations via product streams to ultimately independent groups of employees, the selfmanaging teams. The design of steering structure starts to assign regulating tasks as much as possible to self-managing teams; where this is not possible, steering is assigned to the higher levels of operational group resp. business unit. Comparing MST with DEMO, we observe the following. MST claims to be a complete method, so not only the language for organization construction, but also the “principles” for design and design-sequence. DEMO does provide a language for the “parts” of an organization; however, DEMO does not provide the criteria and the method for enterprise engineering. DEMO starts explicitly with the product structure and derives from that the production structure, the Construction Model; MST starts with a production structure and derives business activities from that. MST bases its information requirements on the design of an implemented organization, while DEMO states that ontology is the stable basis for information requirements. Neither MST nor DEMO is explicitly interested in the issue of splitting enterprises. Graaf (2006) is explicitly interested in the subject of splitting enterprises. He seeks however for generic principles, where we assume many principles and construction rules can be leading and we want to understand the impact of the choice of principles in drawing organizational borders. Also he uses a diversity of units for sharing/sourcing ("services" or "processes", sometimes "goals" and "products"), without underpinning this diversity. Graaf suggests that in order to decide for "outsourcable
Applying Architecture and Ontology to the Splitting and Allying of Enterprises
1423
units", we should look not only at business coherence, but also to information coherence; we consider that an interesting hypothesis to test. We conclude that currently available methods offer promising elements for the method we seek. MST could offer us construction rules and design sequence. DEMO could offer us a language to express the essence of an enterprise, which is also a stable starting point for gathering information requirements. In the construction rules and criteria, we might look to business coherence as well as information coherence. We want to see how this all fits together in a method for splitting enterprises. And we want to see how that works in practice.
3 What Answer Are We Looking for?
implementation
implementation
engineering
reverse engineering
We define enterprise as a goal-oriented cooperative of people and means. This leaves still open the decisions about what is external and what is internal. In the enterprise, we are interested in issues of splitting. When we discern areas of sharing, in- or outsourcing, we are conceptually making splits or cuts in the enterprise. In the enterprise, we are also interested in the issue of allying or co-operating. Splitting and allying enterprises are two sides of the same medal: the moment the work for an enterprise is split over parties, those parties have to ally in order stay that “goal-oriented cooperative of people and means”. architecture We will treat splitting enconstructional functional terprises as a specific case of principles principles the Generic System Develusing system object system opment Process (GSDP) from construction construction xAF (2006), which we will function object construction now briefly introduce, using system ontology ontology design function design Fig. 3. In every design procdesign ess there are two systems analysis synthesis involved, the using system (US) and the object system (OS). The OS is the system to technology technology be designed; the US is the system that will use the functions or services offered by Fig. 3. Generic System Development Process (xAF 2006) the OS once it is operational. Function design, the first phase in the design of the OS, starts from the construction of the US and ends with the function of the OS. Function design delivers the requirements of the OS, so a black-box model of the OS. This function model of the OS does not contain any information about the construction of the OS. Construction design, the second phase in the design of the OS, starts with the specified function of the OS and it ends with the construction of the OS. Construction design bridges the mental gap between function and construction, which means establishing a correspondence between systems of different categories: the category of the US (where the function of the OS is defined) and the category of the OS. Construction design delivers an ontology, the highest level white-box model of the OS. By an ontology or ontological
1424
M. Op ’t Land
model of a system we understand a model of its construction that is completely independent of the way in which it is realized and implemented. The engineering1 of a system is the process in which a number of white-box models are produced, such that every model is fully derivable from the previous one and the available specifications. Engineering starts from the ontological model, produces a set of subsequently more detailed white-box models and ends with the implementation model. By implementation is understood the assignment of technological means to the elements in the implementation model, so that the system can be put into operation. By technology we understand the technological means by which a system is implemented. A wide range of technological means is available, varying from human beings and organizational entities via ICT (e.g. phone, email, computer programs) to vacuum cleaners, cars, drilling machines and screw drivers. In general, the design freedom of designers is undesirable large. xAF (2006) therefore defines architecture conceptually as a normative restriction of design freedom. Operationally, architecture is a consistent and coherent set of design principles that embody general requirements. General requirements hold for a class of systems. In terms of GSDP, we define splitting the enterprise as the first step in making an implementation model of the enterprise, namely assigning responsibilities to organizations and organizational units, so not to function profiles or individual people. Splitting is based on the enterprise ontology and, as part of the designing and engineering of the enterprise, restricted by the enterprise architecture. For example, the two bikesuppliers Batavus and Altera are the same in the essence of “supplying bikes” and therefore they share the enterprise ontology of a bike-supplier. Those bike-suppliers will also differ, e.g. in the principle “outsource all production”. For example, Batavus has chosen to build bikes itself, while Altera has chosen to outsource that. This difference in principles from the enterprise architecture leads to a different pattern of cooperation with partners, and therefore to other organizations. Splitting is a special case of starting drafting an implementation model. Indeed, splitting is taking an existing organization, so an implemented enterprise, and reassigning the roles to one or more new organizations, in which the same product (family) remains to be delivered. For splitting enterprises, we want to find construction rules, so the algorithm by which you decide where to split. We expect our construction rules to look like “if then preferably don’t split the enterprise on that spot, because ”. For instance, “don’t cut the enterprise on a spot with heavy information-exchange, because this will increase the error-rate”. Also the construction rules may prescribe order of working, like “step 1 = distinguish areas with high internal information dependencies; step 2 = …”. The construction rules should tell us consequences of applying a decision rule too, like “when in this situation the enterprise is split, new roles will appear at the organization border, e.g. the role of service manager.” We expect construction rules from both general systems development theory (like expressed in GSDP) applied to enterprises as system type and organization sciences as far as it concerns designing and implementing organizations. Mulder (2006) demonstrated how enterprise ontology according to DEMO worked as a language for enterprise engineering, enabling conscious choices in splitting the enterprise. A theory 1
Engineering is meant here in the narrow sense of the term, contrary to its general use in civic engineering, electrical engineering, mechanical engineering, etc.
Applying Architecture and Ontology to the Splitting and Allying of Enterprises
1425
about those construction rules, including the influence of architecture, is lacking. Organization sciences, on the other hand, will give us commonly used construction rules for enterprise engineering, like "split complex tasks", “keep similar tasks together”, "split between primary and secondary business processes", "loose coupling" and “strong internal and weak external cohesion”. The influence of architecture and ontology on that is currently not defined. We want splitting of enterprises to be done adequately, which we define as being compliant with professional requirements, situational process-requirements and situational result-requirements. A professional requirement is broadly applicable and not situation-specific, e.g. "minimize need for tuning". It probably originates from general systems development theory and organization sciences. Situational processrequirements are specific for a specific process or project of splitting, e.g. project costs, timeliness, effectiveness and quality. Situational result-requirements are the goals to be reached by splitting the enterprise, including the constraints to be complied with. As mentioned in §1, the goals for splitting of enterprises can be quite diverse and include saving costs (location, people, tax), improving quality (right people with right qualifications in e.g. language, training and experience) and improving agility and flexibility. Constraints will typically originate from the ecosystem of the organization, like from (legal or branch-) supervisors, customers, suppliers and other network partners. So in the construction (Professional Requirements ) rules we want to see the Architecture(E ) ⎛ ⎞ influence of architecture and organization⎜ ⎟ Ontology (E ) construction specific ⎜ ⎟ adequate splitting rules ontology, together with pro⎜ Result - requirements (E ) ⎟ enterprise proposal (E) ⎜ ⎟ E ⎜ ⎟ enterprise-splitting fessional and situational ⎝ Process - requirements(E )⎠ requirements, in the adesituationsituationsituationspecific input specific process specific result quate splitting of enterprises. Researching all possible Fig. 4. Concepts for splitting enterprises requirements will not be in scope. We further restrict our problem area by choosing as intended domain “enterprises, currently organized with redundancy in processes and ICT” of for short “organizations with redundancy in processes and ICT”. The reason for this restriction is quite pragmatic. As we saw already in §1, for many organizations which presume to have redundancy in processes or ICT, this is an immediate cause for seeking optimizations like Shared Service Centers, BPO or centralized departments. That action confronts those organizations with the issue of adequately splitting their enterprise. So our problem statement reads as follows: Application of which organizationconstruction rules to organizations with redundancy in processes and ICT leads to adequate splitting of enterprises?
4 Research Approach In our research for organization-construction rules, we want to see especially (1) how architecture and ontology influence the splitting of an enterprise; (2) what is the “minimum size” of architecture and ontology to still let the organization-construction
1426
M. Op ’t Land
rules give the same result – thus discovering the “right size” of architecture and ontology in the splitting of an enterprise. Below we will argue an appropriate approach for the second result is action research and for the first result case studies. We use a research approach in which in successive situations several enterprises are split. The use of organization-construction rules in one such a situation is studied according to the method of case study (see below why). Based on the experience of that one situation, new ideas about the construction rules will emerge and be reflected upon, which can be used in the subsequent situation. In that situation again a case study can be executed, etc. This cycle is commonly referred to as action research, defined by Avison (1999) as a redesired effect peating cycle of intervention, meascase-study: uring, evaluation and improvement. realized effect? measure improve Action research as research instrument is intended to apply a theory in think up concepts and practice and evaluate its value in the N* tools design new reality as changed by (the theory of) situation the researcher. Here the researcher intervene selects or develops new concepts optimised and tools, in our research program concepts and tools organization-construction rules for splitting enterprises, to use it (or let Fig. 5. The action research cycle it be used) in new situations. Based on those characteristics of action research and following (Babeliowsky 1997) and (Eijck 1996), we expect for the realization of the second result, finding the “right-size” of architecture and ontology in enterprise-splitting, and so for the research program as a whole, action research will be an adequate approach. In a case-study, researchers take a position outside of the case and observe the case in its “natural” environment, without intervening or interfering (Yin 1994). Here, to achieve the first result, we concentrate on the correlation between architecture, ontology and requirements on one hand and the resulting split enterprise on the other hand, looking at the construction rules applied in a real-life environment. Information about that is only available in the specific situation itself. By using real-life experience of the researcher in his role as consultant, we expect to get access to sources nowhere else available. According to Yin (1994, p 13) and Babeliowsky (1997, p 18), a good research instrument in these circumstances is the case-study. Studying single cases can satisfy the standards of the natural science model of scientific research (Lee 1989). Therefore, for each single case we have set up a research design for that case study, following the notions of Yin (1994). Each case-study will therefore have its own sub problem, method, result and conclusions. The result of each case-study will have two levels (1) the splitting proposal for the enterprise and how adequate that splitting proposal was for that situation; (2) what that situation has learned us about the organization-construction rules.
Applying Architecture and Ontology to the Splitting and Allying of Enterprises
1427
We now split our over-all problem statement in 4 sub questions: 1. how do ontology & architecture of an enterprise look like in practice (in one case)? 2. how do architecture and ontology influence enterprise-splitting (in one case)? This should deliver a hypothesis on the value of architecture and ontology; the test on adequacy stays restricted to situational requirements; 3. what does organization science say about (a) professional criteria for adequacy of an organization (b) construction rules for splitting: what they are, how to measure? 4. what organization-construction rules work best (in one case) in enterprise splitting? We will now use additional construction rules from organization science; and the adequacy-test now includes professional requirements. We looked for cases in which at least an architecture, an ontology and a splitting proposal is available. In those cases the researcher has a participating role, which satisfies the criteria for action research. We have selected case-material from two organizations, the Dutch-based bank-insurer ING and the public agency Rijkswaterstaat. ING is a large financial institution, operating internationally on many locations. ING is a result of mergers, which caused a significant redundancy in processes and ICT. Rijkswaterstaat is an agency of the Ministry of Transport, Public Works and Water Management, which constructs, manages, develops and maintains the Netherlands’ main infrastructure networks. Especially by its strong regional autonomy in the past, Rijkswaterstaat faced large redundancy in processes and ICT. When we compare this researched domain – Rijkswaterstaat and ING – with the intended domain – organizations with redundancy of processes and ICT –, we see the following. ING and Rijkswaterstaat differ considerably in sector (private-financial versus public) and over-all size (110,000 world-wide versus ± 10,000). Both are large, supra-local functioning organizations with redundancy in processes and ICT. From the 11 large sectors served by the consultancy-firm of the researcher in 2006, they are considered rather representative for two of them (Financial Services and Public Sector). So we expect reasonable generalizability in Financial Services and Public Sector. Our approach to answer the 4 sub questions is as follows: 1. in a case study of Rijkswaterstaat, we will describe the architecture of Rijkswaterstaat as a whole and the ontology of Traffic Management; 2. in a case study of ING, we will describe the architecture and ontology of ING Securities and a proposal for the borders of ING’s Shared Service Center Securities, including the measurement of situational adequacy; 3. the organization scientific reflection will be answered in a literature study; 4. in a case study of Rijkswaterstaat, we will describe several splitting alternatives, based on the architecture and ontology of Rijkswaterstaat, using additional construction rules from organization science and tested for situational and professional adequacy.
5 Expected Added Value As main theoretical added value we expect to find explicit organization-construction rules and how those rules influence the splitting of enterprises. In (Dietz 2006) this influence has not been dealt with. In (Mulder 2006) those construction rules have not
1428
M. Op ’t Land
been explicitly addressed, but they appear bottom-up while discussing several organization alternatives for the same ontology. As practical added value we expect an improved insight in the problem of reorganizing, sourcing and sharing. Especially we expect an improved manageability of this reorganizing, sourcing and sharing: what are professional "handles" for this problem? May be even more generic conclusions on the issue of organization structuring can be drawn. Mulder (2006) for instance applies ontology to an issue of organization structuring without splitting issues, so some of our construction rules might be useful as well. Finally we hope to find indications on the “minimum size” of an enterprise architecture and an enterprise ontology.
References Amelsvoort Pierre van (1999) De moderne sociotechnische benadering – een overzicht van de socio-technische theorie. ST-Groep, Vlijmen Arnold Bert, Engels Ariane, Op 't Land Martin (2000) FPS: another way of looking at components and architecture in the financial world. Congress paper for the Dutch National Architecture Congress 2000 (LAC2000), www.serc.nl/lac/LAC-2001/lac-2000/3-realisatie/fps.doc Avison D, Lau F, Myers M, Nielsen PA (1999) Action research. Communications of the ACM 42:94-97 Babeliowsky Martijn (1997) Designing interorganizational logistic networks; A simulation based interdisciplinary approach. Doctoral dissertation, Delft University of Technology DEMO (=Design & Engineering Methodology for Organizations)-website, www.demo.nl Dietz Jan LG (2006) Enterprise Ontology – theory and methodology. Springer Eijck Daniel TT van (1996) Designing Organizational Coordination. Doctoral dissertation, Delft University of Technology Friedman Thomas L (2005) The World is Flat: A Brief History of the Twenty-first Century. Farrar, Straus and Giroux Graaf Erwin van der (2006) Architectuurprincipes voor de afbakening van outsourcebare kavels. http://www.architecture-institute.nl/master-lab/pdf/ErwinVanDerGraaf.pdf Gulledge TR and Sommer RA (2004) Splitting the sap instance: Lessons on scope and business processes. Journal of Computer Information Systems 44 (3): 109-115. Hackett (2006) BPO-outlook for finance and accounting 2006-2008. The Hackett Group. Lee Allen S (1989) A Scientific Methodology for MIS Case Studies. MIS Quarterly vol 13/1:33-50 Mulder Hans (2006) Rapid Enterprise Design. Dissertation Delft University of Technology. Sitter LU de (1994) Synergetisch produceren; Human Resources Mobilisation in de produktie: een inleiding in structuurbouw. Van Gorcum, Assen Straten Carolien van (2002) Disaggregating the firm by means of Business Process Outsourcing. Master thesis Erasmus University Rotterdam. http://www.strategie-vsb.nl/pdf/8.pdf Travis Lance, Shepherd Jim (2005) Shared Services, Cost Savings, Compliance Relief and Prelude to Outsourcing. AMR-research Umar A (2005) IT infrastructure to enable next generation enterprises. Information Systems Frontiers 7 (3): 217-256. xAF (2006) Extensible Architecture Framework. Report of the xAF-working Group for NAF, offered on LAC2006. See http://www.xaf.nl Yin Robert K (1994) Case study research, Design and Methods, 2nd edn. Newbury Park, Sage Publications
