Enterprise Architecture Governance: A Holistic View

Introduction

Governance is the way in which an organization is run and controlled [1]. Governance is the way rules, norms, and actions are structured, sustained, regulated, and held accountable [2].

Generally, governance is categorized into three types based on the nature of the organization, type of outcomes desired, and practical agenda of the organization [3-12].

• The level of governance is associated with a type of organization. It covers Public Governance, Global Governance, Non-profit Governance, Corporate Governance, and Project Governance.
• The field of governance is associated with a type of activity or outcome. This addresses Environmental Governance, Internet Governance, Enterprise Architecture Governance, and Information Technology Governance.
• The model of governance is derived as an experimental approach. This includes Regulatory Governance, Participatory Governance, Multilevel Governance, Meta Governance, and Collaborative Governance.

However, the strategy of an organization is to drive the Corporate Governance, IT Governance, and Enterprise Architecture Governance of the organization.

Strategy is the direction an enterprise chooses to reach its goals.  Goals are a description of a desired future condition, and strategy is an intention of actions to realize the goals [13]. Strategy for an organization is classified into two categories: Business Strategy and IT Strategy.

Business strategy is the means by which it sets out to achieve its desired ends (objectives). It describes the long-term business planning of an organization. Typically, a business strategy will cover a period of about 3-5 years [14].

IT Strategy is the plan consisting of different projects for deploying Information Technology within an enterprise [15]. A long-term view, mostly described as a high-level framework, on where an organization wants to be IT-wise in 3-5 years [16]. It is an iterative process to align IT capability with long-term business requirements.

Corporate Governance consists of a set of processes, customs, policies, laws, and institutions affecting the way people directly administer or control an organization [17]. It also includes the relationships between the many players involved (the stakeholders) and the organization's goals. Niemann [18] states that information is the key to the success of the Corporate Governance program, and therefore the use of IT and information systems is essential.

IT governance is the organizational capacity to control the formulation, valuation, and implementation of IT strategy, tightly aligned with business strategy, and a guide to proper direction for achieving the business goals of the enterprise [19, 20].  IT governance primarily deals with connections between business focus and IT management. The goal of clear governance is to assure the investment in IT generates business value and mitigates the risks that are associated with IT projects [21]. IT governance is a combination of processes, practices, rules, and relationships.

Enterprise Architecture Governance (EAG) is the exercise of economic, political, and administrative authority to manage the development and implementation of the EA Initiative. It is the organizational structure and set of processes by which an organization controls the IT solutions it deploys to ensure they are consistent with the enterprise architecture vision, principles, and standards.

The diagram below shows the relations between the concepts of governance across organizations. Corporate Governance and IT Strategy are usually developed from the Business strategy. Corporate Governance and IT Strategy is developed based on IT Governance.

Enterprise Architecture and EA Governance were covered in the Business strategy or the IT Strategy (or both).  It is important to be aware that every element in the hierarchy can affect the development of the future state of other concepts [22]. The figure below depicts the types of Governance and their relationship with the Strategy.

EA Governance comprises the enterprise structure and a set of policies, processes, and procedures, by which enterprise can control the IT solutions it, deploys to ensure that they are consistent with the enterprise architecture vision, principles, and standards.

EA Governance is the responsibility of not only the IT executives (CIO and IT Directors) but also executives from the business organization as well, along with critical participation from Enterprise Architects, Domain Architects, Subject Matter Experts, and other support staff throughout the enterprise. Successful enterprise designing is not simply a function of the IT organization, it needs total enterprise participation.

Lack of or improper EA Governance leads to ineffective EA thereby resulting in not reaping the benefits of EA. Without a proper EA Governance, an organization cannot maintain proper alignment of business and IT. This will also result in non-standard technology/product selection/purchasing, inconsistencies in architectures that lead to monolithic implementations ("built-in silos") which are very hard to integrate with internal and external systems. In the absence of a proper EA Governance model/process, EA data becomes stale or obsolete and hence becomes useless or less useful, impairing strategic decision-making based on this outdated data, thereby defeating the very purpose of EA.

The objective of this article is to describe the deep aspects of EA Governance, definition, drivers, principles, and best practices.

The Need For EA Governance

EA is an ongoing activity where governance is a process, which helps in managing and maintaining the architecture of the organization. It is not an isolated discipline but an integral part of an enterprise to look after business and IT alignment.

EA Governance is required to ensure that maximum benefits of EA are reaped by an Enterprise.  It is not an isolated discipline, but it is an integral part of an Enterprise. EA Governance ensures that all the elements in the Enterprise (people, departments, new IT systems, applications) adapt and rigorously follow the Enterprise Strategies, Objectives, and EA models extended by IT.

In addition, a proper EA Governance model is very essential since EA is a continuous activity and not a one-time activity. Only with a proper EA Governance model, an Enterprise can keep its EA data refreshed with every new business and IT initiative and with changes to existing business and IT environments. This results in properly synchronizing or aligning IT initiatives and architectures with business initiatives, establishing standards in IT architectures, purchasing, and enabling data-driven strategic decision-making.

Without adequate governance, Enterprise Architecture will remain a theoretical concept that will fail to deliver the desired business benefits. Architecture governance needs to be supported by an Architecture Governance Framework and it is intended to assist in identifying effective processes and Enterprise structures, so that the business responsibilities associated with architecture governance can be elucidated, communicated, and managed effectively.

Effective Governance provides the following benefits at the Enterprise Level:

• Reduced IT solution delivery time.
• Sustained improvement in time to market.
• Improved integration between systems.
• More effective linkage with external systems.
• Reduction of unnecessary complexity.
• Better leverage of legacy systems.
• Direction and guidance for future investments.
• Business-driven introduction of new technology.
• Improved alignment of IT with the business.
• Improved vendor leverage and interface efficiency.
• Rapid change enabled organization — prepare the organization for rapid, unplanned change.

Enterprise Architecture Governance

The Objectives of the EA Governance are to:

1. Ensure enterprise is adopted and complied with.
2. Guide the decision-making process in order to maintain architectural coherence.
3.  Enable architecture assurance for all key stakeholders.
4. Maintain the relevancy of the enterprise to meet changing requirements.

Designing and planning any new development should relate to its context, which is a series of processes, cultural orientation, and a set of owned responsibilities. It is, therefore, important to understand the context of EA governance in the wider scheme of things surrounding EA initiatives of the enterprise any attempt to form a governance strategy taken. The figure below depicts the overview of the EA Governance. 

The split of process, content, and context are the keys to the support of the EA Governance initiative, by allowing the introduction of new governance material (reference architecture, standards, etc.) without unduly influencing the processes. This content-agnostic approach ensures that the framework is flexible.

The processes are typically independent of content and implement a proven best practice approach for active governance.

Guiding Principles of EA Governance

The EA Governance Guiding Principles are:

• IT processes and systems will conform to the Enterprise Architecture.
• Enterprise architectures must reflect enterprise strategic plans.
• Technologies will be leveraged in order to enable and support business.
• All technology adoptions and retirements must follow the evaluation process defined in the IT Architecture and must consider operational aspects and lifecycle management.
• Every element of the IT Architecture will have an identified owner.
• Elements of the IT Architecture will be designed, implemented, and tuned to meet the service requirements of each application system they support.
• Elements of the IT Architecture will be designed and implemented to meet the business continuity requirements of each business system they support.
• All Enterprise assets and information entrusted to IT will be secured in accordance with business objectives.
• Enterprise Architecture will enable solutions, services, processes, and support that are consistent across all business units.
• The architecture will build in the capability of scaling up or down IT resource requirements in response to changes with minimal impact on IT total costs.
• IT decision processes will balance the IT risk vs. business reward to achieve business objectives.
• Technology selection when implementing a solution will include an assessment of build, buy or reuse of available packages and development options.
• Information Technology will assess and plan for obsolescence, including retirement planning, when selecting solutions to meet business requirements.
• Approved standards will conform to industry standards unless they conflict with specific business objectives.
• Architectures must be appropriately scoped, planned, and defined based on the intended use of the architecture.
• Architectures facilitate change. Architectures continuously change and require transitions.
• IT services will be provisioned and made accessible to the enterprise.
• Architectures must allow many disparate hardware and software systems to connect and integrate with each other, and exchange data as needed to perform the desired business transactions.
• Enterprise Architecture will drive enterprise technology service provisioning through focus groups of technology domain expertise.
• A framework is needed to model and apply enterprise architecture disciplines.
• Enterprise Architecture will need to continue refreshing and updating the framework as well as the taxonomy and to mature the enterprise architecture model.
• Corporate IT must provide policy guidance, advice, and assistance in the definition, design, and implementation of Enterprise Architecture discipline and practice throughout the enterprise.
• The solution architecture development process must be monitored, reviewed, and validated to minimize risks and optimize results.
• IT values must be mapped out and managed in order to understand and control the IT total cost of ownership.

EA Governance Framework

A sound governance framework to support implementation and management of the enterprise architecture is necessary to ensure that Enterprise achieves its EA objectives.

The following characteristics highlight the considerations for developing Governance as an approach to adopt within the EA initiative:

1. Discipline: All involved parties will have a commitment to adhere to procedures, processes, and authority structures established.
2. Transparency: All actions implemented and their decision support will be available for inspection by authorized organizations and provider parties.
3. Independence: All processes, decision-making, and mechanisms used are established to minimize or avoid potential conflicts of interest.
4. Accountability: Identifiable groups within the organization — e.g., governance boards who take actions or make decisions — are authorized and accountable for their actions.
5. Responsibility: Each contracted party is required to act responsibly to the organization and its stakeholders.
6. Fairness: All decisions taken, processes used, and their implementation shall not be allowed, to create an unfair advantage to any one particular party.

Embodying these characteristics, EA Governance will not be an isolated discipline; rather it will operate within the hierarchy of other governance structures existing within an enterprise.

The EA Governance Framework comprises the following elements required in maintaining enterprise architecture:

• EA Governance Organization Structure
• EA Review Board
• EA Governance Processes
• EA Taxonomy
• EA Repository
• EA Metrics

EA Organization Structure

The Enterprise Architecture organization helps to develop and enable the adoption of design, review, execution, and governance capabilities around Enterprise Architecture (EA). These capabilities comprise a number of key elements, including:

• EA Frameworks. A set of standards, procedures, and operating protocols that guide and direct the decisions around the adoption, reuse, reporting, and retirement of information technology at Enterprise. These include guiding principles, methods, procedures, metrics, best practices, and reference models.
• EA Governance. A cross-organizational, multi-disciplinary Architecture Review Board (ARB) with the backing of Enterprise IT executive management to oversee the implementation of the technology governance strategy and framework definition.
• EA Compliance. Definition of an EA Compliance strategy and institution of a set of consistent, repeatable processes to ensure this EA compliance strategy. Establishment of the correct organizational responsibilities and structures to support the architecture governance processes and reporting requirements.

EA guidance and governance over the Enterprise IT solutions delivery processes focused on realizing a number of solutions characteristics.   These include:

• Standardization: Development and promotion of enterprise-wide IT standards.
• Consistency: Enable required levels of information, process and applications integration, and interoperability.
• Reuse: Strategies and enabling capabilities that enable reuse and advantage of IT assets at the design, implementation, and portfolio levels.  This could include both process/governance and asset repository considerations.
• Quality: Delivering solutions that meet business functional and technical requirements, with a lifecycle management process that ensures solutions quality.
• Cost-effectiveness and efficiency:  Enabling consistent advantage of standards, reuse, and quality through repeatable decision governance processes enabling reduced levels of total solutions lifecycle cost, and enabling better realization on IT investments.

The EA group is responsible for overall architecture planning and oversight, including the review of technology plans, establishing standards and guidelines, providing directional input into the enterprise-wide technology plan, and reviewing technology acquisitions.   Generally, the EA Chief Architect reports to the CIO, and the EA group provides guidance to the IT Leadership.

The following diagram depicts the high-level organization model required to achieve business-IT alignment for an enterprise.

Enterprise IT Leadership Council: It comprises executive management including CIO and business executives and would define the enterprise strategic elements and coordinate with the program management office and EARB to translate these elements to procedural elements.  The following are the responsibilities of the Enterprise IT Leadership Council:

• Managing the enterprise business portfolio along with CIO
• Formulating enterprise business strategies along with CIO
• Setting enterprise strategic directions and priorities on how IT will be used to enable the business
• Collaborating with EA workgroup to apply due diligence across the project portfolio
• Collaborating with EA Competency Center to develop common enterprise-wide technology visions and requirements

EA Workgroup: It creates the dynamic elements (Business model, Application architecture, data architecture, infrastructure, etc.) of EA, proposes the broad governance process, EA lifecycle processes, and establishes the formal engagement models with other groups such as EA competency center, technology office, etc.

EA Review Board: The core EA Review Board comprises different architects. The primary responsibility of this body is to participate in key activities like architectural reviews, project prioritization and approvals, RFP/Vendor evaluation, and process reviews. This body should also ensure compliance with defined standards and processes. The following section explains the details of the EA Review Board and its roles and responsibilities.

EA Competency Center: The EA Competency Center will keep a close watch on new technology evolution in the marketplace and determine the business value that is generated from them for the enterprise. It helps develop tools, processes, and migration methodologies that help move the old systems onto new technologies and platforms. Based on the business value that a particular technology brings, the technology office can suggest the IT Leadership council to start new competency centers.

There are a number of applicable governance structural models in a typical IT decision framework.   These range from highly centralized to highly de-centralized frameworks.  Enterprises typically employ a variety of them, using different approaches for these varying decision frameworks. The following section explains the concepts of Centralized, decentralized, and federated architecture models.

Centralized Architecture

 The central architecture governance team is a central authority and is responsible for defining frameworks and guidelines to be used across the enterprise.

This governance model defines all the reference architectures, definitions, standards, and development standards of IT architecture to be used across the organization. All the business units are supposed to follow these standards

The following diagram shows the Centralized Architecture Governance Model,

A centralized model is economical from both a skill and an overhead standpoint but does little to build client/customer relationships, foster business knowledge in IT staff, or further align IT with business needs since customizing the architecture solution to fit specific business requirements can be difficult.

De-Centralized Architecture

The de-centralized architecture model is the most distributed model of the Enterprise choices. In the decentralized model, solutions architecture is aligned with the specific line of business (may be vertical or horizontal domains) and BU-specific architects report into the business line. This facilitates a coordinated model between the IT management governance office (PMO) and executive councils.

The decentralized approach gives business lines the most control over IT architecture and closely aligns IT service delivery with business needs.  The key challenge faced with a de-centralized architecture model is that it becomes difficult to enforce architecture consistency across the business domain units, resulting in a fragmented and potentially inconsistent IT asset portfolio, with challenges in achieving enterprise-wide process, information, and application integration and inter-solution connectivity and inter-operability.  In addition, there is a number of potential redundancies and sub-optimization of IT competencies, with limited cross-domain advantage.

The following diagram shows the De-centralized Architecture Governance Model:

Federated Architecture

In the federated model, an enterprise IT architecture unit such as the CIO/CTO office has primary responsibility for architecture, common infrastructure and services, and standards and frameworks that are common across the enterprise.  Each business/domain area has primary responsibility for domain-specific standards, including any application-specific resource decisions.  Business domain and applications IT designs report into the business domain management, with a virtual (dotted-line) relationship to the central IT architecture organization.

The following diagram shows the Federated Architecture Governance Model,

The Federated model maintains a good balance between enterprise-wide standards and frameworks, localized business-area-driven innovation.  In addition, it is quite effective at aligning IT with the needs of the business.

Enterprise Architecture Review Board (EARB)

The EARB is an existing structure of an Enterprise, which is generally chaired by the CIO of an organization.

Enterprise' Architecture Review Board addresses current and future initiatives that could affect the overall Information Management architecture.  Based on the expected business outcome, a review of these initiatives was done.  The CIO of the Organization generally heads this board. The board meets on a regularly scheduled basis.

The Enterprise Architecture Review Board is typically responsible, accountable for achieving some or all of the following goals,

• Establish, manage and own the content of Enterprise Architecture
• Consistency between sub-architectures
• Flexibility of enterprise architecture

• To meet changing business needs
• To leverage new technologies

• Enforcement of Architecture Compliance
• Improving the maturity level of architecture discipline within the organization
• Ensuring that the discipline of architecture-based development is adopted
• Providing the basis for all decision-making with regard to changes to the architectures
• Supporting a visible escalation capability for out-of-bounds decisions
• Identifying re-usable components

The Operational responsibilities of the Architecture Board are, 

• Meeting on a regular basis
• Ensuring the effective and consistent management and implementation of the architectures
• Resolving ambiguities, issues, or conflicts that have been escalated
• Providing advice, guidance, and information to the implementation teams
• Ensuring compliance with the architectures, and granting dispensations that are in keeping with the technology strategy and objectives
• Ensuring that all information relevant to the implementation of the Architecture Contract is published under controlled conditions and made available to authorized parties
• Validation of reported service levels, cost savings, etc

The Governance responsibilities are, 

• Providing a mechanism for the formal acceptance and approval of architecture through consensus and authorized publication
• Providing a control mechanism for ensuring the effective implementation of the architecture
• Establishing and maintaining the link between the implementation of the architecture, the architectural strategy and objectives embodied in the enterprise architecture, and the strategic objectives of the business
• Identifying divergence from the architecture and planning activities for realignment through dispensations or policy updates

Structure of EARB and its Associated Environment

The Enterprise Architecture Review Board supports the EA Organization in IT strategy implementation through various activities such as:

• Definition of EA framework and dynamic elements of EA
• Defining and continuous improvement of architecture management processes
• Define criterion for architecture acceptance of projects
• Review architectural changes, processing deviations, etc.
• Review EA metrics and EA conformance reports
• Ensure architectural components align with business
• Promote reuse across the enterprise through IT project architecture reviews

The following diagram represents the high-level structure of the ARB and its associated environment:

As shown above, the EA Workgroup is expected to work closely with the IT Project Teams, IT PMO, and IT leadership. The IT leadership provides the strategic direction for the IT function in line with enterprise business goals and objectives. The EA Workgroup and the EARB would be responsible for ensuring that all IT projects are in accordance with the strategic direction. They would work closely with the project teams to provide governance and ensure compliance to standards and principles while selecting, prioritizing, and executing projects. One of the key activities of the EA Workgroup would be to provide architecture consulting and reviews to the project teams. The EA Workgroup would work closely with the IT PMO to provide best practice advice and project governance. IT Leadership Council reviews the decisions of the EARB. The council also provides feedback and approves the decisions.

The CIO shall be the ultimate authority on the decisions and will have the right to review/modify decisions finally.

The following table depicts the high-level responsibilities of different members of EARB.

Role of Enterprise Architect

The following table details the different roles that are performed by an Enterprise Architect, depending on the requirements,

RACI Matrix for EA Roles

The following table depicts the roles and responsibilities at the service group and function level in RACI format with respect to all the service areas and associated functions performed by the EA organization.

Note: R- Responsible, A-Accountable, C- Consulted, I- Informed

EA Governance Processes

The Enterprise EA Governance Framework manages all content relevant both to the architecture itself and to architecture governance processes.

The architecture lifecycle processes are integral elements of the overall EA governance framework used to implement technology solutions within Enterprise. Listed below are the five primary processes:

• Architecture Documentation Process
• Architecture Review Process
• Architecture Communication Process
• Architecture Compliance Process
• Architecture Framework Vitality Process

Architecture Documentation Process

The EA framework articulates the organization's business and technology architecture, providing classifications for products and compliances as emerging, current, twilight, and sunset. This documentation process provides a wealth of information to Enterprise in determining technology solutions. Enterprise and domain architects are responsible for the development and validation of enterprise architecture and ensuring that it stays current at all times. They are part of the EA workgroup and may leverage subject matter experts' input.

The architecture documentation process describes the systematic process for developing and maintaining the EA framework.

The architecture documentation process provides the steps necessary for creating the initial technical architecture framework and is triggered from other architecture lifecycle processes including:

• Architecture Framework Vitality Process
• Help request generated during the Architecture Compliance Process
• Documenting the results from the Architecture Review Process

Architecture Review Process

IT project review is one of the core functions or services offered by EARB to help achieve the following objectives,

• Enterprise-level IT guiding principles are followed – EA compliance
• Ensure consistency with enterprise IT eco-system
• Promote effective reuse though out the enterprise
• Ensure required maneuverability within the proposed architecture
• Ensure all the architecture decisions are taken with valid reasons
• Protect IT investment by reducing the risk of project failures
• Measure and monitor residual risk
• Continuously update and communicate the dynamic elements of EA

The following steps describe the criteria to be adopted for the review of the projects across the enterprise by EARB,

• Enterprise-wide transformation projects
• Projects that are likely to deviate from the EA Roadmap and guidelines
• Project whose scope is not restricted to single departments
• Projects that are mission-critical
• Projects that are business-critical

Architecture Communication Process

The architecture communication process ensures the EA framework contents are communicated in a timely and accurate manner. Without a thorough communication process, the enterprise architecture is simply a document, providing no real substance to Enterprise.

All users must have access to the latest version of the enterprise architecture documents and blueprints. A mechanism must exist to communicate the status and updated documentation to all users. Adequate communication of the enterprise architecture plays a vital role in ensuring that enterprise activities are synchronized with the EA framework and the Enterprise strategic plans.

Any time the enterprise architecture makes a noticeable change due to an architecture review, architecture vitality, or architecture documentation process. Communicate the information to the architecture audience in a timely manner.

The process of communicating the documented enterprise architecture includes one sub-process to help determine, document, and send the architecture communication document.

Architecture communication is a set of communication "documents" that can be disseminated or requested from enterprise architecture information to the various architecture audience members. Some of the communication best queried from the enterprise architecture information itself, while other communication best summarized, with the added ability to query for the details.

Architecture Compliance Process

The architecture compliance process describes the process to request a variance from the product or compliance components approved within Enterprise. Having an established architecture compliance process is an appropriate and tactically sound approach to managing information technology from an enterprise perspective.

Key triggers to architecture compliance process summarized as:

• Project teams have new functionality to address that is not addressed by any in-house tools, technologies, or solution sets.
• Project teams have a new enhancement or a new project whose dollar value exceeds $X.
• Single product solution in the technology area (in which case issues such as interoperability with existing tools and technologies are to be researched).
• Architecture help request on a new/complex technology not currently used in Enterprise.

Review results of the Architecture compliance process shall flow into the process called architecture framework vitality. The compliance process consists of three sub-processes that determine, document, and request architecture variances. These sub-processes include:

• Request Architecture Help
• Determine Technology Options
• Create Architecture Variance Business Case

Architecture Framework Vitality Process

The architecture framework vitality process is the process that ensures the content of the EA framework remains current and accurate. This is a major requirement of the governance processes.

To ensure vitality, the EA framework is reviewed from a perspective of business strategic elements, IT strategic elements, and recommendations for enhancements. Advisors should provide input for the business strategy and the IT strategy.

Any time business strategies or IT strategies make a noticeable shift; an architectural framework review may be required. EA framework reviews should occur every one to two years at a minimum.

The process of routinely reviewing the documented EA framework is made up of one sub-process to help determine, document, and request architecture changes. The process described below follows the format of a process model followed by the process detail.

Following three events cause changes to the EA framework:

• Recommendations from EARB
• Architecture framework element enhancements
• Shifts in Business Strategies provided to the CTO
• Shifts in IT Strategies provided to the CTO

EA Taxonomy

Taxonomy is a collection of defined terminology and a coherent description of the components and the conceptual structure of architecture.

For EA, a logical depiction of the taxonomy elements and their linkages are outlined in the diagram below

In the above diagram, the taxonomy elements are classified into three component areas:

Foundation components: provides a basis to the Supporting and Canonical components, based on industry de facto principles in EA, and the corporate IT environment and culture at the enterprise. The taxonomy structure is governed by EA Governance, which links up with IT Governance.  Guiding Principles are the key element in this area.

Supporting components: based on the Foundation components, and based on industry de facto practices and guiding principles with respect to the enterprise culture and IT environment. Approaches, Best Practices, Methodologies, Metrics, and Protocols are the key elements in this area.

Canonical components: based on industry de facto definitions in reference architectures, IT processes, and architecture standards, and supporting framework components at the enterprise. Processes, Standards, and Blueprints are the key elements in this area.

Specific definitions for key concepts and terms are listed below.

Approach is a way in which a task, activity, or process is executed and in which the performance is measured to meet the criteria covering principles, policies, systems, processes, approaches, and techniques.

Best Practice is a way or method of accomplishing a business function or process that is considered superior to all other known methods.

Blueprints –

• Plan or guide, commonly used in construction, laid out logically and including essential elements to address and follow as building progress
• A blueprint is a plan or design documenting the architecture of an enterprise

Guiding Principles – Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.

Methodologies – A methodology represents a package of practical ideas and proven practices for a given area of activity, such as the planning, design development or management of IT-based systems

Processes – Process is a sequence of operations or events, possibly taking up time, space, expertise or another resource, which produces a specific outcome.

Protocols –

• Rules governing transmitting and receiving of data.
• Follow a standard that specifies the format of data and rules in data communication and network environments.
• Rules of engagement between various roles while performing a function or service.

Standards – A set of criteria (some of which may be mandatory), voluntary guidelines, and best practices. The EA guidelines and standards are,

• Architecture must be appropriately scoped, planned, and defined based on the intended use of the architecture. Development and promotion of enterprise-wide standards
• Enterprise architecture must reflect the Organization's strategic plan
• Architecture continuously changes and requires transition
• Architecture must allow many disparate hardware and software systems to connect and integrate with each other.  They need to exchange data to perform the desired business transactions.
• Enterprise Architecture will need to continue refreshing and updating the framework as well as the taxonomy and to improve the enterprise architecture model.
• Enterprise IT must provide policy guidance, assistance in the definition, design, implementation of Architecture discipline and practice throughout the organization
• Enabling consistent advantage of standards, reuse, and quality through repeatable decision processes enabling reduced solutions cost, and enabling better realization on IT investments.
• Strategies to enable capabilities that reuse and leverage IT assets at the design, implementation, and portfolio levels. This could include process/governance and asset repositories.

EA Metrics

"One cannot manage what one cannot measure". The goal of deriving value out of the Enterprise Architecture initiative would be successfully fulfilled and sustained, only when the value of EA to the organization can be measured effectively and tangibly. For the EA program to be successful, it needs to be monitored periodically and measured with respect to a set of defined EA Metrics.

To ensure that EA is progressing well, and adding value to the organization, there is a need to define metrics for measuring effectiveness of it. However, EA metrics are still an emerging field and there are no defined standards. In addition, current literature does not contain a tool to measure the success of EA implementation.

Why Measure?

Traditionally, Enterprise Architecture has been measured on the immediate benefits that it provides to the organization. Although EA has a significant impact on how the IT organization aligns with Business, if EA metrics are only limited to measuring Business-IT alignment, they would fail to measure the long-term impact of EA and more importantly its impact on business as an enabler and catalyst of change.

Based on our interactions with various customers, the following are the practical challenges that we encountered in measuring the effectiveness of EA:

• Effectiveness of EA is rarely assessed
• No established industry-standard metrics for measuring EA effectiveness
• EA Context significantly differs between the Organizations
• Different stakeholders have different perceptions of EA
• Most EA metrics aim to measure EA value in IT terms; Not in business terms
• Measurement data concerning EA often does not exist within the organization
• Objectives of EA change during the implementation path
• Most employees belonging to the Organization do not know about architecture

EA effectiveness is the degree to which the objectives of EA are being attained by means of EA. EA Metrics not only helps in gauging the long-term impact of EA, but also helps in measuring the true value of EA which will enable the Organization to plan more effectively and efficiently.

Measuring EA metrics is necessary to:

• Determine how effectively and efficiently the process or service satisfies the customer
• Improved ability to seize new business opportunities
• Make decisions based on FACT and DATA
• Improved agility
• Ability to extend systems to meet increasing demand
• Better ability to outsource

Measurement should,

• Translate customer expectations into goals
•  Evaluate the quality of processes
•  Track improvements
• Support enterprise strategies

For the EA program to be successful, it needs to be periodically monitored and measured with respect to a set of defined EA Metrics.  The status of these metrics can be captured, presented and communicated effectively using EA scorecards or dashboards to the EA Governing body.

The most commonly used EA metrics for an Organization are defined in the table below. These are based on author experience.  Again, these vary from domain to domain and customer to customer.

EA Repository

Enterprise architecture tools capture, store, and structure and analyse information pertaining to enterprise architecture and present the information to enterprise stakeholders. These tools provide support for strategic decision-making by capturing vital enterprise context, along with content development and analysis capabilities across the business, information, technology, and solution architectures. —Gartner

EA tools provide support for strategic decision-making by capturing vital enterprise context, along with content development and analysis capabilities across the business, information, technology, and solution architectures.

It helps the stakeholders to analyze and optimize the portfolio of business strategies, organizational structures, business processes/tasks and activities, information flows, applications, and technology infrastructure.

The EA tool coves the following functional features,

• Modeling capabilities
• Framework and Standards support
• Ability to create or import models and artefacts
• Robust and flexible repository and meta model
• Ease of usability
• Integration to multiple enterprise usage tools
• Ability to impact at all levels of the enterprise domains
• Administrative capabilities to meet diverse needs such as security, audit/ control, collaboration, configuration, and versioning

EA Governance Benefits

Significant cost savings are achieved with the right governance model in enterprise, in addition to the following benefits:

1. Brings clarity in roles and responsibilities through management oversight.
2. Facilitates clear and quick decision-making on contentious issues by bringing in transparency and accountability.
3. Preserves architectural coherence by weaving in a compliance culture.
4. Keep architecture relevant and useful in a pragmatic manner.
5. Elevates the role of and accentuates visibility according to architecture within the enterprise
6. Expedites adoption of architecture thinking in the organization
7. Ensures that architecture efforts are expended in the right activities.
8. Sets focus on performance improvement leading to the attainment of best practices.

Future Research Directions

The Ivory Tower approach of EA is slowly vanishing, and Enterprise Architects today are expected to work in Collaborating model and adopt Outcome driven approach.

In a recent research note concerning the future of enterprise architecture into  2022, Gartner predicted that modern enterprise architecture and technology innovation leaders are scaling for their role in the next decade [23]. Enterprise Architects have to scale their role and skills in terms of the following,

• Supporting strategic planning for both the business and IT
• Focusing on digital technologies within the business ecosystem
• Learn and adopt next-generation technologies like Cloud, Microservices, API Management, and DevOps.
• Enhancing integrated business and technology skills to deliver the role in the next decade
• Adopting different tools for analyzing the interrelationships and inter-dependencies of changing plans, in-flight projects, and the state of existing assets over time

In addition, enterprise architects need to involve in technology innovation, agile way of architecture development.

Conclusion

In summary, a well-designed Enterprise Architecture governance structure can be an essential tool in reducing IT cost and risk, and accelerating decision-making and delivery. EA governance ensures that the EA program is properly managed and produces artifacts and plans that are truly representative of organizational goals and needs. It ensures investment decisions are aligned with the EA from initiation to implementation.

Governance is an important part of any change initiative and EA is no exception. Governance provides a platform for various stakeholders to interact regularly and maintain the enterprise architecture. Without adequate governance, Enterprise Architecture will remain a theoretical concept that will fail to deliver the desired business benefits.

In addition, the EA program definition should not span for years. It should deliver business value in a short time. In addition, the program output should be actionable. Always measure impact but not activity.

In modern EA, the Ivory Tower approach of EA Governance will not work. This causes EA programs to fail, especially when the EA program does not consider the demands of digital business, driven by a shift in value creation to ecosystems, platforms, and outside-out architecture.

The role of EA Governance in modern EA is summarized below,

• Do not focus on Current State Architecture
• Continue to advance the EA program to the next level of maturity
• Understand organization's business strategy, business models, and goals, and determine how EA can help deliver business value
• Don't get distracted by EA frameworks, industry reference models, governance, and EA tools
• Shift Emphasis From Top-Down Governance to an EA Center of Excellence
• Adopt a continuous innovation approach to the EA program, refine each cycle
• Don't purchase EA Tool, without understanding the Use cases and Capabilities

Acknowledgment

The author would like to thank Vijayasimha Alilughatta, Raju Alluri of Digital Architecture Group of Wipro Technologies for giving us the required time and support in many ways in bringing this article as part of Digital Enterprise Architecture Practice efforts.

References

1. www.marketing-hub.co.uk
2. https://en.wikipedia.org/wiki/Governance
3. http://www.businessdictionary.com.
4. http://www.investorwords.com.
5. Jacobsen, D.I. and J. Thorsvik, Hvordan Organisasjoner fungerer. Vol. 2. 2002, Bergen: Fagbokforlaget
6. Paras, G., Creating an Effective Conceptual Architecture. META Practice, 2005: p. 7.
7. http://it.toolbox.xom/wiki/index.php/Definition_IT_Strategy.
8. http://www.cioindex.com
9. Niemann, K.D., From Enterprise Architecture to IT Governance. Vol. 1. 2006, Berlin: Friedr Vieweg and Sohn Verlag.
10. Zachman, J.A., You can´t "Cost-Justify" Architecture 2001: p. 9.
11. Weill, P., M. Subramani, and M. Broadbent, Building IT Infrastructure for Strategic Agility. MIT Sloan management review, 2002. 1(44): p. 57-65.
12. Parmo, C.L., Master thesis Interview with Harald Rønneberg. 2009.
13. Jacobsen, D.I. and J. Thorsvik, Hvordan Organisasjoner fungerer. Vol. 2. 2002, Bergen: Fagbokforlaget.
14. https://businesscasestudies.co.uk/business-theory/strategy/business-strategy.html
15. Gottschalk, P., IT Strategi. 2002, Bergen: Fagbokforlaget. 
16. http://it.toolbox.xom/wiki/index.php/Definition_IT_Strategy.
17. Weill, P. and J.W. Ross, IT Governance. 2004, Boston: Harvard business school publishing
18. Niemann, K.D., From Enterprise Architecture to IT Governance. Vol. 1. 2006, Berlin: Friedr Vieweg and Sohn Verlag.
19. The ministry of international trade and industry 1999.
20. Grembergen, W.V., Strategies for Information Technology Governance. 2004, Hershey, PA: Idea Group Publishing
21.  Smallwood, Deb (March 2009). "IT Governance: A Simple Model". Tech Decision CIO Insights
22. Parmo, C.L., Master thesis Interview with Harald Rønneberg. 2009.
23. https://blogs.gartner.com/philip-allega/2018/02/02/future-predictions-for-ea-in-the-next-decade/

Key Terms and Definitions 

Enterprise is an organization supporting a defined business scope and mission. An enterprise is comprised of interdependent resources (people, organizations, and technology) who must coordinate their functions and share information in support of a common mission (or set of related missions).

Enterprise architecture is a strategic information asset base, defines the mission, the information, technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs.

Framework – a structure, usually rigid serving to hold the parts of something together or to support something constructed or sketched over or around it.

Enterprise Architecture Framework — provides an organizing structure for the information contained in and describing an EA. The framework does not contain the EA itself. Many organizations can use the same EA framework, but each EA with its content is organization-specific.

Governance —The governance structure of an enterprise is concerned with the leadership, organizational structures, and processes

Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed, controlled at an enterprise level.  It includes controls, compliance assurance, processes, and practices that ensure management and accountability

Process – a repeatable unit of work with recognizable starting and stopping points, using personnel, materials, tools, and information to create products and/or new information