enterprise architect

Paper for TEAR 2013 – 8th Trends in Enterprise Architecture Research Workshop, in conjunction with the 17th IEEE International  Enterprise Distributed Object Computing Conference (EDOC 2013).

Reference: Gøtze, J., 2013, The Changing Role of the Enterprise Architect. Proceedings of the 2013 17th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW 2013), 9-13 September 2013, Vancouver, British Columbia, Canada. DOI

John Gøtze 

Abstract—Enterprise architecture is practiced in different ways, and there are different types of enterprise architects with quite different roles. This paper looks closer at the role of enterprise architects and the importance of the enterprise architects’ understanding of boundary issues in their practice. The paper suggests that enterprise architects must focus on problem-finding more than problem-solving, and should develop not just more dialectic skills, but also dialogic skills. The paper also argues that the enterprise architects must gain a deeper understanding of the enterprise, and need to start working with other enterprise disciplines.

Keywords—enterprise architect, enterprise architecture, competencies, skills, boundaries, dialogics, enterprise, enterprising

I. INTRODUCTION

Being a practice-based profession and an emerging discipline, enterprise architecture is practiced in different ways [1][2][3]. Several studies of enterprise architecture practice have shed light on many important issues related to practicing enterprise architecture [4][5][6][7]. Few academic studies, however, have looked closer at the role of the enterprise architect, and how this role changes as the discipline evolves. Yet, “without this vital role, enterprises will continue to evolve in a state of chaos” [8]. This position paper discusses how the role of enterprise architects is changing. The paper begins with a brief analysis of the disciplinary scope of enterprise architecture, and then moves into a discussion about the enterprise architect’s role(s), and here identifies a number of challenges that enterprise architects are facing. The last two sections discuss ways for enterprise architects to deal with those challenges.

II. THE ENTERPRISE ARCHITECTURE DISCIPLINE

Enterprise architecture has traditionally been seen as a discipline working with the current and planned totality of information systems [9]. With origins in Information Systems Architecture [10], enterprise architecture has close relations to traditional concepts in the information systems literature [11], such as Information Resource Management [12][13], Enterprise Information Architecture [14] and Strategic Information Systems Planning [15]. Also, starting with the US Clinger-Cohen Act from 1996, the institutionalization of enterprise architecture in government [16] has been highly influential on the enterprise architecture discipline. Since 1999, enterprise architecture has been one of the Clinger-Cohen Core Competencies, a core body of (now) 12 competency areas identified by the US Federal CIO Council as fundamental to the effective management of federal technology resources [17]. Over the past decade, the disciplinary scope of enterprise architecture has however widened significantly [18]. The US Federal Government’s Common Approach to Federal Enterprise Architecture [19] in 2012 defined enterprise architecture as “the management best practice which can provide a consistent view across all program and service areas to support planning and decision making”. Essentially, enterprise architecture is “the inherent design and management approach essential for organizational coherence leading to alignment, agility and assurance” [1], where organizational coherence is the “logical, orderly and consistent relation of the parts to the whole” (ibid.). This follows ISO 42010:2011 which defines architecture as the “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. This way of understanding the whole through the relationship of the parts is the foundation of systems theory [20][21]. Several researchers have also applied systems thinking [22][23][24], such as the Viable System Model [25][26], to enterprise architecture [27][28]. Others focus more on the ‘in its environment’ part and suggest a more externally oriented, market-driven perspective on enterprise architecture [29][30].

Three distinct modes of enterprise architecture – Foundation, Extended and Embedded – show how enterprise architecture is, or can be, practiced [1]. Foundation is where there is an enterprise-wide view and plan for technology and in more advanced enterprises there is use of Enterprise Business Architecture to ensure the technology and business are well aligned. This is the predominant form of enterprise architecture practiced today. Extended is where the science, tools and techniques of enterprise architecture are extended into (and used by) all parts of the enterprise to design/describe much more than technology. For example, they could be used to help design better policy or improve service descriptions. Embedded is where enterprise architecture science, tools, and techniques are ingrained in everyday processes and people contribute to the overall enterprise architecture without being enterprise architects or necessarily knowing that they are contributing to the work of the enterprise architecture. For example, the budget line items conform to enterprise architecture standards that allow parts of the enterprise’s architecture to be updated on a regular basis, but by people doing budgets, not enterprise architecture. The classic enterprise architect then (in addition to former duties) also ensures that the artifacts created by the various process owners adhere to and contribute to an overall enterprise architecture effort.

Related to this idea, there has been a longstanding debate in the literature about what alignment is, why it is needed, how enterprises may go about the task of becoming aligned, and how it should best be researched [32]. Alignment definitions include: The degree of coherence between realized business strategy and realized IT strategy [33]; the degree of fit and integration among business strategy, IT strategy, business infrastructure, and IT infrastructure [34]; the basic principle is that IT should be managed in a way that mirrors management of the business [35]; good alignment means that the organization is applying appropriate IT in given situations in a timely way, and that these actions stay congruent with the business strategy, goals, and needs [36]; strategic alignment of IT exists when an organization’s goals and activities and the information systems that support them remain in harmony [37]; and alignment is the business and IT working together to reach a common goal [38]. In May 2013, a library database counts 281.152 peer-reviewed articles about “alignment”, and 21.199 about “business-IT alignment”. Alignment in an IT-context is today generally understood as the ability of the IT department to support the business department’s mission, vision and plans, and any existence of structures in the IT department to support the execution of the business requirements. When aligned, employees in IT act in such a way that their actions stay congruent with the business strategy, goals, and needs. However, such a definition of alignment confines the utilization to a paucity of cases. Sometimes IT is the primary anchor domain and the business is therefore required to align their strategic or structure to IT. Hence IT can both support and shape the business policies. In [34] a strategic alignment model is proposed to delineate alignment between IT and business, and the model features two types of integration: strategic integration and functional integration. Strategic integration is about alignment between strategy and operations, and is the alignment between the external and internal organizational domains (ibid). When organizations adopt a proven framework for alignment early in the planning process, these organizations save time and resources in the long run [39]. An empirical study of 63 enterprises [40] finds that there is a significant IT payoff for firms that practice strategic alignment, and other studies have shown that a strategic fit between business and IT strategies positively affect sales growth, profitability, and reputation [41][42][43].

Regardless of how IT-savvy an enterprise is, there are often other alignment needs than those between IT and business. The extended architecture focuses on all of the alignment needs of the enterprise, both in terms of strategic alignment and policy alignment, and in terms of lines of business and their alignment. In many ways, the embedded architecture is an attempt to move enterprise architecture away from the IT department and embed it in the organization’s everyday processes. The techniques and diagrams have not changed, it is the way they are used and governed by the organization that is new. This process has also been called moving from an EAaware to an EA-infused organization [31]. The three modes of architecture are processes of accumulation, and not replacement. It is important to stress the importance of an enterprise having a balanced enterprise architecture practice, meaning that all of the three modes should be present. Balanced architecture is when an organization utilizes the best and the most appropriate characteristics of each of the three modes of enterprise architecture.

III. TYPES OF ENTERPRISE ARCHITECT

The enterprise architect’s role is one of arranging unstructured information in a useful manner that guides decision-makers in making choices that lead to performance improvements, and the following roles for enterprise architects are suggested [8]:

1. Change agent: the enterprise architect supports enterprise leaders in establishing and promoting the best strategy to accomplish business goals and objectives.
2. Communicator: the enterprise architect assists managers, analysts, systems architects, and engineers in understanding the details of the strategy sufficiently well to make decisions and execute the plan that leads to realization of the shared vision.
3. Leader: the enterprise architect participates in creating a shared vision, motivating members of the enterprise to aspire to achieving the vision, and providing clear direction regarding what is required to execute a strategy to accomplish goals and objectives.
4. Manager: the enterprise architect organizes the architecture team and ensures that adequate resources are secured to perform the architecture process.
5. Modeler: the enterprise architect provides a representation of the relationships of enterprise components with sufficient detail and in the format needed to enable making necessary decisions to execute the strategic plan.

Others focus more on role-like competency areas, for example: credible expert, strategist, politician, and leadership [44]. Several authors have focused on intermediary competencies for enterprise architects [45][46][47][48] and [45] identifies the five most important as: analytical skills; communication skills; negotiation; abstraction capacity; and sensitivity and empathy, but also finds that creativity and leadership “appear to be essential for the enterprise architect”, and also identifies over 20 important competencies such as abstraction capacity, accurateness, and analytical skills. A recent survey about practicing enterprise architects [31] finds that the critical attributes of successful enterprise architects are Communicative, Pragmatic, Creative, Experienced, and Analytical. While these skills are important and necessary for practitioners, they do not say much about what the enterprise architects actually do. The work of the enterprise architecture function needs more attention [49][50]. As the enterprise architecture practice evolves, the work of the enterprise architects also evolves. Three types of enterprise architects can be identified [1]:

• Core enterprise architects: experts in enterprise architecture theory and practice.
• Implicit enterprise architects: those who support enterprise architecture work.
• Applied enterprise architects: those who define enterprise architecture requirements.

The core architects lead the enterprise architecture practice and understand the various approaches for doing enterprise architecture such that they can choose the right approach for that enterprise. They are architecture subject matter experts in enterprise architecture overall and in various supporting disciplines. They develop the standards, models, repositories, principles and the like. They are expected to be familiar with the numerous standards, conventions and communities involved in the enterprise architecture discipline. They also form an enterprise architecture team that is capable of conducting business requirement analyses at various levels of the enterprise, identifying viable alternatives and creating designs on behalf of the business owner(s) from the alternative that is selected.

Enacted business plans, business cases, organizational designs, job descriptions, process models, workflows, project plans, system specifications, information models, and the like comprise the enterprise’s architecture, we realize that the people who create such artifacts are, in a very real way, architects. However, they do not normally consider themselves to be ‘architects’. The idea behind embedded enterprise architecture is that we can provide these people with certain tools so that the ‘architecture’ they create can be standardized and their designs can be well constructed. The enterprise architect can then more readily use the ‘as found’ documentation. That is, the enterprise architect can use the documents as they were created for other prior purposes instead of reformatting them, re-creating them, modifying them, or entering them into a different tool. The enterprise architecture stays more current because the various process owners (implicit architects) create and use the documents as a part of their jobs, not as some extra task. These people, who have the potential to create and maintain much of the architecture, are thus an important part of the enterprise architecture team. There could be hundreds or thousands of implicit enterprise architects in medium and large size enterprises. Implicit enterprise architects can and should continue to function under their normal job titles, unless it is beneficial to give them a formal title that describes a specific architecture function – most likely a derivation of a core architecture job title. Therefore the term ‘implicit’ enterprise architect is a concept, not a job title or label that should be given to an individual.

Bridging the world of core and implicit enterprise architects are the applied enterprise architects. They have the task of figuring out which enterprise architecture capabilities are needed, in what form and where. They conduct the assessments and they help to promote ‘opportunistic architecture.’ This is where they take advantage of projects with certain characteristics to advance the goal of coherency. For example, they might know from previous assessments that the enterprise needs to standardize the way that they describe clients throughout all of the processes. If they see a project with a strong element of customer relationship management, they would support that project with an aim towards developing that standard. They would, as they start, ensure that major process owners from across the enterprise know that the standard for describing a ‘client’ is going to be established during the course of the project and then leverage those process owners in the development of the standard. The applied enterprise architects are usually a subset of the core enterprise architecture team, but logically separated to draw attention to the idea that from a pragmatic point of view, they may make compromises and prioritizations that the core architects should not need to consider.

IV. BOUNDARY-FOCUSED ARCHITECTS

Much of what enterprise architects do is transmit, translate and transform knowledge across boundaries, whether the boundary is between customer and vendor, between “business silos”, or between the classic ‘business ‘ and ‘IT’. A boundary object is something that can transmit, translate and transform knowledge across boundaries [51]. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds [52]. Boundary objects are concrete objects with the ability to span boundaries, such as repositories, standardized forms and methods, objects and models [53].

There are three categories of boundary objects [54]: First, artifacts, which are the shared tools, documents, models. Second, discourse, which is a common language that can be shared across communities of practice. Third, processes, i.e., the shared processes, routines, and procedures that facilitate coordination of and between communities of practice. The enterprise architect must therefore have a very deep understanding of boundaries and boundary objects, and how to work with those.

There are three types of boundaries an enterprise architect must work with: syntactic, semantic and pragmatic [55]. Syntactic boundaries assume that knowledge can be transferred between systems as long as a common syntax is in place [51]. If there is no common syntax, transfer errors occur: NASA crashed a probe into Mars in 1999, because the two involved engineering teams were using different measurement systems [26][56]. Foundation architecture can be seen as the mode of enterprise architecture which works best at such syntactic boundaries as enterprise architecture is seen here as “the organizing logic” [57]. Enterprise architecture is here observed as a syntax (organizing logic), which is used to speak about IT in relation to business. In [57], an enterprise architecture is more of an overview picture of how IT supports the different business processes; how they support the operating model chosen. In this model, the important relationships between the subsystems are made clear, so that the IT department can know how to best support the business, which can be made explicit through contracts and service-level agreements (SLA). Foundation architecture often employs a common modeling language or a shared repository, so that requirements from the business can be transferred to the IT department. At a semantic boundary, a common language is not enough; a common understanding is needed to translate knowledge across boundaries. An effective semantic boundary object provides a concrete means for individuals to specify and learn about their differences and dependencies across a given boundary [53]. In the extended architecture mode, the focus is on providing coherent views of an entire enterprise, encompassing strategy, business and technology. This mode of enterprise architecture thus offers the boundary objects needed to span semantic boundaries, as the focus is on creating shared understanding of the different levels in the EA3 Cube [18]. This view is especially useful as it offers the means to slice up the enterprise architecture and approach it e.g. according to line of business. In this way the shared understanding is easier to achieve, as you have a clear part of the enterprise you need to understand. An example could be the Asset Management business department of the acquiring enterprise in an M&A event, who needs to understand the Asset Management department of the acquired enterprise in order to understand the legal differences. Enterprise architecture could be used here to form a shared model and to do a gap analysis to understand the differences between the two. The purpose of the extended architecture mode, then, is to secure a shared understanding of the enterprise goal, which is often secured through modeling an asis and a to-be description at all levels of the company [18]. The pragmatic boundary [53] is the most socially and politically complex [51]. This is because above a shared language and understanding, a common interest needs to be established to transform knowledge across such boundaries. This is particularly a problem in mergers and acquisitions, as different departments will hold different interests in how the postmerger integration should happen. The embedded enterprise architecture mode can be seen as helping to mediate across such pragmatic boundaries. Here enterprise architecture tools, methods and models are embedded in the existing, everyday processes of the organization in order to create coherency across the entire enterprise [1]. The purpose of enterprise architecture, then, is to transform this message and make it a natural and interesting part of the working practice. If this enterprise architecture mode is used, the enterprise should also have the most important parts and data for the organization mapped prior to the re-sourcing, securing the organization against lost knowledge.

Like the different modes of enterprise architecture, the three types of boundaries are all represented between the subsystems in an organization. The complexity increases with each boundary type; again just as with the enterprise architecture modes. The syntactic boundary is the simplest boundary and foundation architecture is the least complex of the enterprise architecture modes, which means that the effort and previous experience in enterprise architecture is limited. The semantic boundary is more complex, together with an extended architecture. Lastly, the pragmatic boundary is the most complex and is best handled by an embedded architecture approach. The complexity of the boundary an organization is facing should match the complexity of the enterprise architecture approach employed, following Ashby’s law of requisite variety [58]: “Control can be obtained only if the variety of the controller is at least as great as the variety of the situation to be controlled”, often also formulated as only variety can absorb (or destroy) variety [25]. The enterprise architect has a crucial role in finding the right varieties for the right situations and contexts, often in the form of principles, standards, patterns and rules.

There are many benefits from doing enterprise architecture [59], such as business-IT alignment, standardized business processes, business and process flexibility, business transformation, IT cost reduction, operating cost reduction, application maintenance cost reduction, business risk management, senior management satisfaction, quality of service improvements, among many others. But these are all intermediate benefits contributing towards three primary benefits and outcomes: alignment, agility and assurance [1]. Alignment refers to the ability of the organization to operate as one by working towards a common shared vision supported by a well-orchestrated set of strategies and actions. Agility refers to the ability of the organization to respond to and manage change. Assurance refers to the ability of the organization to establish and institutionalize (internalize) practices that ensure fulfillment of organizational goals and achievement of outcomes. Enterprise architecture is a good approach to counteract short-termism and yet deliver immediate results, such as crucial prioritizations and essential impact analyses. On January 15, 2013, a Gartner press release [60] revealed that “Enterprise Architecture Practitioners Significantly Influenced $1.1 Trillion” in worldwide enterprise IT spending. Yet, enterprise architects often need to present measures that show enterprise architecture’s impact. This can be related to cost avoidance, risk mitigation and much more, where a traditional business case is often difficult to establish. But often times, the enterprise architect really only need one or two early ’successes’ that demonstrate enterprise architecture’s value to the enterprise to get initial buy-in [61]. However, the more successful enterprise architecture becomes in adding value to the enterprise, the more invisible it becomes; we can call it enterprise architecture by stealth, where enterprise architecture is done ‘everywhere’ in the enterprise [1]. Essentially, ‘enterprise’ means readiness to embark on bold new ventures. Enterprise architecture is especially helpful in highly complex transformations, such as M&A situations, and can be crucial to transforming enterprises, because it is essential for an enterprise to have an integrated and coherent approach to its strategies, business and technologies, and that is exactly what enterprise architecture is all about. Enterprise architecture is often considered a transformational effort dealing with change, but as laudable as that might be, this, in fact, falls well short of enterprise architecture’s full potential. If we only ever do enterprise architecture as part of a transformation project, how can enterprise architecture ever tell us what transformation to make? Therefore, enterprise architecture must become pervasive and regularized, and continuously be tied to on-going strategic planning and corporate governance.

V. THE DIALOGIC ARCHITECTS

The boundaries between “IT” and “business” are becoming more and more pragmatic, possibly because other boundaries have weakened. For example, mobile technologies such as iPads and cloud services such as Salesforce have made IT services much more available, accessible and attractive. The “Nexus of Forces” as research-advisory firm Gartner calls the combination of mobility, cloud, information (Big Data) and social media [62], is in many ways a “boundary meltdown” and opens many doors for the diligent enterprise architects. Cloud services exemplify a domain that enterprise architects “should” embrace. The hype about cloud services has turned away from pure technology, and now focuses on the business side, the economics and the governance aspects, all of which enterprise architects have a lot to contribute to [63]. The information area is already a traditional EA territory. Mobility has proven to be an area where enterprise architects can help the enterprise realize benefits. Unfortunately, many enterprises still choose to embark on unarchitected tactical initiatives, for example by asking an ad agency to create an app for a campaign. This may work for a single effort, but is bound to create problems in the long run, for example with integration. Some, more mature, enterprises instead look for more complete mobility platforms and frameworks. The market for such is still very immature, but highly dynamic with new players entering every day. The enterprise architects are the most obvious players inside the enterprise to review and assess the market offerings, and should strive for spearheading the enterprise’s mobility roadmap, which is rapidly turning into an allimportant architecture domain. And if Gartner is right, all the forces in the nexus will become enterprise architect territory: On April 2, 2013, Gartner announced that new research show that social collaboration efforts are a big challenge to many enterprises, and only has a 10% success rate [64]. Gartner suggests that “social collaboration is a challenge for which enterprise architects are well suited”, as they “are able to work with social initiative leaders to define community purposes and condense these purposes into a strategy or roadmap which they can use to guide project teams during implementation”. Incidentally, social collaboration has already become an issue within enterprise architecture itself, and more and more EA tools and repositories have added “social features”, e.g. [65]. The enterprise architect must be somewhat of a jack-of-alltrades, where both professional and personal competencies are important [66][67]. The Clinger-Cohen Core Competency area for enterprise architecture [17] encompasses the following competency areas: Enterprise architecture functions and governance; Key enterprise architecture concepts; Enterprise architecture interpretation, development, and maintenance; Use of enterprise architecture in IT investment decision making; Enterprise data management; and Performance measurement for enterprise architecture. While all of these continue to be important for all enterprise architects, not just in the US government, there will be more core competencies of relevance for enterprise architects in the coming years. In fact, the 11 other Clinger-Cohen Core Competencies all seem highly relevant for enterprise architects: Policy and Organization; Leadership and Human Capital Management; Process and Change Management; Information Resources Strategy and Planning; IT Performance Assessment: Models and Methods; IT Project and Program Management; Capital Planning and Investment Control; Acquisition; Information and Knowledge Management; Cybersecurity and Information Assurance; and Technology Management and Assessment. Also, there are a number of other enterprise competencies that are highly relevant for the enterprise architects, for example competencies in general strategic planning, corporate governance, investment management, operational excellence, quality management, and various business capabilities depending on which industry the enterprise is in.

The enterprise architecture practice should be collaborative [68]. In fact, enterprise architects should be cooperative in character, and be able to engage in many kinds of communications and collaborations. Enterprise architects must have competencies in resolving conflicts, and in creating consensus, synthesis and common understanding. Such dialectic skills [69] also include detecting what might establish that common ground and the skill of seeking the intent rather than just reading the face value of the words. Enterprise architecture management is dependent on individual decisions influenced by diverse internal and external psychological factors [70]. Developing the ability to cooperate gives architects the confidence to navigate complex interactions. In facing wicked problems [71], enterprise architects must focus more on problem-finding than problem-solving. In analogy with craftsmanship, craft looks at situations in a problemfinding manner [72]. When skilled in the craft of cooperation [69], and confident in their ability to negotiate complexity, the architects can interact with those who are different, antagonistic, or even aggressive towards them. Such dialogic skills [69] also include listening well, behaving tactfully, finding points of agreement and managing disagreement, and avoiding frustration in a difficult discussion. Dialogics, or the dialogical domain, is “that world of talk that makes an open social space, where discussion can take an unforeseen direction” [69]. Dialogic conversation, the “subjunctive mood in speech”, opens a “space of ambiguity” within the conversation, for all parties equally. It also facilitates empathy, which should be distinguished from sympathy, as curiosity or wonder about an other, as opposed to identification [69]. Enterprise architecture practitioners must become better at understanding “organizingness,” [73] that which helps technology become “integrated in the workflow, ‘aligned and ‘understood'”, and is “made by real world participants from absorbed coping, care, being there amidst ambiguity, intimacy, sporting hospitality as well as tamed hostility towards what the new and the unknown is disclosing” [74].

VI. THE ENTERPRISING ARCHITECTS

To fully understand the role of the enterprise architect, it is necessary to understand the word “enterprise”. Some refer to an enterprise as a “sociotechnical system”, but here “the ‘socio’ too often gets short shrift while the ‘technical’ gets the bulk of the attention,” [75] which is unfortunate since enterprise architecture is about the architecture of the enterprise and not restricted to technology in the enterprise [76]. Wordnet [77] defines enterprise as “a purposeful or industrious undertaking; an organization created for business ventures; readiness to embark on bold new ventures,” which shows the breadth of the concept of “enterprise,” and explains why enterprise architects should be “marked by imagination, initiative, and readiness to undertake new projects,” i.e., enterprising [77]. As the Chief Executive Officer is becoming a management architect [78], one who defines the principles and processes that can help an organization surface the best ideas and unleash the talents of everyone who works there, and one who wants to build a company that is truly fit for the future, there is here a golden opportunity for enterprise architects to step in and help enabling such surfacing and unleashing, but also to approach the executives about necessary structural innovations and enterprise investments [79]. The enterprise architect offers a view of the enterprise as a complex system of structures, assets and resources put in place to make it work, and should be able to assess what should be done to make it work even better. Alas, some of the established approaches to enterprise architecture have, appropriately, been criticized for having a “de-worlded” [73] view on the enterprise, where “systems are objects, knowledge is data, work is business process, and people are emotionless decision makers who have to align their preferences and adjust to the changes rationally planned for them” [74]. In a wider “big picture” of “enterprise”, there are two additional ways to see the enterprise [80]: Not only should the enterprise be seen as a mesh of personalities, impressions, and images in people’s minds, expressed in symbols, language, and culture and reflecting a shared sense of purpose; it should also be seen as an experiential space for interactions of people, environments, and artifacts, addressing human motivation, perception, and behavior. Thus, in addition to the architecture perspective on the enterprise, there are important perspectives on the enterprise related to identity and experience [80]. Bringing these three perspectives together has been labeled Enterprise Design [80], which centers on Strategic Design but involves enterprise architecture and several design disciplines, including, Service Design, Experience Design and Interaction Design. Related is also what Gartner called Hybrid Thinking, which should bring together the “analytical mastery of architects and the intuitive originality of designers” [71] in a hybrid of the disciplines Enterprise Architecture and Design Thinking [81].

As a young discipline, the enterprise architecture discipline must be aware of the risks of (disciplinary) conflation [76]. Yet, being defined as a meta-discipline, enterprise architecture is the organizing meta-context and standards authority for implementing all management and technology best practices [18], and Enterprise Investment [79] and Enterprise Design [80] should be seen as two emerging, and quite disruptive, such best practices that need attention. They are disruptive because they are contributing to build a “complete” theory of the enterprise, and both should therefore become core competency areas for core enterprise architects, and Enterprise Design for implicit and applied enterprise architects. Contributing to such theory this author would also include Systems Thinking, in particular the Viable System Model [25][26][28], because it provides a unique understanding of how an enterprise works. There are of course also other emerging best practices that enterprise architects need to cope with in order to fill out the role with success, including the earlier mentioned dialogic skills.

VII. CONCLUSIONS

Enterprise architecture is an evolving discipline, and the role of the enterprise architect is changing with it. In a wellestablished enterprise architecture practice there are core, applied and implicit enterprise architects, and enterprise architecture is a general management discipline practiced across boundaries by enterprising people with dialectic and dialogic skills.

REFERENCES

[1] Doucet, G., Gøtze, J., Saha, P., Bernard, S., 2009, ‘Coherency Management: Architecting the Enterprise for Alignment, Agility, and Assurance’, AuthorHouse.

[2] Lapalme, J.,2011, Three Schools of Enterprise Architecture, IT Professional, IEEE computer Society Digital Library, IEEE Computer Society, December 14, 2011.

[3] Korhonen, J.J. and J. Poutanen, 2013, Tripartite Approach to Enterprise Architecture. Journal of Enterprise Architecture, Vol 9 No 1.

[4] Iyer, B.and R. Gottlieb, 2004, The Four-Domain Architecture: An Approach to Support Enterprise Architecture Design, IBM Systems Journal, Vol. 43, No 3.

[5] Riege, C. and S. Aier, 2009, A Contingency Approach to Enterprise Architecture Method Engineering, in: ICSOC 2008, LNCS 5472, 388- 399, Springer-Verlag, Berlin Heidelberg.

[6] Aier, S. and J. Schelp, 2010, A Reassessment of Enterprise Architecture Implementation, in: A. Dan, F. Gittler, F. Toumani (Eds.), ICSOC/ServiceWave 2009, LNCS 6275, 35-47, Springer- Verlag.

[7] Van Steenbergen, M., 2011, Maturity and Effectiveness of Enterprise Architecture, PhD Dissertation, University Utrecht.

[8] Strano, C. and Q. Rehmani, 2007, The role of the enterprise architect. Information Systems and e-Buisness, 5(4):379-396.

[9] Hirschheim, R., Klein, H.K., & Lyytinen, K., 1995, Information Systems Development and Data Modeling: Conceptual and Philosophical Foundations, Cambridge University Press, Cambridge, 1995.

[10] Zachman, J.A., 1987, A Framework for Information Systems Architecture, in IBM Systems Journal, Vol. 26, No. 3, pp454-470.

[11] Opdahl, A. & Päivärinta, T., 2003, The multiple Life Cycle Perspective on Information Systems Architecture, In: Proceedings of the 26th Information Systems Research Seminar in Scandinavia (IRIS).

[12] Nolan, R.L., 1973, Managing the computer resources: A stage hypothesis, Communications of the ACM (16:7), pp 399-405.

[13] Nolan, R.L., 1979, Managing the crisis in data processing, Harvard Business Review: March/April) 1979.

[14] Cook, M.A., 1996, Building Enterprise Information Architectures: Reengineering Information Systems, Prentice Hall, Upper Saddle River NJ, 1996.

[15] Ward, J. & Peppard, J., 2002, Strategic Planning for Information Systems, (3rd ed.) Wiley, Chichester.

[16] Hjort-Madsen, K., 2009, Architecting Government: Understanding Enterprise Architecture Adoption in the Public Sector. PhD Dissertation, IT University of Copenhagen.

[17] CIO Council, 2012, 2012 Clinger-Cohen Core Competencies & Learning Objectives https://cio.gov/wp-content/uploads/downloads/ 2013/01/2012-Learning-Objectives-Final.docx

[18] Bernard, S.A., 2012, ‘An introduction to Enterprise Architecture’, AuthorHouse, 3rd edition.

[19] Office of Management and Budget, 2012, ‘The Common Approach to Federal Enterprise Architecture’. Executive Office of the President of the United States.

[20] Jackson, M.C., 2000, ‘Systems approaches to management’, Kluwer Academic/Plenum Publishing, New York

[21] Jensen-Waud, A.Ø. & Gøtze, J., 2012, ‘A Systemic-Discursive Framework for Enterprise Architecture‘, Journal of Enterprise Architecture, vol. 8, issue 3.

[22] Hoogervorst, J.A.P., 2009, ‘Enterprise governance and enterprise engineering’, Sogeti Nederland B.V., Springer.

[23] Gøtze, J. & M. Axél, 2013, Sourcing from an Enterprise Architecture Perspective. In Dijkstra, R., Gøtze, J., P.v.d. Ploeg (eds.) Right Sourcing: Enabling Collaboration. Bloomington, IL: Authorhouse.

[24] Pulkkinen, M., 2006, Systemic Management of Architectural Decisions in Enterprise Architecture Planning: Four Dimensions and Three Abstraction Levels, Proceedings of the 39th Annual Hawaii International Conference on System Sciences.

[25] Beer, S. 1972, Brain of the Firm – The Managerial Cybernetics of Organization, London: Allen Lane and Penguin Press.

[26] Hoverstadt, P., 2008, The Fractal Organization: Creating Sustainable Organizations with the Viable System Model, Chichester: John Wiley & Sons.

[27] Zadeh, M. E., G. Millar and E. Lewis, 2012, Reinterpreting TOGAF’s Enterprise Architecture Principles Using a Cybernetic Lens. Journal of Enterprise Architecture, Vol 8, No 2.

[28] Buckl, S., Schweda, CM, and Matthes, F., 2009, A Viable System Perspective on Enterprise Architecture Management. In Proceedings of SMC, 1483-1488.

[29] Potts, C., 2011, The consumer has the technology. The market has the process. BPTrends, Sept.

[30] Højsgaard, H., 2011, Market-Driven Enterprise Architecture. Journal of Enterprise Architecture, Vol 7 No 1.

[31] Cumps, B., S. Viaene, P. Dussart, J. Vanden Brande, 2013, Towards Enterprise Architecture-Infused Organizations. Journal of Enterprise Architecture, Vol9, No2.

[32] Avison, D., J. Jones, P. Powell and D. Wilson, 2004, Using and validating the strategic alignment model. Journal of Strategic Information Systems 13, 223–246.

[33] Chan, Y. E. and B. H. Reich, 2007, IT alignment: what have we learned? Journal of Information Technology 22, 297–315

[34] Henderson, J., Venkatramen, N., 1989, Strategic Alignment: A Model for Organisational Transformation, in Kochan, T., Unseem, M. (Eds.), 1992. Transforming Organisations. OUP, New York.

[35] Sauer and Yetton, 1997, (eds.) Steps to the Future: Fresh thinking on the management of IT-based organizational transformation, 1st edn, San Francisco: Jossey-Bass, pp. 1–21.

[36] Luftman, J., Brier, T., 1999, Achieving and Sustaining Business-IT Alignment. California Management Review, Fall, 1999, Vol.42(1), p.109

[37] McKeen, J.D. and Smith, H., 2003, Making IT Happen: Critical issues in IT management, Chichester, Hoboken, NJ: Wiley.

[38] Campbell, B., 2005, Alignment: Resolving ambiguity within bounded choices, PACIS 2005, Bangkok, Thailand. 1–14.

[39] Kearns, G. S., & Sabherwal, R., 2007, Strategic Alignment Between Business and Information Technology: A Knowledge-Based View of Behaviors, Outcome, and Consequences. Journal of Management Information Systems, 23(3), 129–162.

[40] Tallon, P. P., & Kraemer, K. L., 2003, Investigating the relationship between strategic alignment and IT business value: the discovery of a paradox. (N. Shin, Ed.)Business, 12, 1–22.

[41] Tallon, P. P., & Pinsonneault, A., 2011, Competing perspectives on the link between strategic information technology alignment and organizational agility: insights from a mediation model. MIS Quarterly, 35(2), 463–486.

[42] Thatcher, M. E., & Pingry, D. E., 2007, Modeling the IT value paradox. Communications of the ACM, 50(8), 41–45. doi:10.1145/1278201.1278204

[43] Watson, B. P., 2007, Is Strategic Alignment Still a Priority? CIO Insight, (86), 36–39.

[44] Bredemeyer, D., Malan, R, 2004, What it takes to be a great enterprise Architect. Enterprise Architecture Executive Report 7(8), Cutter Consortium

[45] Op ’t Land, M., E. Proper, M. Waage, J. Cloo, C. Steghuis, 2009, Enterprise Architecture. Springer

[46] Bean, S., 2006, The elusive enterprise architect. IT Adviser.

[47] Walker, M., 2007, A day in the life of an enterprise architect. Technical Report, Microsoft Corporation. http://msdn2.microsoft.com/enus/ library/bb945098.aspx

[48] Steghuis, C., Voermans, K., Wieringa, R., 2005, Competencies of the ICT architect. Technical Report, Netherlands Architecture Forum.

[49] Raadt, B.v.d., H. v. Vliet, 2008, Designing the Enterprise Architecture Function. In Quality of Software Architectures. Models and Architectures. Lecture Notes in Computer Science Volume 5281, pp 103-118

[50] Raadt, B.v.d., Bonnet, M., Schouten, S., van Vliet, H., 2010, The relation between EA effectiveness and stakeholder satisfaction. The Journal of Systems & Software Vol.83(10), pp.1954-1969

[51] Spee, A.P. & Jarzabkowski, P., 2009, ‘Strategy tools as boundary objects’, Strategic Organization, vol. 7, issue 2, pp. 223-232, Sage Publications.

[52] Star, S.L., Griesemer, J.R., 1989, ‘Institutional Ecology, ‘Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39’, Social Studies of Science, Vol. 19, No. 3, pp. 387-420.

[53] Carlile, P.R., 2002, ‘A pragmatic view of knowledge and boundaries: Boundary objects in new product development’, Organizational Science, vol. 13, no. 4, Jul-Aug 2002, pp. 442-455

[54] Wenger, E., 2000, ‘Communities of Practice and Social Learning Systems’, Organization, Volume 7(2): 225-246.

[55] Axél, M., 2012, ‘Managing post-merger IS integration through Enterprise Architecture from a constructivist systems theory perspective’, Master Thesis. IT University of Copenhagen.

[56] Grossman, L., 1999, Metric Math Mistake Muffed Mars Meteorology Mission. Wired Nov. 10, 1999. http://www.wired.com/thisdayintech/ 2010/11/1110mars-climate-observer-report/

[57] Ross, J.W., Weil, P. & Robertson, D.C., 2006, Enterprise architecture as strategy: Creating a foundation for business execution, Harvard Business School Press.

[58] Ashby, W.R., 1957, An introduction to cybernetics, Chapman & Hall, London.

[59] Tamm, T., P. B. Seddon, G. Shanks and P. Reynolds, 2011. Delivering Business Value Through Enterprise Architecture. Journal of Enterprise Architecture, Vol 7, No 2.

[60] Gartner, 2013, Enterprise Architecture Practitioners Significantly Influenced $1.1 Trillion, Press release January 15, 2013.

[61] Mayo, D. and M. Tiemann, 2005, EA: It’s Not Just for IT Anymore, Journal of Enterprise Architecture, Volume 1, Number 1.

[62] Howard, C., D. C. Plummer, Y. Genovese, J. Mann, D. A. Willis and D. M. Smith, 2012, The Nexus of Forces: Social, Mobile, Cloud and Information”. Gartner Research Note, 14 June 2012.

[63] Ommeren, E. v. and M.v.d. Berg, 2011, Seize the Cloud: A Manager’s Guide to Success with Cloud Computing. Sogeti.

[64] Gartner, 2013, Gartner Says the Vast Majority of Social Collaboration Initiatives Fail Due to Lack of Purpose. Press release 2 April 2013.

[65] Software AG, 2012, Software AG’s ARIS 9.0 brings the Power of Social to Business Process Improvement. Press Release, October 2012. http://www.softwareag.com/corporate/Press/pressreleases/ 20121015_Aris_9_0_page.asp

[66] Steghuis, C. and E. Proper, 2008, Competencies and Responsibilities of Enterprise Architects. Advances in Enterprise Engineering I. Lecture Notes in Business Information Processing Volume 10, pp 93-107, Springer.

[67] Tambouris,, E, M. Zotou, E. Kalampokis and K. Tarabanis, 2012, Fostering enterprise architecture education and training with the enterprise architecture competence framework. International Journal of Training and Development 16:2.

[68] Bente, S., U. Bombosch, S. Langade, 2012, Collaborative Enterprise Architecture. Enriching EA with Lean, Agile, and Enterprise 2.0 Practices. Boston, Morgan Kaufmann.

[69] Sennett, R., 2011, Together: The Rituals, Pleasures and Politics of Cooperation, Yale University Press.

[70] Ahlemann, F., K. Mohan and D. Schäfczuk, 2012, People, adoption and introduction of EAM. In Ahlemann, F. et al. (eds.), Enterprise Architecture Strategic Management: Challenges, Best Practices, and Future Developments, Management for Professionals. Berlin Heidelberg, Springer-Verlag.

[71] Sennett, R., 2008, The Craftsman. Allen Lane

[72] Gall, N., D. Newman, P. Allega, A. Lapkin, R.A. Handler, 2010, Introducing Hybrid Thinking for Transformation, Innovation and Strategy. Gartner Research ID Number: G00172065, 13 April 2010

[73] Ciborra, C., 2001, From Control to Drift: The Dynamics of Corporate Information Infrastructures. Oxford University Press.

[74] Ciborra, C., 1997, De profundis? Deconstructing the concept of strategic alignment. Scandinavian Journal of Information Systems, 9(1):67–82

[75] Fehskens, L., 2011, Enterprise Architecture’s Quest for its Identity. Open Group Blog 10 Mar 2011. http://wp.me/p1cB5i-85

[76] Fehskens, L., 2012, Why We Can’t Agree on What We Mean by “Enterprise Architecture” and Why That’s OK, At Least for Now. Open Group Blog 10 Apr 2012. http://wp.me/p1cB5i-oF

[77] Wordnet, 2013, Dictionary entry for the noun “Enterprise”. http://wordnetweb.princeton.edu/perl/webwn?s=enterprise

[78] Hamel, G., 2012, What matters now. How to win in a world of relentless change, ferocious competitiion, and unstoppable innovation. Jossey- Bass Wiley.

[79] Potts, C., 2012, DefrICtion: Unleashing your Enterprise to Create Value from Change. Technics Publications.

[80] Guenther, M., 2012, Intersection: How Enterprise Design Bridges the Gap Between Business, Technology, and People. Morgan Kaufmann.

[81] Brown, T., 2005, Design Thinking. Harvard Business Review 2008(6).