Lecture 2: The Concept of Enterprise Architecture

Copyright © 2019 by Svyatoslav Kotusev. All rights reserved.

Svyatoslav Kotusev, PhD

The Concept of Enterprise Architecture

LECTURE 2

The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

Based on the book The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment #2SK

▪ The concept of enterprise architecture

▪ The practice of using enterprise architecture for

improving business and IT alignment

▪ EA artifacts as fundamental components of enterprise

architecture and their essential properties

▪ The role of architects in enterprise architecture practices

▪ The place of architecture functions in organizations

In This Lecture



▪ Enterprise architecture (EA) can be defined as a

collection of special documents (artifacts) describing

various aspects of an organization from an integrated

business and IT perspective intended to bridge the

communication gap between business and IT

stakeholders, facilitate information systems planning and

thereby improve business and IT alignment

▪ Enterprise architecture typically describes business,

applications, data, infrastructure and sometimes other

domains relevant from the perspective of business and

IT, e.g. integration or security

What Is Enterprise Architecture?



▪ Enterprise architecture provides effective instruments

facilitating communication, collaboration and mutual

understanding between different groups of actors

▪ Using EA documents for supporting discussions helps

alleviate communication problems resulting from

disparate knowledge, interests and goals of various

involved actors

▪ Essentially, enterprise architecture can be considered as

a communication medium between diverse business and

IT stakeholders in organizations

The Essence of Enterprise Architecture



▪ To business executives EA documents explain the

implications of planning decisions for the business

strategy

▪ To IT executives EA documents explain the implications

of planning decisions for the IT strategy

▪ To business unit managers EA documents explain the

impact of planning decisions on their business processes

▪ To IT project teams EA documents explain the

implications of planning decisions for specific IT projects

▪ To third parties EA documents explain the implications of

planning decisions for the structure of specific contracts

EA Documents and Organizational Actors



EA as an Instrument for Communication



▪ Enterprise architecture has not much in common with

building architecture

▪ Organizations as dynamic socio-technical systems

cannot be designed or engineered and then built

▪ Organizations are extremely complex, organic and living

entities that gradually evolve over time

▪ Enterprise architecture is a pragmatic set of descriptions

useful for managing the evolution of organizations

▪ The term “enterprise architecture” is purely metaphorical

and is only an umbrella term for multiple diverse

documents used for information systems planning

Specifics of Enterprise Architecture



▪ The informational contents of enterprise architecture

typically encompass the following common EA domains:

• Business domain – covers customers, capabilities, processes,

roles, etc.

• Applications domain – covers programs, systems, custom

software, vendor products, etc.

• Data domain – covers data entities, structures, sources, etc.

• Integration domain – covers interfaces, connections, interaction

protocols, integration platforms, etc.

• Infrastructure domain – covers hardware, servers, operating

systems, networks, etc.

• Security domain – covers firewalls, authentication mechanisms,

identity and access management systems, encryption, etc.

Domains of Enterprise Architecture



▪ The set of common EA domains can be represented as a

multilayered stack of domains, where lower layers

underpin higher layers:

• Applications automate business processes

• Data is used by applications

• Integration mechanisms link all applications and data together

• Infrastructure hosts all applications, databases and integration

platforms

• Security mechanisms permeate all other EA domains

▪ The business domain is non-technical in nature, while all

other EA domains are technical domains directly

related to respective technologies

EA Domains as a Stack



▪ All EA domains can be also separated into business-

enabling domains and business-supporting domains

▪ Business-enabling EA domains occupy the top layers

of the stack and represent functional domains

▪ These domains are relevant to business stakeholders

and define the core business functionality of IT systems

▪ Business-supporting EA domains occupy the bottom

layers of the stack and represent non-functional domains

▪ These domains are irrelevant to business stakeholders

and unrelated to business functionality of IT systems

Enabling and Supporting EA Domains



Generally, enterprise architecture can describe any

domains considered as important from the perspective of

the relationship between business and IT

The Stack of EA Domains



▪ The practice of enterprise architecture, or simply an EA

practice, is an organizational practice of using specific

documents called EA artifacts for improving

communication between business and IT stakeholders,

facilitating information systems planning and improving

business and IT alignment

▪ An EA practice is a multifaceted organizational practice

embracing all EA-related artifacts, people, processes,

software and their interaction

▪ An EA practice penetrates an entire organization,

involves numerous actors and modifies most IT-related

decision-making processes

The Practice of Enterprise Architecture



▪ An EA practice is not a separate standalone activity, but

rather an integral part of the organizational organism

▪ An EA practice requires integration with other

organizational processes, most importantly with strategic

management and project management

▪ The role of an EA practice is to translate abstract

business considerations into the designs of specific IT

solutions implementing these considerations

An EA Practice and Organization



▪ The strategic management process takes relevant

information from the external business environment as

an input and produces abstract business considerations

guiding an organization as an output

▪ An EA practice takes these abstract business

considerations as an input and produces specific

implementable designs of IT solutions as an output

▪ The project management process takes these

implementable designs as an input and produces optimal

IT solutions corresponding to these designs as an output

▪ All these processes are continuous, carried out

simultaneously and imply constant feedback

An EA Practice and Other Processes



As a mediator between strategic management and projects

management, an EA practice enables effective coordination

of plans and activities between all relevant actors involved

in strategic decision-making and implementation of IT

systems resulting in improved business and IT alignment

The Position of an EA Practice



▪ Separate documents constituting enterprise architecture

are typically called as EA artifacts

▪ EA artifacts provide descriptions of an organization from

different perspectives important for the various actors

involved in strategic decision-making and

implementation of IT systems

▪ An EA practice implies using specific sets of EA artifacts

for improving communication between different actors

▪ EA artifacts can be very diverse and differ in their

informational contents, general meanings and lifecycles

Enterprise Architecture Artifacts



▪ From the perspective of their informational contents,

various EA artifacts can have different:

• Representation formats - textual, graphical and tabular formats

or a mix of these formats

• Levels of detail - range in their granularity from very high-level

abstractions to pretty low-level details

• Organizational scopes - range from entire organizations and

lines of business to separate change initiatives and IT projects

• EA domains - business, applications, data, integration,

infrastructure and security domains as well as their combinations

• Temporal states - current state (now), short-term future state (<1

year), mid-term future state (2-3 years), long-term future state (3-

5 years), stateless and their combinations

Informational Contents of EA Artifacts



▪ Duality of EA artifacts implies that the information

provided by these artifacts is relevant to two different

audiences simultaneously, satisfies the information

needs of both these audiences and presented in a

convenient format appealing to both audiences

▪ Duality allows using EA artifacts as a means of

communication between different groups of actors

▪ Explicit duality is when different parts of EA artifacts are

relevant to different groups of actors

▪ Implicit duality is when same parts of EA artifacts are

interpreted differently by different actors

Duality of EA Artifacts



This solution overview helps business and IT stakeholders

make optimal collective planning decisions regarding the

launch of a new IT initiative

Example of a Dual EA Artifact



▪ From the perspective of their general meaning in an EA

practice all EA artifacts can be separated into decisions

EA artifacts and facts EA artifacts

▪ Decisions EA artifacts represent made planning

decisions, i.e. achieved and formalized agreements

between various stakeholders regarding the desired

future course of action

▪ Facts EA artifacts represent documented objective

facts, i.e. reflections of the actual current situation in an

organization as it is

Two Meanings of EA Artifacts



▪ Decisions EA artifacts may represent these decisions:

• How an organization needs to work from the IT perspective

• Where an organization should invest its IT dollars

• How a particular IT solution should be implemented

▪ They always have certain implications for the future

▪ These EA artifacts are always developed or updated

collaboratively by all relevant stakeholders

▪ After decisions EA artifacts are created and approved, all

stakeholders should act according to these decisions

▪ All EA artifacts describing the future, and all stateless EA

artifacts, can be considered as decisions EA artifacts

Decisions EA Artifacts



▪ Facts EA artifacts may document these facts:

• What technologies the organizational IT landscape uses

• What IT assets an organization possesses, runs and maintains

• How the existing IT systems and databases are interconnected

▪ They have no implications for the future

▪ These EA artifacts may be developed or updated solely

by specific actors

▪ After facts EA artifacts are created, they can be used by

any actors as reference materials for planning purposes

▪ All EA artifacts describing only the current state can be

considered as facts EA artifacts

Facts EA Artifacts



Decisions and Facts EA Artifacts



▪ From the perspective of their lifecycles in an EA practice

all EA artifacts can be separated into permanent EA

artifacts and temporary EA artifacts

▪ Permanent EA artifacts are long-lived EA artifacts often

existing for many years

▪ Temporary EA artifacts are short-lived EA artifacts

often existing for several months or even weeks

Two Lifecycles of EA Artifacts



▪ Permanent EA artifacts live and evolve together with an

organization

▪ They are created once and then updated when

necessary according to the ongoing changes in an

organization and its business environment

▪ After being developed these EA artifacts are constantly

used, continuously maintained and occasionally

discarded when become irrelevant

▪ Most EA artifacts covering wider scopes beyond specific

IT initiatives or projects tend to be permanent EA

artifacts

Permanent EA Artifacts



▪ Temporary EA artifacts are transitory, single-purposed

and disposable

▪ They are created at specific moments for particular

purposes, used as intended and then immediately

discarded or archived

▪ Due to their short lifespan, the very need to update or

maintain temporary EA artifacts is usually absent

▪ All EA artifacts covering narrow scopes (e.g. separate IT

initiatives or projects) tend to be temporary

Temporary EA Artifacts



Permanent and Temporary EA Artifacts



Examples of EA Artifacts



▪ The key actors of an EA practice are architects

▪ Architects act as chief IT planners in organizations

▪ Ideal architects are effective communicators, team

players, innovators and systems thinkers knowledgeable

in both business and IT

▪ Architects are “T-shaped” professionals in connecting

business and IT, i.e. specialists in finding optimal IT

strategies and solutions satisfying business strategies

and needs

The Role of Architects in an EA Practice



▪ Communicating with various business and IT

stakeholders and understanding their concerns

▪ Facilitating the dialog and conversation between different

stakeholders

▪ Finding, proposing and discussing optimal planning

decisions satisfying the concerns of stakeholders

▪ Developing and updating EA artifacts for supporting

discussions and documenting the achieved agreements

▪ Establishing and maintaining a repository of EA artifacts

▪ Establishing, running and optimizing EA-related

processes

General Responsibilities of Architects



▪ Architects are the key developers of all EA artifacts

▪ Architects are responsible for involving relevant

stakeholders, collecting necessary data and completing

all other activities required to develop EA artifacts

▪ However, the typical process of developing and updating

EA artifacts differs significantly for decisions EA artifacts

and facts EA artifacts

Architects as Developers of EA Artifacts



▪ The development and update of decisions EA artifacts is

a complex, creative and tricky process

▪ Decisions EA artifacts are always developed

collaboratively by architects and their stakeholders

▪ Essentially, the collaborative development of decisions

EA artifacts is the actual process of IT planning

▪ Even though architects usually act as facilitators or

drivers of their development, fundamentally decisions EA

artifacts are products of a collective teamwork

▪ Decisions EA artifacts are normally created in a

proactive manner

Developing Decisions EA Artifacts



▪ The development and update of facts EA artifacts is a

more simple, routine and straightforward process

▪ Unlike decisions EA artifacts, facts EA artifacts may be

developed by individual architects alone or with only a

minimal involvement of other actors

▪ Facts EA artifacts are often created in a reactive manner

on an as-necessary basis

Developing Facts EA Artifacts



Processes for Developing EA Artifacts



EA Artifacts, Architects and Other Actors



▪ An EA practice is implemented by an architecture

function

▪ An architecture function is a separate organizational

function usually reporting to the CIO and responsible for

an EA practice and for organization-wide IT planning

▪ An architecture function can be considered as a

specialized planning subunit of the IT department

▪ The main purpose of an architecture function is to enable

and support primary activities, e.g. production and sales

Architecture Functions in Organizations



▪ All architects employed by an organization typically

reside in its architecture function

▪ An architecture function may employ different types of

architects and architecture managers

▪ Different types of architects may focus on different EA

domains and organizational scopes

▪ Common denominations of architects include chief

architects, enterprise architects, principal architects,

domain architects and solution architects

▪ An architecture function typically also includes one or

more architecture governance bodies

Architecture Functions and Architects



▪ Enterprise architecture is as a collection of artifacts

describing an organization that help bridge the

communication gap between business and IT

▪ An EA practice is a complex and multifaceted practice of

using EA artifacts for effective collaboration

▪ EA artifacts are special documents providing different

views of an organization important for various actors

▪ EA artifacts represent either made planning decisions, or

documented objective facts, many EA artifacts are dual

▪ Architects are the key actors of an EA practice and chief

developers of EA artifacts

Lecture Summary



▪ The next lecture will discuss the position of enterprise

architecture and an EA practice in the broader

organizational, managerial and historical context

In the Next Lecture



The Full Teaching Pack on Request

The full teaching pack with

19 lectures, tests and other

materials based on the book

The Practice of Enterprise

Architecture: A Modern

Approach to Business and

IT Alignment, which can be

freely used for teaching

purposes, adapted or

translated with references to

the original, is available

on request to the author

(visit http://kotusev.com)

Lecture 2: The Concept of Enterprise Architecture

Documents

Transcript of Lecture 2: The Concept of Enterprise Architecture