Motivation behind Enterprise Architecture

T-86.5171 / Essay 1 / 14.2.2012 Elisabete Patricio (elisabete.patricio@aalto.fi, 253909) Anton Panhelainen (anton.panhelainen@aalto.fi, 39925H) Antti Savolainen (antti.t.savolainen@aalto.fi, 83720H) Samsher Chahar (samsher.chahar@aalto.fi, 84918J) Cristian Micliuc (cristian.micliuc@heavensolutions.com, 244976)

1. Introduction
Past scenarios have relied on Enterprise Architecture (EA) delivering automatic business and technical value per si. However, the outcomes have been a unsuccessful due to lack of previous understanding of what business value is in the first place for a certain organization. Some of the reasons pointed for this failure lay in rigid standards, tedious and time-consuming complying processes, changes which take too long and amazingly the fact that after implementation EA implementers are no longer following the standards implemented. When embracing the creation of an EA, it is necessary to understand that EA is only a precondition for creating architecture value. It is not a guarantee of long-term reward (Boster, Liu and Thomas 2000, p. 43). But what is then the business value of EA? Why should companies invest time, money and other resources in EA? What are their resources of reference, planning, motivation, and agreements toward the same goals. In addition, how do companies measure the EA business value for further monitoring of the agreed in the strategic and planning phase? These are some of the questions which this section aims to address. On the one hand academics argue that business owners have a vague idea of why an EA should be built, leading to planning which lacks purpose. One reason is the unsystematic way to analyse and define value where the EA planning could be based on for realistic expectations (Boster, Liu and Thomas 2000). On the other hand, practitioners of EA point other reasons such as how to link the EA efforts into the overall enterprise processes and how to leverage them as assets used regularly by a variety of stakeholders. Assets or advantages of EA have been recognized and are used as a strong argument for the business value creation. Some of the advantages are linked to business benefits, such as agility of enterprise, product time to market, flexible sourcing of value chain components, improved and consistent information exchange and risk reduction. Other advantages are linked to financial benefits, such as alignment of IT business case to value of strategic initiatives, reuse, time savings, lower support cost, lower acquisition cost and technical adaptability; and to other corporate benefits, such as increased flexibility of staffing and scale of skill pools (Aziz, Obitz, Modi and Sarkar 2005, pp. 1-3).

2. What is EA?
The concept of enterprise architecture has been changing and evolving on a regular basis. In the 1970s and 1980s the concept was commonly referred to as Information Systems Architecture. As time passed, a number of architectural frameworks, methodologies, and techniques have been developed. The image below shows some of these.

Figure 1. Enterprise Architecture Framework timeline. [Jaap Schekkerman, 2006, p89] Since the concept of Enterpise Architecture has constantly been evolving, there are numerous definitions of Enterprise Architecture but not one commonly accepted. One could argue that Zachmans definition of Enterprise Architecture could the one which is commonly accepted considering the fact that Zachman is one of the few who has conducted extensive research on the subject matter. Below is a list of some of the definitions of Enterprise Architecture. John Zachman "Architecture is a set of descriptive representations that are relevant for describing something you intend to create and that constitute the baseline for changing an instance of that thing once you have created it. Therefore, Enterprise Architecture is the set of descriptive representations relevant for describing an Enterprise and that constitutes the baseline for changing the

Enterprise once it is created." EACommunity (www.eacommunity.com) Enterprise Architecture is a framework or blueprint for how the organization achieves the current and future business objectives. It examines the key business, information, application, and technology strategies and their impact on business functions. Each of these strategies is a separate architectural discipline and Enterprise Architecture is the glue that integrates each of these disciplines into a cohesive framework. United States Government, Government Accountability Office, 2003 "...providing to people at all organizational levels an explicit, common and meaningful structural frame of reference that allows an understanding of what the enterprise does, when, where, how and why it does it and what it uses to do it" United States Government, Government Accountability Office, 2008 An enterprise architecture (EA) is a blueprint that describes an organizations or a functional areas current and desired state in both logical and technical terms, as well as a plan for transitioning between the two states. As such, it is a recognized tenet of organizational transformation and IT management in public and private organizations. Without an EA, it is unlikely that an organization will be able to transform business processes and modernize supporting systems to minimize overlap and maximize interoperability. Kaisler et al., 2005 "Enterprise architecture (EA) identifies the main components of the organization, its information systems, the ways in which these components work together in order to achieve defined business objectives, and the way in which the information systems support the business processes of the organization. The components include staff, business processes, technology, information, financial and other resources, etc. Enterprise architecting is the set of processes, tools, and structures necessary to implement an enterprise-wide coherent and consistent IT architecture for supporting the enterprise's business operations. It takes a holistic view of the enterprise's IT resources rather than an application-by-application view." ArchiMate foundation A coherent whole of principles, methods, and models that are used in the design and realization of an enterprises organizational structure, business processes, information systems, and infrastructure. Gartner Group Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprises future state and enable its evolution. Gartner Group, Philip Allega Enterprise architecture is the process that interweaves business and IT together ANSI/IEEE Std 1471-2000 The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. Cap Gemini Enterprise Architecture is the description and visualization of the structure of a given area of

contemplation, its elements and their collaborations and interrelations links vision, strategy and feasibility, focusing on usability durability and effectiveness. Architecture enables construction, defining principles, rules, standards and guidelines, expressing and communicating a vision Forrester, Gene Leganza, 2001 Enterprise architecture consists of the vision, principles and standards that guide the purchase and deployment of technology within an enterprise Institute for Enterprise Architecture Development Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate MIT Center for Information Systems Research: Enterprise Architecture is the organizing logic for key business processes and IT capabilities reflecting the integration and standardization requirements of the firms operating model. The ArchiMate Foundation: A coherent whole of principles, methods, and models that are used in the design and realization of an enterprises organizational structure, business processes, information systems, and infrastructure The Open Group By being inclusive with all other management frameworks, EA is a discipline that helps the Enterprise define, develop and exploit the boundary less information flow (BIF) capabilities in order to achieve the Enterprises Strategic Intent. US Federal Enterprise Architecture Framework (FEAF) Enterprise architecture is a management practice to maximize the contribution of an agencys resources, IT investments, and system development activities to achieve its performance goals. Architecture describes clear relationships from strategic goals and objectives through investments to measurable performance improvements for the entire enterprise or a portion (or segment) of the enterprise Microsoft's Michael Platt Offers a view of enterprise architecture as containing four points-of-view, called the business perspective, the application perspective, the information perspective, and the technology perspective. The business perspective defines the processes and standards by which the business operates on a day-to-day basis. The application perspective defines the interactions among the processes and standards used by the organization. The information perspective defines and classifies the raw data (such as document files, databases, images, presentations, and spreadsheets) that the organization requires in order to efficiently operate. The technology perspective defines the hardware, operating systems, programming, and networking solutions used by the organization.

The Open Group, TOGAF Version 9 Enterprise Edition Overview TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership. The term "enterprise" in the context of "enterprise architecture" can be used to denote both an entire enterprise - encompassing all of its information and technology services, processes, and infrastructure - and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise. Mark Lankhorst et al Enterprise architecture: a coherent whole of principles, methods, and models that are used in the design and realization of an enterprises organizational structure, business processes, information systems, and infrastructure.

3. Motivation for EA?

Most EA framework focus on modelling EA structure and behaviour while neglecting motivational dimension. For example, current EA practice uses conceptual models to express as-is and to-be architectures, while the reasons behind the choices of to-be architectures, and the exploration of alternatives are recorded outside the models, if documented at all. Reason and intention behind EA are hard to find and trace.(Yu, Strohmaier. & Deng, 2006) . Understanding those ends and means behind EA is vital to business success. Thats why Object Management Group(OMG) have developed Business Motivation Model(BMM). It focuses on Business Process, Workflows and Business Vocabulary.(OMG BMM, 2010 and Antunes et all, 2011) EA enables the capture and presentation of information in a rigorous, coherent and comprehensive way that aids the understanding of complex issues in organizations.(Jonkers et al., 2006) EA practise provides a way to each stakeholder to express their concerns and add their contribution to resulting architecture (Antunes et al., 2011 and TOGAF 9.1, 2011) Zachman framework emphasizes in its 6x6 matrix that each audience perspective row should have one column in which motivation intentions of that audience is described.(Zachmann, 2011) Influencers are the key of understanding EA for BMM. Those views derive from business perspective. (OMG BMM, 2010 and Antunes et all, 2011). In Togaf framework motivation consists three motivation extensions, which are Driver, Goal and Objective. Driver parts emphasizes idea why is a issue and it addresses the goal. The Goal is then realized. Objective is materialized and tracked through Measure extension. That extension is governance, which reminds that Goal and Objectives should be measured in order to see, if movement from as-is to-be state is going on.(TOGAF 9.1, 2011) EA also supports change management activities (MoDAF, 2010). A well-defined EA is an important asset for new developments within the context of the existing processes, IT systems, and other business assets of an enterprise, It helps in identifying necessary changes. It should not be considered something statical or innovation blocker(Jonkers et al., 2006). EA can be seen as a means of strategy alignment in changing business environment. It provides flexibility, when business and processes are changing. (Kang, Lee & Kim, 2010) Good architectural practice help an enterprise to innovate and change business and/or IT processes while providing stability and flexibility during change (Jonkers et al., 2006). While the use of EA standards can potentially help organizations to solve coordination problems across business units, standardization involves trade-offs. Standardization promises increase in overall efficiency, but there is trade offs. These trade offs are: EA restricts the options of business units, thus resulting in a less optimal local solutions (Hite,2003).

EA in military context provides support for defence initiative and changes operational level. It also enables military doctrines called: In DoDAF it is Network centric operations warfare (NCOW) and it is known in MoDAF as network enabled capability (NEC). Those doctrines seek advantage on battlefield using information technology (MoDAF, 2010 & DoDAF, 2010). Both MoDAF and DoDAF have been evolving as EA frameworks, because both have been updated to 2.x version in year 2010. Their original versions are from beginning of 21st century. According to Lapalme, EA can be divided to three schools of thought. These three schools of thought are Enterprise IT architecting School, Enterprise Integrating School and Enterprise Ecological Adaptation School. On motivational perspective Enterprise IT Architecting School driver is IT cost reduction through technology reuse and duplicate system and process elimination. Enterprise Integrating School finds motivation from stakeholder understanding as it exploits known aspects of the enterprises. Enterprise Ecological Adaptation School emphasizes innovation and capabilities increase. (Lapalme, 2011) Roger Session identified a list of concerns that would motivate organizations think about implementing an Enterprise Architecture. The list includes problems faced by many organizations and should signal the acute need of an effective Enterprise Architecture. Unreliable Enterprise Information - it is generated by data duplication and uncoordinated business processes Untimely Enterprise Information - A good analogy here is with playing chess without knowing your opponent last move. This happens usually because of extensive human driven operations which is a sign that the business is not well aligned with IT New complex projects underway New companies being acquired - It can be very difficult to merge two sets of business processes and IT systems without a good Enterprise Architecture in place Enterprise want to spin off unit - If EA sets the unit as autonomous from the rest of the business it can be easily integrated in other organization Need to identify outsourcing opportunities - Business strategy needs to understand how core IT systems and business processes relate to support IT systems and business processes Regulatory Requirements - Privacy regulations, auditing regulations and other regulations Need to automate relations with external partners / customers - EA can help to well define business processes that are aligned with IT systems Poor relation between IT and business units - Distrust between business and IT Poor interoperability of IT Systems - Enterprises have a large number of IT systems that were developer or bought off shelf and are built on incompatible platforms. There is a big challenge to coordinate these systems and make them share information. IT systems unmanageable - The so called pinned architecture where one system can not be easily changed because it affects other systems in an unacceptable or unpredictable way

3.1 How to identify Complexity in an organization?

Everything should be made as simple as possible but not simpler (Albert Einstein) A good EA is a simple EA(Sessions 2008)

The confusion can be made between the complexity of the problems that EA tries to solve and the complexity of the solution. Roger Sessions argues that the simplicity has to be taken as core value when building EA and even to have superior priority than all the other values such as agility, security, performance and reliability of IT systems, as simplicity is in many ways the ultimate enabler. Simplicity is viewed as a business asset. Eg: Kevin Drinkwater threw out $13 million JD Edwards ERP implementation at a company purchased by Mainfreight New Zeeland and replaced it with a $25.000 with a home grown ERP. Mathematics of complexity In order to have results reproductively and verifiable there is a need of having either a mathematical or logical model to asses complexity. Otherwise every time the EA professionals will rely on experience, gut feeling, luck, intuition or other intangibles. A mathematical model for understanding complexity will deliver the results promised by the rational world: reproducible and verifiable results. As per Session findings the number of system states is a good measure of complexity and can be calculated with a formula: C is complexity measure V is the number of variables S is the number of significant states, on average for each of the variables C = S^V Similar for business processes the complexity can be calculated using the formula C is the complexity measure D is the number of decision points P is the number of paths, on average for each decision point C = P^D There are three strategies to reduce complexity: partitioning, simplification and iteration. Partitioning deals with the split of large collections into independent subsets. Simplification is about reducing the complexity of subsets further by removing items from subset or eliminating an entire subset. Iteration promotes the manage of subsets one by one rather than working with all the entire collection at once (Sessions 2008). In the iteration process some rules stand out based on the observation of John Boyd who was a Air Force Colonel interested in dogfights. He found that the key to winning consecutive dogfights was observe, orient, plan, act (OOPA). Also he suggested that the speed of iteration beats the quality of iteration. This can be applied in implementation of complex systems as well meaning that it is better to act quickly rather than perfectly. This doesnt mean that the iteration should be carelessly, but should for example iterate through the partitions quickly rather than delivering all partitions in a big-bang way. Besides the complexity, there are also interactions between software systems that usually dont appear in the business processes. It is important to balance the need for interoperability

between the software systems (for example when using partitioning as reducing the complexity) and the complexity inside the software systems. It is estimated that adding 25% more functionality to a software system generates an increase of 100% in the complexity of the software system itself (Rattig 2007). Following this logic a system with 300 functions will be 32 times more complex then a system with 100 functions. But if one manage to partition the 300 functions system in 3 systems of 100 functions the total complexity will be 3/32 or ~9,4% of the original one. (Sessions 2008)

3.2 What is the Business value of EA?

Although organisations largely agree that EA is able to create business value for the enterprise, there is much confusion in the field how this value is created, and what kind of returns an organization embarking on a big enterprise architecture implementation project (or program) can expect (Boucharas et al, 2010). To research these questions, Tamm et al conducted a large literature survey in which they looked at the academic research and practitioner white papers to arrive at a holistic view of the expected business value of EA and the drivers behind them (Tamm et al, 2011). They concluded that there are four benefit enablers that drive business value creation out of EA: organisational alignment, information availability, resource portfolio optimization and resource complementarity. Organisational alignment means how the enterprise is able to align each organisational subunit to achieve the whole corporations goals. This is achieved by the increased dialogue that should be ignited by the EA planning activity in enterprises. The outcome of this dialogue should be the identification of duplicate effort in enterprises (e.g. multiple different information systems, processes dealing with the same business problem or multiple technology platforms). This should lead to reduction of duplicate work that in turn could potentially increase total return on investment in the enterprise. One output of the EA activity should be the creation of models and documents that depict the working of the enterprise. This information is then made available to the decision makers that can take advantage of the new information to make better decisions. Another benefit is achieved by establishing common, enterprise-wide data definitions and structures. These ensure that the whole enterprise uses same definitions all around and that the same information can be used in different systems with minimum integration costs. Better information for decision makers is also brought by the simplified processes and data that can be extracted from the data stores of the enterprise. Tamm et al hypothesize that the ultimate outcome of information availability are better targeted product development, marketing and sales campaigns. Optimizing the entire resource portfolio of an enterprise is one of the key tasks of EA. Key resources are people, software, hardware and information. EA tries to identify resource gaps and duplicate effort from the view of the whole enterprise. The goal is to simplify the portfolio by e.g. building a standardized technology platform and reducing the needed interfaces between different systems. This should lead to reduced costs, higher efficiencies and improved quality (in products and service delivery).

Resource complementarity deals with ensuring that the different parts of the enterprise work synergistically towards common goals. Its about how the organizational capabilities and competences are orchestrated. According to Tamm et al the benefits of resource complementarity are dependant on the operating model of the organization - e.g. an enterprise that is striving for customer intimacy can benefit by having a single view of the customer across the enterprise. In another similar literature survey that was conducted by Boucharas et al, the researchers ended up with a more detailed list of different business benefits of EA. Their Enterprise Architecture Benefits Map (EABM) describes the different viewpoints that are thought to be the benefits of EA. The approach is similar to the Balanced Scorecard method. There are the financial perspective, the customer perspective, the internal perspective and the learning & growth perspective. They argue that limiting the benefits evaluation to only financial aspects does not offer a comprehensive view on the overall benefits of EA. Also individual IT systems projects can benefit from the EA effort, though the ultimate goal of EA is to create value for the enterprise as a whole. Examples from practice have shown that the existence of an EA is likely to reduce project costs and schedule duration, reduce project risks, manage project complexity and speed up project initialization (Foorthuis et al, 2011). All of these benefits rise from the fact that EA provides better visibility and long-term goals that steer the projects forward. Visibility in terms that the enterprise knows what other project are ongoing and what kind of interdependencies they have. Long-term goals help establish boundaries in which the project should operate. In a way the goals set a standardized platform on top of which the projects can build their foundation. It is important to note that business value does not mean the same thing for every business. Instead the expected benefits are linked to the operating model of the enterprise. Ross et al recommends that the enterprise architecture effort should be started by debating the operating model at the top management level. The operating model is decided based on two axes: whether business process integration needs are high or low and/or business process standardization needs are high or low. They categorize four different typical operating models for businesses based on this mapping: coordination, unification, diversification and replication. In an environment, in which there are high business process integration requirements there are needs to have common data set i.e. a single view of the customer and the entire product portfolio. In this kind of the situation the enterprise can expect benefits from a centralized database design and centrally managed IT infrastructure. High business process standardization requirements are typical in an environment where the customer-base can be quite heterogeneous and business units are independent, but there are clear benefits of sharing best practices in business processes.

Fig. 3. Enterprise operating model matrix (Ross et al. 2006) As mentioned the operating model has clear implications on the business value and benefits an enterprise can expect from EA. For example a global bank that serves normal households does not benefit from having a central customer database, because their services are provided for customers from national branch offices and there are very few same customers between different national branches.

3.4 Why and how to measure the value of EA?

Three value contexts or dimensions are presented as the main importance when considering the value of EA, they are the architect, the process to build the EA and the architecture and its final products (e.g. architectural drawings and models). Each dimension includes critical aspects of both business (what we want) and technical (how we do it) perspectives. However, normally the expectations of the value of EA are higher than reality due to greater focus on the technical perspective (Boster, Liu and Thomas 2000, p. 44). In Figure 4 it is depicted a higher expectation-reality gap on the business dimension.

Fig. 4. Measuring the value of an EA, (Boster, Liu and Thomas 2000, p. 44) Therefore, a starting point into measuring the value of EA consists of including business perspectives as well, which should be in alignment with the business value of EA initially defined before implementation. This includes beside technical measurements of the EA value for monitoring its achievement, as well as political, governmental, organizational communication competencies and business aspects. Why is this important? To ensure that everyone in the organization understands, believes and accepts the EA (Boster et al. 2000; Ross 2003). Another interesting question when observing the expectation-reality gap is related to what has been decided to achieve, it could be that the goals are unrealistic or unfeasible. Therefore, it is important to analyse the what we want and how to do it close together and not in separate silos. How can you measure this? It might be easy to develop a goal but then how to you evaluate its achievement? Where do you start? Do you start by having the measures before or after the EA implementation? According to the Balanced Scored Card (BSC), a set of measures or KPIs (key performance indicators), which enables a fast comprehensive view of the business to managers, organizations can track or have control points to measure the achievement of the EA goals. The identification of the metrics should be developed together with the people involved in the implementation. The BSC lays emphasises on four dimensions with both quantitative and qualitative measures. The dimensions focus are Financial, services towards the Customers, processes at the Internal Business Perspective, and assets at the Innovation and Learning dimension. The goal is to enable the strategic goals to be translated into action through an holistic view at the EA value, without limiting those to a single indicator. Nevertheless, how do you develop the metrics? Schelp & Stutz (2007, p. 8-9) developed an EA scorecard framework (Fig. 5) based on the enterprise resource allocations. In their view the four dimensions of the BSC are classified according to the IT architecture, the context of IT, the enterprise, and finally cross-company. They conclude as well that these are linked together from the internal to the external or cross-company level.

Fig 5. EA scorecard framework (Schelp & Stutz 2007, p. 9) Some examples of measurements were proposed to help understand better the presented framework. If the business value of EA is to increase efficiency and effectiveness to reduce costs of operations (standardization) and to increase rapid change to market needs (agility), here were some of the measures which could be a good indicator: Agility - companies % of revenue generated from new products Standardization - of technology platforms and business processes, which increases in throughput and efficiency However, as previously pointed out, it could be that the initial defined goals and expectations are not feasible. Thus, if the goals where not reached, the next questions are why, what happened, and what to do next? Even if an organization is using measurements, those are not enough if the organization does not use them to alter the strategy, the goals, and in the end the metrics themselves. A Plan, Manage, Monitor and Adjust approach is proposed by Schelp & Stutz (2007) as a constant iterative process when it comes to measuring the value of EA. Another interesting approach to measuring the value of EA is the one considered by TOGAF 9 Content Metamodel (Fig. 6). Here the measurements are seen as a Governance Extension, which focus mostly on supporting in-depth, operation governance. This measures set performance criteria to ensure correct delivery of the agreed in the goals, enabling the bond between the objectives and business services. TOGAF 9 proposes that the use of governance extension is relevant when in the presence of IT change due to transformations in existing operational governance models (it includes change in policies, contracts, metrics, ownership and management of systems), and to trace that the service levels are in accordance with the business goals. The benefits pointed are service levels defined in a more structured way enabling better trace through diagrams of system and data ownership and additional diagrams of system operation and dependencies on operations processes (OpenGroup 2011a).

Fig. 6 (OpenGroup 2011a) TOGAF 9 has as well the Architecture Development Method (ADM), displaying an holistic iterative method where the relationships between the requirements and the needed elements can be seen for a successful achievement of the business goals initially established (Fig. 7) (Open Group 2011b). The content meta model is a more formal structure indicating the different dimensions and their subsets, whereas the ADM is a process of iterations indicating a direction or to provide a process life cycle to create and manage architectures within an enterprise (Open Group 2011a).

Fig 7. TOGAF 9 ADM (Open Group 2011b)

It is the Implementation Governance phase of the ADM where the Governance extension previously mentioned is included. Furthermore, one can see measurements under the Motivation dimension in the TOGAF 9 Content Meta model, which is under the Business Architecture, again emphasizing the link between of the business drivers, goals and objectives with measures as means of achieving evaluation, control points, and further improvement according to those. Another observation is the fact that the measurements are under the motivation for adopting EA, which can indicate a need to develop measures of how to evaluate EA As-Is to To-Be before undergoing implementation (Open Group 2011b). The goal of this paper is not to focus the analysis in TOGAF 9. However, as mentioned in the motivation part, TOGAF 9, Zachman and MoDAF are the most widely used EA frameworks by practitioners. Hence, the need to observe how the frameworks tackle the usefulness of EA from organization motivations point of view, and their understanding of the benefits of EA, towards planning and development, implementation, monitoring and improvement. According to the findings in this paper, a successful use of EA departures from identifying the motivation behind it, which once the business values are identified, these might still not be realistic. Therefore, the possible success factors for the use of EA is the interaction and repetition of the process on an ongoing phase, for continuous improvement between the different objectives, phases, and specially the business and IT people involved. Hence, having measurement of the value of EA is of most importance to enable improvement. Whittle & Myrick (2004) present a similar argument:
the building of integrated EA from the customer centric perspective enables corporate leaders to view the enterprise holistically.[...] The models illustrate [strategic model] the alignment and formal links between the strategy, vision and corporate objectives, with the strategic initiative roadmap. Finally, it establishes the metrics, measures, and expectations for success from this customer centric view" (Whittle & Myrick 2004, p.3)

The focus here in on the value created towards the customer as the final goal within most organizations and as a highly motivating factor to build an EA. Therefore, ensuring the link between the strategy and the results measurements is needed.

4. Conclusion
There is no one common definition of enterprise architecture. The discipline is young and immature, thus explaining the heterogeneous views practitioners and academics have on EA. On the one hand, some frameworks and definitions focus on the technical side of EA, i.e. they see EA as a way to rationalize and simplify existing technical architectures. While on the other hand, some frameworks and definitions view EA more as a business development, management and leadership tool, taking into account the whole enterprise as an organism, which consists of, among other things people, processes, governance practices and of course

technology. As acknowledged in a recent paper by J. Lapalme, technological aspects are clearly couple of the benefits EA is able to offer, but the future of EA calls for a holistic approach that looks past the technological modelling domain. Understanding the business motives behind EA is key to success. That provides traceability for measurements. Those measurements provide understanding how goals have been reached. In an enterprise there are different viewpoints for EA and all those have take account to succeed in EA practise. Those viewpoints have to be described from stakeholders view not with one ontology. The business benefits of EA presented in this paper, suggest an enterprise to weigh in on the possible returns an EA implementation program can offer. The benefits an enterprise can expect are dependant on the operating model of the enterprise and are often customer centric. The realization of these benefits must be based on a set of measurements, for which couple of examples were given. These measurements are once again tied with the operating model of the business and are designed according to the strategy goals. The established metrics are not static and are part of a continuous interactive process or loop to enable improvement. The relevance is linked to analysing the As-is to To-be position and to evaluate the needed changes of the initial objectives proposed, which can be unrealistic, and needed adjustments when no longer on track. The most common EA frameworks (TOGAF 9, Zachman and MoDAF) used emphasize the need for measurements as a important factor to enable the realization of the initial motivation for embracing EA. This again emphasizes the link between of the business drivers, goals and objectives with measures as means of achieving evaluation, control points, to provide further improvement accordingly. An interesting observation in this paper is the use of governance models to provide these points of control or metrics. The so called Governance Extension from TOGAF 9 is placed under the business architecture and motivation dimension, which displays the formal structure of the EA. In addition, the Implementation of Governance is included in the iterative process of the Architecture Development Model in TOGAF 9, as one of the requirements of the process life cycle. TOGAF 9 proposes that the use of governance extension is relevant when in the presence of IT change due to transformations in existing operational governance models, and to trace that the service levels are in accordance with the business goals. The complexity of both business processes and software systems can be assessed using mathematical models. Having a mathematical model in place for managing complexity will ensure that the EA results can be replicated and verified. So in order to fight complexity, simplicity should be seen as a core value when designing an EA.There are existing techniques for reducing complexity such as partitioning, simplification and iteration. Furthermore the executives should be more aware about technology as now IT departments manage huge numbers of legacy systems and any feature request may result in a dramatic increase of complexity that triggers a budget drain.

5. Further research
Several questions in this paper were still left answered. They are a result of the various group meeting discussions. Therefore, concerning the topic Motivation behind EA, next is presented a list of possible questions for further research. How to manage change linked to changes in the business environment? Who should come with the measurements? Business people? IT people? All together? Should measures come before EA implementation or vice versa More examples of measurements, what measurements, according to what EA business value? Could EA be considered as a living organism instead of a linear one? Where is the line where IT Governance is beneficial within the context of EA practice? ( IT Governance most often brings higher bureaucracy, slower decision-making and escalation processes) what is more suitable concerning EA, an mechanist or agility approach? Complexity of organizations are not linked solely to its size, what other reasons? How does the 3 schools of EA differ in terms of motivation, business value, measurements and interpretation of complexity?

6. References
Jaap Schekkerman(2006) How to survive in the jungle of enterprise architecture frameworks, 2006, p89 The Department of Defence Architecture Framework v2.02, 2010, DoDAF, [online] Available at: <http://dodcio.defense.gov/sites/dodaf20/index.html> [accessed 17.1.2012] The Ministry of Defence Architecture Framework V1.2.004, 2010, MoDAF, [online] Available at: <http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/ MODAF> [accessed 17.1.2012] Antunes G, Barateiro J, Becker C, Borbinha J, Vieira R., 2011,Modeling Contextual Concerns in Enterprise Architecture, Enterprise Distributed Object Computing Conference Workshops (EDOCW), 15th IEEE International, ISSN: 1-4577-0869-8 Zachman Framework for Enterprise Architecture 3.0, 2011, Zachman , [online] Available at: <http://www.zachman.com/> [accessed 17.1.2012] The Business Motivation Model V1.1,2010, OMG BMM, Object [online] Available at: <http:// www.omg.org/spec/BMM/v1.1/> [accessed 17.1.2012] Jonkers, H., Lankhorst, M. M., ter Doest, H. W. L., Arbab, F., Bosma, H., & Wieringa, R. J. (2006). Enterprise architecture: Management tool and blueprint for the organisation. Information Systems Frontiers, 8(2), 63-66. [online] Available at: <http://mmlab.ceid.upatras.gr/

courses/AIS_SITE/files/3/Enterprise architecture- Management tool and blueprint for the organisation.pdf> [accessed 19.1.2012], doi:10.1007/s10796-006-7970-2 Hite, R., 2003, Information technology: A framework for assessing and improving enterprise architecture management (version 1.1). White Paper, United States General Accounting Office, Washington, DC [online] Available at: <www.gao.gov/new.items/d03584g.pdf> [accessed 25.1.2012] Lapalme, J., 2011, 3 Schools of Enterprise Architecture. IT Professional. doi:10.1109/ MITP.2011.109 Kang, D., Lee, J., & Kim, K. 2010, Alignment of Business Enterprise Architectures using fact-based ontologies. Expert Systems with Applications, 37(4), 3274-3283. Elsevier Ltd. doi:10.1016/j.eswa.2009.09.052 Yu, E., & Strohmaier, M. & Deng, X., 2006, Exploring intentional modeling and analysis for enterprise architecture. Enterprise Distributed Object. [online] Available at: <http:// ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4031292> [accessed 5.2.2012] Boster, M. Liu, S. and Thomas, R. 2000, Getting the most from your Enterprise Architecture, Journal IT Professional, vol. 2, issue 4, IEEE Educational Activities Department Piscataway, NJ, USA, Doi: 10.1109/6294.869382

Aziz, S. Obitz, T. Modi, R. and Sarkar, S. 2005, Enterprise Architecture: A Governance Framework, Part I: Embedding Architecture into the Organization, White paper, Infosys Technologies Knowledge Sharing Series web seminars. Ross, J.W. 2003, Creating a Strategic IT Architecture Competency: Learning in Stages, MIS Quarterly Executive, Working papers 4314-03, Massachusetts Institute of Technology (MIT), Sloan School of Management. The Open Group 2011a, TOGAF 9.1 > Part IV: Architecture Content Framework > Content Metamodel, viewed 17, 27.1.2012, <http://pubs.opengroup.org/architecture/togaf9-doc/arch/ chap34.html#tag_34_02_02> Schelp, J. & Stutz, M. 2007, A Balanced Scorecard approach to measure the value of enterprise architecture, M. M. Lankhorst & P. Johnson, Architecture, vol. 3, issue 1, pp. 5-12 The Open Group 2011b, Module 3 Introduction to the Architecture Development Method, viewed 10.2.2012, <http://www.togaf.info/togaf9/togafSlides91/TOGAF-V91-M3-Intro-ADM.pdf> Whittle, R. & Myrick, C.B. 2004, Enterprise Business Architecture: The Formal Link between Strategy and Results, 1.ed., CRC Press, USA Tamm, T., Seddon, P.B., Shanks, G., and Reynolds, P. 2011, How Does Enterprise Architecture

Add Value to Organisations?, Communications of the Association for Information Systems, vol. 28, article 10. Available at: http://aisel.aisnet.org/cais/vol28/iss1/10 Boucharas, V., van Steenbergen, M., Jansen, S., and Brinkkemper, S., 2010, The Contribution of Enterprise Architecture to the Achievement of Organizational Goals: A Review of the Evidence, Proceedings of Trends in Enterprise Architecture, pp. 1-15 Ross, J. W., Weill, P., and Robertson, D. C., 2006, Enterprise Architecture as Strategy Creating a Foundation for Business Execution, Harvard Business School Press, viewed 9.2.2012, <http:/ /cisr.mit.edu/files/2009/12/Topic-EA_slide1_lg.png> Op t Land, M., Proper, E., Waage, M., Cloo, J., Steghuis, J. 2009, Enterprise Architecture Creating Value by Informed Governance, Springer-Verlag Foorthuis R., van Steenbergen M., Mushkudiani N., Bruls W., Brinkkemper S., Bos R. 2011, On Course But Not There Yet: Enterprise architecture conformance and benefits in systems development, Centraal Bureau voor de Statistiek Sessions, R. 2008, Simple architectures for complex enterprises, Microsoft Press Cynthia Rettig, The Trouble With Enterprise Software, 2007, MIT Sloan Management Review