Skip to main content

What is Enterprise Architecture Practice

Introduction

There are many definitions of Enterprise Architecture (EA) on the market. Different people have different understandings about it. When I presented Enterprise Architecture and Business Innovation & Transformation in an international conference of The Open Group, I asked the audience: how many of you think you know the definition of Enterprise Architecture. There are about 90% of them raised hands. Then I asked: how many of you think you and your colleagues’ share a same understanding of Enterprise Architecture, there are about 40-50% of them raised hands. When I asked: how many of you think you and your managers share a same understanding of Enterprise Architecture, only about 10-20% of people raised hands. Then I asked: how many of you think you and your companies’ executives share a same understanding of Enterprise Architecture, only few people raised hands, about 1-2%.

Generally, companies have some key players in their enterprise architecture practices(EAP), such as CIO, IT VP, EA VP or Director, Chief EA, EA Lead, Enterprise Architect, Application Architect, Information Architect, IT managers, etc. However, each stakeholder may have his/her own EA understanding. That’s one of the root causes why many companies are not able to develop EA practice effectively to realize the strategic values EAP are expected to deliver for business, although these companies’ leaders know that EAP is critical for the overall business performance. To address the common challenge on the EA understanding, a company may utilize an EA understanding framework(shown in as Figure 2.1) to enable the stakeholders to share a same constructive EA understanding across enterprise. The EA Understanding Framework consists of three components: 1) a multi-tier EA definition across IT and business perspectives to align with various stakeholders’ interests; 2) a tangible EA view and 3) a structured EA thinking process.  This constructive EA understanding framework will ensure various EA stakeholders share a same “EA” understanding in their daily practices.

Figure 2.1 Enterprise Architecture Understanding Framework



The following sections will illustrate more about each of the components in the EA Understanding Framework.

Defining Enterprise Architecture Practice (EAP)

Because the stakeholders engaged in enterprise architecture practice are from various business departments, at various levels, and with their own interests and focused areas, there is no single enterprise architecture definition on the market is able to cover all the perspectives for all the EA-related stakeholders yet. Therefore, a multi-tier definition on enterprise architecture should be appropriate to align with the various stakeholders’ interests. The following multi-tier definition of enterprise architecture practice constructively integrated the major definitions of Enterprise Architecture available on the market (refer to Table 2.1).

Table 2.1 Multi-Tier Enterprise Architecture Practice  Definition
Defined BY
Enterprise Architecture (EA) Definition
Perspectives (Tiers)
ANSI/IEEE
Fundamental organization of a system
Technology

Embodied in its components


Relationships to each other and the environment


Principles governing its design and evolution
 IT Operation
TOGAF
(ANSI EA Definition) +
a formal description of a system, or a detailed plan of the system at a component level to guide its implementation
IT Operation
MIT-CISR
The organizing logic for business process and IT infrastructure capabilities reflecting the integration and standardization requirements of the firm's operating model
Organization & Operation
Gartner
Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them.
Organization & Operation
 Anonymous
Practice that allows an organization to build core foundations and capabilities they need, systematically and   holistically across the enterprise, to adapt to emerging business landscape , compete and win in the current market competition, and lead its business and industry to the future.
Business Strategy


As the multi-tier Enterprise Architecture (EA) definition (Table2.1) shows, EA is not just about system architecture in IT, it also covers IT operation, business organization, operation, strategy and the holistic alignments among them. Therefore, Enterprise Architecture Practice is a more appropriate term than Enterprise Architecture.  EAP is an expansion of the traditionally-defined EA (e.g. the ANSI’s EA definition). The multi-tier EAP definition will help various stakeholders in a company to understand each other’s point of view on EA, and to execute strategic Enterprise Architecture Practice systematically and holistically.  

Viewing EA


“Seeing is believing”. To enable a company’s leaders, managers and other stakeholders to quickly “see” what the company’s enterprise architecture practice is really about , an enterprise architecture group may show the diagram (Figure 2.2) to the stakeholders. The diagram illustrates what EAP is in a quick visualized way. It includes the major components and their structure relationships across the business and IT. 

Figure 2.2  Enterprise Architecture Understanding – Viewing EA

As Figure2.2 shows, generally, a strategic enterprise architect practice starts with an enterprise’s mission and vision, which are supported by the business domain architecture and the IT domain architecture. The business domain architecture includes business strategies including financial strategy, product strategy, HR strategy, market strategy, etc., which are supported by appropriate organization and operation models, which will conduct appropriate daily business process to deliver business result. The IT domain architecture includes IT strategies, such as architecture strategy, information strategy, technology strategy, etc. which are supported by information system architecture and portfolio, application system architecture and portfolio and infrastructure system and technology architecture and portfolio, etc. which will be integrated to provide solutions to support the business requirements, which align with  business operation and process.  Fundamentally, to enable the business and IT domain architecture components work together constructively, EAP also define an Enterprise Execution Foundation to support an enterprise to achieve its expected performance through daily execution. The foundation includes the core execution components, which includes: people, process, technology, budget, appropriately defined timeline or road-map, and organized alignments among them. To enable the enterprise to develop its execution foundation effectively, it needs to have solid enterprise architecture execution foundation, which includes core EA organization and operation models, e.g. EA engagement and governance models, key EA skill-sets and tools, core EA strategy and road-map, EA budget and the alignments across these components.

Think EA

The way an enterprise architect thinks to address any challenges in an enterprise is fundamentally different from a domain (e.g. application, database, infrastructure) or solution architect. 
  • A domain architect designs a solution structure to meet business needs from a specific domain perspective.
  • A solution architect designs a system solution structure to meet business needs across various technical domains, e.g. application, information/data, integration and infrastructure perspectives.
  • An enterprise architect designs a business solution structure to meet business needs statically and dynamically from application, information/data, integration, security, technology and infrastructure perspectives as domain or solution architects do, as well as strategy, management, organization, operation, process and people perspectives holistically and systematically. Further, an enterprise architect also ensures a business solution’s components from various perspectives as mentioned earlier to be aligned with each other across the enterprise. An enterprise architect needs ensure that a business solution can be executed effectively across an enterprise, not just within a department, line of business (LOB) or a sub business domain. 

Figure 2.3 below shows the overall perspectives, from which a typical enterprise architect should consider when designing an enterprise business solution architecture. To address a business challenge, an enterprise architect should think of a solution from strategy, organization and people, operation and process, technology, security, integration, alignment and execution perspectives. The technology perspective will include information architecture, application and solution architecture, infrastructure, security and integration. An enterprise architect will also ensure the solution from all the perspectives are aligned with each other appropriately and executable.

Figure 2.3 Enterprise Architecture Understanding – EA Thinking

In addition, an enterprise architect generally needs to think about the scope of an enterprise solution may be implemented. This EA concern is measured by the enterprise “depth” and “breadth” (i.e. width) of an enterprise architecture solution to be applied. The “breath” is measured by the number of business unites, sub-domains, etc. applying the enterprise architecture solution. The “depth” is measured by the level an enterprise architecture solution may be applied, such as, conceptual level, logical design level, physical implementation level, and/or at corporate level, business unit level or project level, etc.

Summary

Enterprise Architecture is a practice with long term impact on an enterprise's core competencies and execution capability. Hence, a more appropriate term for it should be Strategic Enterprise Architecture Practice. To understand it correctly, we may utilize a constructive EA understanding framework illustrated in this article, which includes: defining, viewing and thinking EA.

Comments

Popular posts from this blog

Is Second or Fast Second the Best Strategy for Big Established Companies?

Background   - Second or Fast Second Many large companies prefer to take “second strategy” to get the most of the market value the “first mover” may create without taking the risk the “first mover” may have. They hope to enter the emerging market secondly but utilizing its know-how in the existing industry to become one of the leaders in the new market. Will “second strategy” works? It really depends on whether a large company has the capability and time to execute effectively to enter a new market as a second mover but become one of the leader in the new market quickly. Given the fact that quite some large leading companies taking “second strategy” failed to become a leader in a new market they pursued and some of them even failed to survive, e.g. Blockbuster, Barnes & Noble, Kodak, etc. the “fast second strategy” is proposed as the best strategy for big, established companies contemplating entry into an emerging market (by Constantinos C. Markides and Paul A. Geroski,

How to Address the Debate on “Whether Cloud Saves IT/Business Cost” Practically and Strategically

Context This is a simple question, but it is hard to provide a simple answer. It has been asked by all companies plan to initiate their cloud practices. There are various cloud cost models on the market, including those from AWS, Azure, Gartner , etc. However, none of them can provide a simple answer to the question. The only practical right answer is: depends. It is said that one of large cloud providers hired a PhD in finance from Harvard. All s/he does is to figure out, make and tell a financial case/story for the company’s potential enterprise customers. Debate on “Whether Cloud Saves IT/Business Cost” When I led enterprise cloud practice initiations during consulting engagements with large companies, the debate on "whether cloud will save IT and business cost" was always on the table. Quite often the debate was about comparing “apple” with “orange”. The various stakeholders were never able to achieve an “agreement”. A typical dilemma is: some cloud-promot