Enterprise Architecture at the Crossroads

Enterprise Architecture is facing several challenges as a discipline and a practice. In this blog post, John Gøtze outlines four central challenges, and discusses what should be done. He suggests that enterprise architecture management must focus on enterprise collaboration.

The Challenges

The discipline Enterprise Architecture (EA) is at a crossroads, facing four challenges:

  • The first challenge is to overcome the narrowness of scope of present practice in EA, and re-gain the coverage of the entire business on all levels of management, and a holistic and systemic coverage of the enterprise as an economic entity in its social and ecological environment.
  • The second challenge is how to face the problems caused by complexity that limit the controllability and manageability of the enterprise as a system.
  • The third challenge is connected with the complexity problem, and describes fundamental issues of sustainability and viability.
  • Following from the third, the fourth challenge is to identify modes of survival for systems, and dynamic system architectures that evolve and are resilient to changes of the environment in which they live.

A recent (in-press) peer-reviewed article, Enterprise Engineering and Management at the Crossroads – the result of a collaborative effort between eleven authors from four continents – discusses these four challenges and the state of the art of the discipline of Enterprise Architecture, with emphasis on the challenges and future development opportunities of the underlying information system, and its IT implementation, the Enterprise Information System (EIS).

Responses

The article provides pointers to possible radical changes to models, methodologies, theories and tools in EIS design and implementation, with the potential to solve these grand challenges:

bernusetal-fig1

Towards Solutions

The article argues that EA needs to embrace full or broad views of the enterprise as per the original vision of the discipline’s mission that originated in manufacturing (e.g. computer integrated manufacturing systems), and the parallel developments in information systems and software development. This division between information systems, system science, and manufacturing & industrial engineering needs to be resolved as it is still felt today and hampers the discipline of EA as a whole. Any credible development of the discipline must equally cover and explain deliberate change and evolutionary change in a system of socio-technical systems, the production & service to the customer, and the management & control of the enterprise, the technical resources (logistics, manufacturing machinery, communication systems, computer systems), human resources, financial resources, and assets of all other kind (knowledge & information assets, buildings and grounds, and various intangibles).

As EA is moving up the hierarchy from technical to management levels, the language and skill set of its practitioners has to change to better reflect the specific needs and language of the management community. This needs to be reflective in terms of not only language, but also culture. The focus must be on views of the organisation that management science is interested in (People, Capability, Place, Role, Relationships and Trust, Risk, Finance, Brand Strategy, Knowledge Management) rather than detailed, possibly local technical views of the organisation.

A central concern in EA is the development of the information system that implements a coherent, aware behaviour of the enterprise on any scale. It is acceptable (even desirable) that the implementation of these properties should not have a single locus, so that the system should display these properties without a single subsystem or system component being responsible for them. If awareness and coherency are emergent properties of the enterprise, it is likely that the enterprise (and its information system) would be more resilient in terms of being able to maintain these systemic properties.

A New Paradigm for EA

The article suggests a new paradigm for EA:

It is clear that the future is not in EA reinventing the complete gamut of management models, but it is in providing a unifying platform through which the multiple models used in the various life cycle phases and in the various stages of the enterprise’s life history can be combined. The combination needs a new paradigm though, as current EA methodologies struggle with the reality of complex relationships among models present at different abstraction levels. In essence, guided evolution of the enterprise requires that enterprise modelling not be seen as a top-down or bottom up process, but as a powerful problem finding and problem solving tool that supports transformational activities both on the strategic and operational levels.

In my article from 2013, The Changing Role of the Enterprise Architect, I argue that in facing ‘wicked problems’, enterprise architects must focus more on problem-finding than problem-solving; true craftsmen look at situations in a problem-finding manner, rather than blindly applying the same method and tool every time to what may be a new and interesting challenge.

Enterprise architecture practice must be collaborative, and enterprise architects should be cooperative in character, able to engage in many kinds of communication and collaboration. I argue that enterprise architects must have both:

  1. dialectic skills and competencies in resolving conflicts, creating consensus, synthesis and common understanding, detecting what might establish that common ground, and the skill of seeking the intent rather than just reading the face value of the words, and
  2. dialogic skills including listening well, behaving tactfully, finding points of agreement, managing disagreement, and avoiding frustration in a difficult discussion.

Jason Uppal picks up on this in his lecture at a recent EA conference.

The dialectic/dialogic distinction is of course a classic discourse in educational research (see for example Rupert WegerifRichard Paul, and Andrew Ravenscroft) and generally throughout the critical social sciences (“Bakhtinian dialogic and Vygotsky’s dialectic”) ever since Hegel.

In Together: The Rituals, Pleasures, and Politics of Cooperation sociologist Richard Sennett states that the distinction between dialogic and dialectic is fundamental to understanding human communication. Sennett says that dialectic deals with the explicit meaning of statements, and tends to lead to closure and resolution. Whereas dialogic processes, especially those involved with regular spoken conversation, involve a type of listening that attends to the implicit intentions behind the speaker’s actual words. Unlike a dialectic process, dialogics often do not lead to closure and remain unresolved. Compared to dialectics, a dialogic exchange can be less competitive, and more suitable for facilitating cooperation. Sennett explains further in a lecture at Harvard: The Architecture of Cooperation.

The Importance of Enterprise Collaboration

Cooperation and collaboration are closely related concepts, and often thought of as synonymous. In fact, they are quite different.

Oscar Berg‘s Collaboration Pyramid may explain the difference:

Collaboration Pyramid

Berg distinguishes between the three layers in this way:

  • The community is the enterprise seen as a group of individuals that share the same purpose, vision and values. It is about shared attitudes and behaviors within the enterprise, or the culture if you like. It is also about the individual’s ability to be seen, participate and be recognized, all of which are fundamental for developing a sense of belonging, identity, and self-confidence.
  • Cooperation is about people enabling each other to do something, for example by providing a person with information or other resources that make the person more able to perform a task. Cooperation can be seen as the opposite of selfishness and competition. People help each other out for some mutual benefit.
  • Collaboration is about a team of people that work closely together to achieve a certain goal. It can be a permanent team, like a production unit at an assembly line, or temporary team, like a project team. The team would most likely have a formally appointed leader, someone who is responsible for the planning, coordination, follow-up, and communication within the team as well as the world outside the team.

Enterprise collaboration is a term that covers all these three all-important concepts of the “social” enterprise. The term is often mistakenly used to cover social networking tools and intranet, but should be seen as a wider concept and a more comprehensive platform for the enterprise, wherefrom strategic alignment and viable process and information flows are tangible outcomes.

In our Collaboration whitepaper, we explain further how QualiWare is enabling our customers to work with collaboration in their enterprise architecture work.

Become a Certified Enterprise Architect

cmuThe Carnegie Mellon University Certified Enterprise Architect Program is one of QualiWare Academy‘s core certification  offerings.

Currently offerings include:

Denmark

Norway

  • EA Fundamentals, tba
  • EA Applied, tba
  • EA Advanced, tba

 

 

EA³: A Primer

John Gøtze, PhD

Enterprise Architecture is an emerging profession and management practice that is devoted to improving the performance of enterprises by enabling them to see themselves in terms of a holistic and integrated view of their strategic direction, business practices, information flows, and technology resources. By developing current and future versions of this integrated view, an enterprise can better manage the transition from current to future operating models and methods. This transition includes the identification of new goals, activities, and all types of capital and human resources (including information technology) that will improve bottom line financial and mission performance. 

The strategic use of resources is increasingly important to the success of public and private sector enterprises, including extended enterprises involving multiple internal and external participants (e.g., supply chains). How to get the most from business, technology, and human resources requires an enterprise to think in terms of enterprise-wide solutions, rather than individual system development projects. Doing this requires a new approach to planning and systems development, an approach that has come to be known as Enterprise Architecture (EA). The word ‘enterprise’ implies a high-level, strategic view of the entire organization, while the word ‘architecture’ implies a structured framework for the analysis and design of all types of resources.

With regard to resources, one of the greatest challenges that many enterprises continue to face is how to identify the business and technology components of strategic initiatives. A big part of this challenge is that technology, information technology (IT) in particular, has historically not been viewed as a strategic asset in many enterprises. As such, traditional planning activities often focused on the development of individual technology solutions to meet particular organizational requirements. Today, a much more integrated and collaborative planning approach is called for. That is enterprise architecture in a nutshell.

The EA³ Cube approach

The EA³ Cube approach (“EA³″) was developed by Scott A Bernard and is today used in academic and professional EA training programs all over the world, including Carnegie Mellon University’s Certified Enterprise Architect program. The EA³ approach has also had a clear impact on many practitioners, who use it as a practice approach. EA³ has been the foundation for several government EA approaches, including the US Government’s Common Approach to Federal EA and the FEAF-II Framework. Today, EA³ is owned and maintained by the International EA Institute.

This paper provides an overview of the enterprise architecture approach known as EA³.

In EA³, the following equation is the ‘sound bite’ version of what enterprise architecture is all about, and is intended to help people remember the distinct difference between EA and the various types of IT planning: that EA is driven by strategic goals and business objectives:

EA = S+B+T
Enterprise Architecture = Strategy + Business + Technology

This “SBT” formulae is in EA3 more formally used when defining enterprise architecture:

Enterprise Architecture is the analysis and documentation of an enterprise in its current and future states from an integrated strategy, business, and technology perspective.

Enterprise Architecture is a strategy and business-driven activity that supports management planning and decision-making by providing coordinated views of an entire enterprise. These views encompass strategy, business, and technology, which is different from technology-driven, systems-level, or process-centric approaches.

Establishing an enterprise architecture practice typically involves implementing an enterprise architecture management program and adopting a framework-based design and analysis method for enterprise planning activities. 

Enterprise Architecture as a Practice

Enterprise Architecture is a management and technology practice that is devoted to improving the performance of enterprises by enabling them to see themselves in terms of a holistic and integrated view of their strategic direction, business practices, information flows, and technology resources.

By developing current and future versions of this integrated view, an enterprise can manage the transition from current to future operating states.

The strategic use of resources is increasingly important to the success of public, private, and non-profit sector enterprises, including extended enterprises involving multiple internal and external participants (i.e., supply chains). How to get the most from business, technology, and human resources requires an enterprise to think in terms of enterprise-wide solutions, rather than individual systems and programs (Figure 1-1). Doing this requires a new approach to planning and systems development, an approach that has come to be known as Enterprise Architecture. The word ‘enterprise’ implies a high-level, strategic view of the entire entity, while the word ‘architecture’ implies a structured framework for the analysis, planning, and development of all resources in that entity.

fig1-1
Figure 1-1: The Organizing Influence of Enterprise Architecture

With regard to resources, one of the greatest challenges that many enterprises continue to face is how to identify the business and technology components of strategic initiatives. A big part of this challenge is that technology, information technology (IT) in particular, has historically not been viewed as a strategic asset. As such, planning activities often have focused on the development of individual technology solutions to meet particular organizational requirements.

“Enterprise architecture” is both a noun and a verb. The architecture of an enterprise is a thing – captured as a collection of models and information. Creating an enterprise-wide architecture is accomplished through processes that are sustained through an ongoing management program. EA provides a strategy and businessdriven approach to policy, planning, decision-making, and resource development that is useful to executives, line managers, and support staff. To be effective, an EA program must be part of a group of management practices that form an integrated governance structure, as is shown in Figure 1-2.

fig1-2
Figure 1-2: Major Areas of Integrated Governance

Enterprise Architecture as a Meta-Discipline

An enterprise-wide architecture should serve as an authoritative reference, source of standards for processes / resources, and provider of designs for future operating states. An EA is therefore THE architecture of the enterprise and should cover all elements and aspects. Having a single source of reference is essential to avoiding waste and duplication in large, complex organizations. It also resolves the “battle of best practices” and competition between sub-architectural domains which can be problematic for organizations that are trying to become for efficient.

Developing an enterprise-wide architecture is a unique and valuable undertaking for organizations, in that the EA is holistic and serves as an umbrella or “metacontext” for all other management and technology best practices. The EA also creates abstract views, analyses, and models of a current or future enterprise that helps people make better plans and decisions. EA extends beyond technology planning, by adding strategic planning as the primary driver of the enterprise, and business planning as the source of most program and resource requirements. There is still a place for technology planning, which is to design systems, applications, networks, call centers, networks, and other capital resources (e.g. buildings, capital equipment) to meet the business requirements… which are the heart of the enterprises activities… creating and delivering those products and services that accomplish the strategic goals of the enterprise.

Regarding the “battle of the best practices”, organizations in the public and private sectors are often faced with decisions about which practices to adopt as they pursue quality, agility, efficiency; manage risk, and adopt new technologies. There are dozens of best practices out there, and most of them were created in isolation – relative to the other best practices. This is the “battle of the best practices” and it creates an expensive dilemma for organizations – what to adopt? Because the implementation and maintenance methods for many of the best practices are very resource intensive, and the scope is not all-inclusive, the organization is faced with the challenge of deciding which to adopt, how to do it, and what overlaps, contradictions, and gaps are produced from the resulting collection. When EA is THE architecture of an organization in all dimensions, it becomes the over-arching, highest level discipline and the authoritative reference for standards and practices. This is a tremendous and unique contribution, because when EA is used in this way, the dilemma disappears and organizations can use the EA framework to make rational decisions about which best practices need to be adopted, what they will cover, and how they can relate to each other. Figure 1-3 illustrates how EA serves as an organizing context for the adoption and use of best practices.

fig1-3
Figure 1-3: Enterprise Architecture as a Meta Discipline.

When identifying and selecting best practices enterprises should consider the following enterprise concerns:

  • Coherency – does the best practice “fit” with the bigger picture? Does it overlap with other practices?
  • Consensus – all relevant stakeholders and employees must “follow” to ensure successful implementation of new practices.
  • Consistency –  enterprise-wide adoption or not? Ensuring consistent use of best practices across the enterprise.

The Enterprise Architecture Approach

For an EA approach to be considered to be complete, the six core elements shown in Figure 1-4 must be present and work synergistically together.

fig1-4
Figure 1-4: Core Elements of an Enterprise Architecture Approach

Governance

The first core element is “Governance” which identifies the planning, decision-making, and oversight processes and groups that will determine how the EA is developed and maintained, accomplished as part of an organization’s overall governance.

Methodology

The second core element is “Methodology” which are specific steps to establish and maintain an EA program, via the selected approach.

Framework

The third core element is “Framework” which identifies the scope of the overall architecture and the type and relationship of the various subarchitecture levels and threads. Not all frameworks allow for sub-domains or are able to integrate strategy, business, and technology planning.

Artifacts

The fourth core element is “Artifacts” which identifies the types and methods of documentation to be used in each sub-architecture area, including strategic analyses, business plans, internal controls, security controls, and models of workflow, databases, systems, and networks. This core element also includes the online repository where artifacts are stored.

Standards

The fifth core element is “Standards” which identify business and technology standards for the enterprise in each domain, segment, and component of the EA. This includes recognized international, national, local, and industry standards as well as enterprise-specific standards.

Best Practices

The sixth core element is “Associated Best Practices” which are proven ways to implement parts of the overall architecture or sub-architectures, in context of the over-arching EA.

Extended elements list: The Common Approach’s Basic Elements: Governance, Method, Standards, Principles, Tools, Use, Reporting, and Audit.

Enterprise Architecture Activities

Enterprise architecture is accomplished through a management program and an analysis and design method that is applicable to various levels of scope. Together the EA program and method provide an ongoing capability and actionable, coordinated views of an enterprise’s strategic direction, business services, information flows, and resource utilization.

EA as a Management Program

The EA management program is ongoing and provides a strategic, integrated approach to capability and resource planning / decision-making. An EA program is part of an overall governance process that determines resource alignment, develops standardized policy, enhances decision support, and guides development activities. EA can help to identify gaps in the performance of line of business activities/programs and the capabilities of supporting IT services, systems, and networks. The following paragraphs will describe five different means that contribute to identifying and alleviating gaps.

Strategic Alignment

EA supports strategic planning and other operational resource planning processes by providing macro and micro views of how resources are to be leveraged in accomplishing the goals of the enterprise. This helps to maximize the efficiency and effectiveness of these resources, which in turn will help to promote the enterprise’s competitive capabilities. Development projects within the enterprise should be reviewed to determine if they support (and conform to) one or more of the enterprise’s strategic goals. If a resource and/or project is not aligned, then its value to the enterprise will remain in question, as is shown in Figure 1-5.

fig1-5
Figure 1-5: Strategic Alignment of Capabilities and Resources

Standardized Policy

EA supports the implementation of standardized management policy pertinent to the development and utilization of IT and other resources. By providing a holistic, hierarchical view of current and future resources, EA supports the establishment of policy for: Identifying strategic and operational requirements Determining the strategic alignment of activities and resources Developing enterprise-wide business and technology resources Prioritizing the funding of programs and projects Overseeing the management of programs and projects Identifying performance metrics for programs and projects Identifying and enforcing standards and configuration management.

Policy documents include those which can be categorized as general guidance (e.g., high-level directives and memos); specific program guidance (e.g., plans, and manuals); and detailed process guidance (e.g., standard operating procedures). By using these hierarchical categories of documents, succinct and meaningful policy is established. It does so in a way that no single policy document is too long and therefore not too burdensome to read. It is also important to understand how the various areas of policy are inter-related so that program implementation across the enterprise is coordinated. EA policies must integrate with other policies in all governance areas, so as to create an effective overall resource management and oversight capability.

Decision Support

EA provides support for IT resource decision-making at the executive, management, and staff levels of the enterprise. At the executive level, EA provides visibility for large IT initiatives and supports the determination of strategic alignment. At the management level, EA supports design and configuration management decisions, as well as the alignment of IT initiatives with technical standards for voice, data, video, and security. At the staff level, EA supports decisions regarding operations, maintenance, and the development of IT resources and services.

Resource Oversight

EA supports standardized approaches for overseeing the development of capabilities and optimizing supporting resources. Depending on the scope of the resources involved and the available timeframe for development, various system development lifecycle methods can be used to reduce the risk that cost, schedule, or performance parameters may not be met. EA further supports standardized, proven approaches to project management that promote the comprehensive and effective oversight of ongoing programs and new development projects. Finally, EA supports the use of a standardized process for selecting and evaluating investment in IT resources from a business and financial perspective.

EA as an Analysis and Design Method

References to EA began to emerge in the late 1980’s in various management and academic literatures, with an early focus on technical or systems architectures and schemas for organizing information. The concept of ‘enterprise’ architecture analysis and design emerged in the early 1990’s and has evolved to include views of strategic goals, business services, information flows, systems and applications, networks, and the supporting infrastructure. Additionally, there are ‘threads’ that pervade every level of the architecture: standards, security, and skills.

EA analysis and design are accomplished through the following six basic elements: (1) an EA framework, and (2) a set of appropriate components that are described via (3) current and (4) future views of the architecture, as well as the development of (5) an EA Management Plan to manage the enterprise’s transition from current to future architectures. There are also several areas common to all levels of the framework that are referred to as (6) “threads” as shown in Figure 1-6.

fig1-6
Figure 1-6: Basic Elements of EA Analysis and Design

EA Analysis and Design Element #1: The Framework.

The EA framework identifies the scope of the architecture to be developed and establishes relationships between the architecture’s areas. The framework’s scope is reflected through its geometric design and the areas that are identified for documentation. The framework creates an abstracted set of “views” of an enterprise through the way that it collects and organizes architecture information.

fig1-7
Figure 1-7: EA³ Cube Analysis & Design Framework

The EA³ Cube Framework has hierarchical levels – sub-architectures – so that the different distinct functional areas can be logically related to each other. This is done by positioning high-level strategic goals/initiatives at the top, business products/services and data/information flows in the middle, and supporting systems/applications and technology/infrastructure at the bottom. In this way alignment can also be shown between strategy, information, and technology, which aids planning and decision-making.

To lower risk and promote efficient, phased implementation methods, the EA framework is divided into segments of distinct activity, referred to as Lines of Business (LOBs). For example, each LOB has a complete subarchitecture that includes all five hierarchical levels of the EA³ framework. The LOB therefore can in some ways stand alone architecturally within the enterprise except that duplication in data, application, and network functions would occur if each LOB were truly independent. An architecture encompassing all five framework levels that is focused on one or more LOBs can be referred to as a segment of the overall EA.

Key Term: Line of Business
A Line of Business (LOB) is a distinct area of activity within the enterprise. It may involve the manufacture of certain products, the provision of services, or internal administrative functions.

Key Term: Architecture Segment
A part of the overall EA that documents one or more lines of business at all levels and threads. A segment can exist as a stand-alone part of the EA.

EA Analysis and Design Element #2: EA Components

EA components are changeable goals, processes, standards, and resources that may extend enterprise-wide or be contained within a specific line of business or segment. Examples of components include strategic goals and initiatives; business products and services; information flows, knowledge warehouses, and data objects; information systems, software applications, enterprise resource programs, and web sites; voice, data, and video networks; and supporting infrastructure including buildings, server rooms, wiring runs/closets, and capital equipment. Figure 1-8 on the next page provides examples of vertical and crosscutting EA components at each level of the EA³ Cube framework.

fig1-8
Figure 1-8: Examples of EA Components

EA Analysis and Design Element #3: Current Architecture

The current architecture contains those EA components that currently exist within the enterprise at each level of the framework. This is sometimes referred to as the “as-is” view. The current view of the EA serves to create a ‘baseline’ inventory of current resources and activities that is documented in a consistent way with the future view of the EA so that analysts can see gaps in performance between future plans and the current capabilities. Having an accurate and comprehensive current view of EA components is an important reference for project planning, asset management, and investment decision-making. The current view of the EA is composed of ‘artifacts’ (documents, diagrams, data, spreadsheets, charts, etc.) at each level of the framework, which are archived in an online EA repository to make them useable by various EA stakeholders.

EA Analysis and Design Element #4: Future Architecture

The future architecture documents those new or modified EA components that are needed by the enterprise to close an existing performance gap or support a new strategic initiative, operational requirement, or technology solution. As is shown in Figure 1-9, the future architecture is driven at both the strategic and tactical levels in three ways: new directions and goals; changing business priorities; and emerging technologies. The EA cannot reflect these changes in the future architecture unless the enterprise’s leadership team provides the changes in strategic direction and goals; unless the line of business managers and program managers provide the changes in business processes and priorities that are needed to accomplish the new goals; and unless the support/delivery staff identifies viable technology and staffing solutions to meet the new business requirements.

fig1-9
Figure 1-9: Drivers of Architectural Change

The future architecture should cover planned changes to EA components in the near term (tactical changes in the next 1-2 years), as well as changes to EA components that are a result of the implementation of long-term operating scenarios that look 3-10 years into the future. These scenarios incorporate different internal and external drivers and can help to identify needed changes in processes, resources, or technology that translate to future planning assumptions, which in turn drive the planning for new EA components.

Enterprise Roadmapping

– a methodology that enables enterprise planners – enterprise architects, organization and program managers, strategic planners, capital planners, and other planners – to work with sponsors and stakeholders to design an enterprise roadmap that defines needs of the enterprise, what can and will be done to address those needs, and what and when benefits will be achieved, and how those benefits will be measured. 

EA Analysis and Design Element #5: EA Management Plan

The EA Management Plan articulates the EA program and documentation approach. The EA Management Plan also provides descriptions of current and future views of the architecture, and a sequencing plan for managing the transition to the future business/technology operating environment. The EA Management Plan is a living document that is essential to realizing the benefits of the EA as a management program. How the enterprise is going to continually move from the current architecture to the future architecture is a significant planning and management challenge, especially if IT resources supporting key business functions are being replaced or upgraded.

EA Analysis and Design Element #6: Threads

In the FEAF-II Framework, security is treated as a sixth sub-architecture domain that pervades all of the other five areas of the EA framework because security and privacy controls, to be most effective, need to be “built into” service workflows, data flows, systems, applications, and host networks. FEAF-II uses Governance instead of “Threads” to label the crosscuts, which include:

  • Security and Privacy
  • Capital Planning / Portfolio Management
  • Program and Project Management
  • Competency and Asset Management
  • Standards / Configuration Management

EA documentation includes ‘threads’ of common activity that are present in all levels of the framework. These threads include IT-related security, standards, and skill considerations.

  • Security. Security is most effective when it is an integral part of the EA management program and documentation methodology. A comprehensive IT Security Program has several focal areas including: information, personnel, operations, and facilities. To be effective, IT security must work across all levels of the EA framework and within all of the EA components.
  • Standards. One of the most important functions of EA is that it provides technology-related standards at all levels of the EA framework. EA should draw on accepted international, national, and industry standards in order to promote the use of non-proprietary solutions in EA components. This in turn enhances the integration of EA components, as well as better supporting the switch-out of components when needed.
  • Skills. Perhaps the greatest resource that an enterprise has is people. It is therefore important to ensure that staffing, skill, and training requirements are identified for LOB and support service activities at each level of the EA framework, and appropriate solutions are reflected in the current and future architectures.

Reference Architecture and Segment Architecture

A reference architecture is the part of an EA that provides standards and documentation for a particular type of capability throughout the enterprise – such as mobile services or cloud computing. A segment architecture is somewhat similar, but usually focuses one or more particular business units or functions – such as the finance and accounting group, or how an ERP system and all of its modules are going to be implemented (general ledger, accounts payable, accounts receivable, payroll, benefits, etc.).

Fitting the Architecture Elements Together

While the basic elements of EA analysis and design provide holistic and detailed descriptions of the current and future architecture in all areas of the underlying framework, it is important to also be able to articulate these relationships in discussions and presentations with executives, managers, support staff, and other EA stakeholders. Being able to understand and relate how the architecture fits together is essential to being able to use the EA in planning and decision-making throughout the enterprise. This communication is supported through two EA program resources: the EA Management Plan and the EA Repository. As was mentioned in the previous section, the EA Management Plan is a living document that is periodically updated so that it remains relevant as the ongoing primary reference for describing where the current and future architectures are at. The EA Repository is the on-line archive for EA information and the documentation artifacts that are described in the EA Management Plan.

The following is an example of how to communicate about EA with stakeholders. In this example, some questions are presented about how to apply an EA framework to an enterprise. These are the types of questions that should be answered in the first few sessions of EA program meetings in order to promote an understanding of how the EA framework and documentation can reflect the enterprise. In the following example (see as check-list) of how to talk about EA, the five levels and three vertical threads of the EA3 Cube framework are used for illustration. Notice how the questions build in a way that reflects the hierarchical relationships between the levels of the EA Framework.

Each area of the EA Framework represents a functional area of the enterprise. The EA3 Framework can be used in a top-down, bottom-up, or single-component manner. To begin to use the framework in a top down-manner, a series of questions at each level should be asked in order to determine how information about the enterprise will fit within that level of the framework.

The first questions to ask relate to the strategic ’Goals and Initiatives’ level of the framework. The questions are: (1) for what purpose does the enterprise generally exist (usually expressed in the mission statement) and (2) what kind of organization does the enterprise generally intend to be (often given in the vision statement)? What are the primary goals (strategic goals) of the enterprise? What then are the strategic initiatives (ongoing programs or new projects) that will enable the enterprise to achieve those goals? Finally, for this level, when will the enterprise know that it has successfully reached these strategic goals or is making progress toward these goals (outcome measures)?

Second is the business ‘Products and Services’ level of the framework, and it is important to first ask what are the ongoing activity areas (lines of business) that the enterprise must engage in to support and enable the accomplishment of both strategic initiatives and normal ‘maintenance/housekeeping’ functions? What then are the specific activities in each line of business (business services)? What are the products that are delivered in each line of business? How do we measure the effectiveness and efficiency of the line of business processes (input/output measures) as well as their contribution to strategic goals (outcome measures)? Do any of these business services or manufacturing processes need to be reengineered/improved before they are made to be part of the future architecture? What are the workforce, standards, and security issues at this framework level?

Third is the ‘Data and Information’ level of the framework. When the lines of business and specific business service/products have been identified, it is important to ask what are the flows of information that will be required within and between activity areas in order to make them successful? How can these flows of information be harmonized, standardized, and protected to promote sharing that is efficient, accurate, and secure? How will the data underlying the information flows be formatted, generated, shared, and stored? How will the data become useable information and knowledge?

Fourth is the ‘Systems and Applications’ level of the framework and it is important to ask which IT and other business systems and applications will be needed to generate, share, and store the data, information, and knowledge that the business services need? How can multiple types of IT systems, services, applications, databases, and web sites be made to work together where needed? How can configuration management help to create a cost-effective and operationally efficient ‘Common Operating Environment’ for systems and applications? What are the workforce, standards, and security issues at this level?

Fifth is the ‘Network and Infrastructure’ level of the framework and it is important to ask what types of voice, data, and video networks or computing clouds will be required to host the IT systems/applications and to transport associated data, images, and conversations, as well as what type of infrastructure is needed to support the networks (e.g. buildings, server rooms, other equipment). How can these networks be integrated to create a cost-effective and operationally efficient hosting and transport environment? Will these networks and clouds extend beyond the enterprise? What are the workforce, standards, and security issues at this level? What are the physical space and utility support requirements for these infrastructure resources?

The EA Repository

Providing easy access to EA documentation is essential for use in planning and decision-making. This can be accomplished through the establishment of an EA repository to archive the documentation of EA components in the various areas of the EA framework. The EA repository is essentially a complex database that stores enterprise information, and exposes it via a website or other relevant channels such as tablets.

Using a holistic approach to Enterprise Architecture as a strategic initiative has become increasingly more popular among QualiWare users. The QualiWare toolset is being used for building and maintaining the Enterprise Architecture repository including all aspects of the enterprise such as strategy models, process architecture, application architecture, information architecture, organization architecture and infrastructure architecture. In security architecture and risk management the tool and repository covers features such as Risk Heatmaps to show the risk profile for a business area, and Control Coverage Maps to show the combination of the residual risk with the level of investment required to achieve that risk level. Due to the strategic nature of the EA work the results are often materialized in new initiatives and business transformation projects.

A typical scenario for mid-size to large size enterprise using QualiWare for EA or business transformation projects starts with a decision on the modeling standard (metamodel) to be used. Then the project model is decided and the tool is automatically configured to support this setup. When the analysts and designers have started building and approving models these models are published to the web by the QualiWare publishing server and the relevant employees or projects stakeholders are able to browse the published models, and also provide feedback or updates to content and relationships from their web browser.

Summary of Concepts

A program or systems-level perspective is not sufficient for the management and planning of technology and other resources across enterprises with significant size and complexity. EA is the one discipline that looks at systems holistically as well as provides a strategy and business context. EA was described as being as both a management process and an analysis and design method that helps enterprises with business and technology planning, resource management, and decisionmaking. The purposes of an EA management program were described: strategic alignment, standardized policy, decision support, and resource development. The six basic elements of an EA analysis and design method were presented: the EA documentation framework, EA components, current EA views, future EA views, an EA Management Plan and multilevel threads that include security, standards, and workforce planning. An example of how to communicate the various areas of an EA framework was also provided.

The Changing Role of the Enterprise Architect

ieeePaper 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).