Lecture_2.pdf for Enterprise Application Achitecture

1
Enterprise Application
(MIT503)
Unit 2: Enterprise Application Architecture
Asst. Prof. Bal Krishna Subedi
Center Department of Computer Science and IT
Tribhuvan University

2
Chapter Outlines:
Concepts of enterprise architecture
Roles and practice of enterprise architecture
Architecture Functions in Organizations
Historical origin and best modern practices
Enterprise Architecture Practice as City
Planning
Enterprise Architecture Artifacts
The CSVLOD Model

3
• What Is Enterprise Architecture?
• 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.

4
• What Is Enterprise Architecture?
• Even though enterprise architecture often covers specific
aspects related directly to business planning (e.g. business
processes, organizational roles or even corresponding
business unit structures), it still generally revolves largely
around IT, offers mostly IT-related views and is
currently associated primarily with IT planning or,
more precisely, with joint business and IT planning.
• For example, enterprise architecture can describe how
specific business processes and roles will be modified
when a new information system is introduced.

5
• The Essence of 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/different
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.
• By enabling effective communication and cooperation between
relevant actors, enterprise architecture helps organizations make
optimal planning decisions taking into account the interests and
concerns of all business and IT stakeholders involved in strategic
decision-making and implementation of IT systems.

6
• To business executives EA documents may
provide the answers to the following essential
questions:
– How does the decision contribute to our long-term
business objectives?
– What financial investments are required to implement the
decision?
– When can the decision be implemented?

7
• To IT executives, EA documents explain the
implications of each planning decision for the
corporate IT strategy.
• For example, to IT executives EA documents may
questions:
– What technologies need to be introduced or reused to
implement the decision?
– What is the impact of the decision on the quality of our IT
landscape?
– What teams and partners should be involved in
implementing the decision?

8
• To business unit managers, EA documents explain the
implications of each planning decision for their local
business processes.
• For example, to business unit managers EA documents may
provide the answers to the following essential questions:
– How does the decision meet our local requirements and needs?
– How does the decision modify our established business
processes?
– How does the decision change the information systems that we
use daily?

9
• To IT project teams, EA documents explain the
implications of each planning decision for the design of
separate IT projects.
• For example, to IT project teams EA documents may
questions:
– What exactly needs to be done to implement the decision?
– What approaches can be used to implement the decision?
– How exactly does the decision modify the structure of our
IT landscape?

10
• Lastly, to third parties, EA documents explain the
implications of each planning decision for the structure of a
specific contract or outsourcing agreement.
• For example, to third parties EA documents may provide
the answers to the following essential questions:
– What essential requirements need to be met to implement the
decision?
– What products or technologies can we offer to implement the
decision?
– How does the existing IT landscape facilitate or stop the
implementation of the decision?

• EA as an Instrument for Communication
11

12
• Specifics of Enterprise Architecture
• Enterprise Architecture Is Different from Traditional Architecture.
• Despite the notion that architecture is usually associated with
buildings and other construction objects, enterprise architecture
has not much in common with traditional architecture.
• Unlike buildings, organizations are dynamic socio-technical
systems that cannot be designed or engineered and then built.
• Instead, organizations can be considered as exceedingly complex,
organic and living entities that gradually evolve or grow over time,
rather than get constructed in a well-planned manner.
• 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 (multifarious) documents
used for information systems planning.

13
• Domains of Enterprise Architecture
• The informational contents of enterprise
architecture, as a set of documents describing an
organization from an integrated business and IT
perspective, cover various organizational aspects
important for business and IT usually called EA
domains.

14
• The informational contents of enterprise architecture typically
encompass the following common EA domains:
– Business domain – the business domain views an organization from
the perspective of its business operations, e.g. capabilities, processes,
tasks, roles, locations, value streams, customer experience, etc.
– Applications domain – the applications domain views an
organization from the perspective of its end-user applications, e.g.
applied programs, corporate systems, online websites, mobile apps,
custom software, vendor products, etc.
– Data domain – the data domain views an organization from the
perspective of its core data, e.g. data entities, their structures and
representation formats, databases, warehouses and storage, master
data sources, big data, etc.

15
• The informational contents of enterprise architecture typically
encompass the following common EA domains:
– Integration domain – the integration domain views an organization
from the perspective of its system integration mechanisms, e.g.
interfaces and connections, interaction protocols, integration buses,
messaging middleware, ETL platforms, etc.
– Infrastructure domain – the infrastructure domain views an
organization from the perspective of its underlying IT infrastructure,
e.g. hardware, servers, data centers, operating systems, system
software, cloud, networks, telephony, etc.
– Security domain – the security domain views an organization from
the perspective of its security mechanisms, e.g. firewalls,
authentication approaches, identity and access management systems,
cryptographic protocols, etc.

16

17
• EA Domains as a Stack
• 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.

18
• Enabling and Supporting EA Domains
• 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.
• For instance, business managers are naturally interested in how
their business processes work, what applications they can use and
what data is available to them. All planning decisions relevant to
business-enabling EA domains and affecting business functionality
are normally agreed with business stakeholders.

19
• Enabling and Supporting EA Domains
• 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.
• For instance, business managers are generally not interested in the
integration, infrastructure and security aspects of their information
systems, as long as these systems are adequately integrated, run on
reliable infrastructure and are reasonably secure.
• Most planning decisions relevant to business-supporting EA
domains usually do not affect any business functionality and might
be not discussed with business stakeholders.

20
• The Stack of EA Domains
• The stack of common EA domains with business-enabling and
business-supporting domains is shown above. Generally, enterprise
architecture can describe any domains considered as important
from the perspective of the relationship between business and IT.

21
• The Practice of Enterprise Architecture
• The practice of enterprise architecture, or simply an EA
practice, also be called enterprise architecture
management (EAM), 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 from CEO to ordinary team
members and modifies most IT-related decision-making
processes.

22
• An EA Practice and Organization
• An EA practice is not a separate standalone activity, but
rather an integral part of the organizational organism.
• An EA practice cannot work in isolation and requires
integration with other organizational processes, most
importantly, with strategic management and project
management.
• Basically, an EA practice “sits” between strategic
management and project management and the role
of an EA practice is to continuously translate abstract
business considerations into the designs of specific IT
solutions implementing these considerations in the most
optimal manner.

23
• An EA Practice and Other Processes
• The strategic management process carried out by business
executives takes relevant information from the external business
environment as an input and produces abstract business
considerations guiding an organization as an output, e.g. goals,
objectives, plans and needs. An EA practice takes these abstract
business considerations as an input and produces specific
implementable designs of IT solutions describing exactly what needs
to be done, how and when to satisfy the business considerations as
an output.
• Finally, the project management process carried out by IT
project teams takes these implementable designs as an input and
produces optimal IT solutions corresponding to these designs as an
output, thereby implementing the abstract business considerations
defined by business executives. Importantly, all these processes are
continuous, carried out simultaneously and imply constant feedback

24
• The Position of an EA Practice
An EA practice provides a connecting link between high-level strategic
business planning and low-level IT systems implementation. By acting as a
mediator between the strategic management and project
management processes in organizations, 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.
Practicing enterprise architecture implies not “architecting” organizations, but
rather discussing their desired evolution.

25
• Enterprise Architecture Artifacts
• 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 are the main “workhorses” of an EA practice enabling
effective decision-making and integrated business and IT planning in
organizations.
• EA artifacts can be very diverse and differ in their informational
contents, general meanings and lifecycles.

26
• Informational Contents of EA 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. (e.g. business and
IT capabilities, overarching conceptual rules and executive-level
considerations) to pretty low-level details (e.g. specific business
activities, concrete IT systems and their components)
– Organizational scopes - From the perspective of their
scopes, coverage of EA artifacts ranges from entire
organizations, lines of business and business functions to narrow
organizational areas, separate change initiatives and even single
IT projects. Typically, EA artifacts covering broader scopes are
less detailed, while EA artifacts covering narrower scopes are
more detailed.

27
• Informational Contents of EA Artifacts
• From the perspective of their informational contents,
various EA artifacts can have different:
– EA domains - business, applications, data, integration,
infrastructure and security domains as well as their
combinations
– EA temporal state - EA artifacts can focus on different
temporal states of an organization, i.e. describe an
organization at different points in time. 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

28
• Physical Perspective of EA Artifacts
• From the perspective of their physical properties, EA artifacts can
use different storage approaches and have different volumes.
• EA artifacts can be stored as ordinary files created in general-
purpose text editors, diagramming tools and spreadsheet software,
depending on their representation formats, most often using the
omnipresent MS Office suite. For example, graphical EA artifacts are
often developed in MS Visio, artifacts in tabular formats are usually
maintained in MS Excel, while textual EA artifacts and artifacts of
mixed formats are most typically created in MS Word.
• EA artifacts can have different volumes. In most cases, the physical
volume of EA artifacts can be roughly measured in their number of
printed pages and the size of these pages. However, when the
architectural information is stored in specialized software
repositories, the notion of volume largely loses its meaning.

29
• Duality of EA Artifacts
• One of the most essential properties of EA artifacts is the duality of
their informational contents.
• 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.
• Their duality allows using EA artifacts as a means of communication
and partnership between different groups of actors involved in
strategic decision-making and implementation of IT systems. Duality
of EA artifacts can be regarded as one of the most fundamental
mechanisms underpinning an EA practice and enabling effective
collaboration between diverse stakeholders.

30
• Duality of EA Artifacts
• Duality of EA artifacts can be explicit or implicit.
• Explicit duality is when different parts of EA artifacts are relevant
to different groups of actors, e.g. some sections of an EA artifact
are intended primarily for business stakeholders, while other
sections of the same artifact are intended primarily for IT
stakeholders.
• Implicit duality is when the same parts of EA artifacts are
interpreted differently by different actors, e.g. the same diagram in
an EA artifact is relevant to both business and IT stakeholders, but
has significantly different implications for each of these parties. In
other words, duality of EA artifacts implies either providing
different information to different actors, or providing the same
information having different meanings for different actors.
• However, explicit and implicit dualities in EA artifacts are often
combined.

31
• Example of a Dual EA Artifact
• This solution overview helps business and IT stakeholders make

32
optimal collective planning decisions regarding the launch of a new IT
initiative.

33
• Two Meanings of EA Artifacts
• 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.

of their general meaning in an EApractice
.
33
Decisions 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 and usually imply
some changes in an organization.
• These EA artifacts are always developed or updated collaboratively by all
relevant stakeholders and represented in format convenient for all.
• Decisions EA artifacts are inherently subjective, speculative and people-
specific in nature. They are based only on the informed opinions of their
contributors about the desirable future course of action and shaped
primarily by the interests of their stakeholders.
• After decisions EA artifacts are created and approved, all stakeholders
should act according to these decisions.
• Since any ideas regarding the desired future always imply collective
decisions, all EA artifacts describing the future state, as well as all stateless
EA artifacts also having specific implications for the future, can
automatically be considered as decisions EA artifacts from the perspective

34
• Facts 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.
• Basically, facts EA artifacts play a supporting role in an EA practice
by providing the information base required for developing decisions
EA artifacts.
• 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.

35
• Decision and Facts EA Artifacts

36
Two Lifecycles of 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.

37
Permanent 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.

38
• Temporary EA Artifacts
• Temporary EA artifacts are short-lived EA artifacts
that often exist for several months or even weeks.
• Temporary EA artifacts are transitory, single-purposed
and disposable.
• Temporary EA artifacts 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.

39
• Permanent and Temporary EA Artifacts

• Examples EA Artifacts
40

41
• Examples EA Artifacts
• All EA artifacts should be produced with
a clear idea regarding their intended
future usage and intent, while the
content, structure, presentation and
complexity of information reflected in EA
artifacts should closely match their
purposes.

42
• The Role of Architects in an EA Practice
• 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
• These qualities allow architects to communicate with various
business and IT stakeholders, understand their concerns and
propose optimal planning decisions satisfying the essential interests
of all parties.
• Even though architects usually come from IT departments and have
IT-centric backgrounds, they do not belong wholly to IT specialists
or to business specialists. Instead, architects are “T-shaped”
professionals in connecting business and IT, i.e. experts in finding
optimal IT strategies and solutions satisfying business strategies and
needs.

43
• General Responsibilities of Architects
• Architects are the chief owners of EA artifacts
and facilitators of the dialog between business
and IT. They play a critical role in organizing,
establishing and running an EA practice. Even
though architects themselves cannot be the
sponsors or ultimate beneficiaries of an EA
practice, they are among the main actors of
most EA-related processes.

44
• Typical responsibilities of architects include:
– Analyzing the external technological environment
– Studying the internal organizational and IT environment
– Communicating with various business and IT stakeholders and
understanding their concerns
– Facilitating the dialog and conversation between different
stakeholder groups
– Acting as intermediaries or “translators” between diverse
stakeholders Finding, proposing and discussing optimal planning
decisions satisfying the concerns of all their stakeholders
– Developing and updating EA artifacts for supporting discussions
and documenting the achieved agreements

45
• Typical responsibilities of architects include:
– Ensuring the execution of the agreed planning decisions
reflected in EA artifacts
– Peer-reviewing and approving EA artifacts developed by other
architects
– Establishing and maintaining a repository of EA artifacts
– Setting up necessary software tools for working with EA artifacts
– Establishing, running and optimizing EA-related processes
– Participating in other special activities that require their
expertise, e.g. vendor contract negotiations and technical due
diligence for mergers and acquisitions

46
• Architects as Developers of EA Artifacts
• 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.

47
• Developing Decisions 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.
• The most critical success factor related to decisions EA artifacts is
the timely involvement and active participation of all relevant
stakeholders in the process of their development.
• Decisions EA artifacts are normally created in a proactive manner.

48
• Developing Decisions EA Artifacts
• For example, to develop principles or a solution design, an
architect may schedule a series of meetings with relevant
stakeholders (business executives and IT project teams
respectively) to discuss their views and concerns, based on
the collected opinions propose the initial versions of EA
artifacts, organize workshops with the stakeholders to
elaborate and complete these artifacts, and then distribute
the final versions of these artifacts to all the stakeholders
for their formal approval and sign-off. After the EA artifacts
are signed-off, all the involved parties are committed to
align their decision-making to the newly established
principles or to implement an IT solution exactly as
described in the developed solution design.

49
• Developing Facts EA Artifacts
• The development or update of facts EA artifacts
typically starts from the need for specific documented
facts.
• 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.

50
• Developing Facts EA Artifacts
• The development or update of facts EA artifacts typically
starts from the need for specific documented facts. As the
first step, architects collect the necessary raw data from all
relevant sources, which may include studying available
documents, asking competent people and extracting data
from the existing IT systems or repositories.
• When sufficient information on the required facts is
collected, architects create new or update existing EA
artifacts to accurately document the uncovered facts with
the necessary level of detail.
• For these artifacts the product is more important than the
process.

• Processes for Developing EA Artifacts
51

• Enterprise Architecture Artifacts, Architects and
Other Actors
• An EA practice includes architects and other
organizational actors communicating via
creating and using EA artifacts. However, the
roles of architects and other actors, as well as
their communication and interaction patterns
in the context of an EA practice, are
significantly different from the perspective of
decisions EA artifacts and facts EA artifacts.
52

• Enterprise Architecture Artifacts, Architects and Other
Actors
53

54
• Architecture Functions in Organizations
• 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.

55
• Architecture Functions and Architects
• All architects employed by an organization typically reside in its
architecture function.
• An architecture function may employ different types of architects
and architecture managers i.e. managers of other architects.
• Different types of architects may focus on different EA domains and
organizational scopes
• Different types of architects usually have different responsibilities
and may focus on different EA domains (e.g. applications, data or
infrastructure) or scopes, ranging from entire organizations to
separate IT solutions.
• For instance, common types of architects often found in
organizations include chief architects, enterprise architects, principal
architects, lead architects, domain architects, platform architects,
program architects, solution architects and some other less popular
denominations. However, the precise meaning of these positions and
titles is very organization-specific and can vary significantly across
different companies.

56
• Architecture Functions and Architects
• An architecture function typically also includes one or
more architecture governance bodies , i.e. special
decision-making committees involving architects and
other relevant business and IT stakeholders.
• These governance bodies are responsible for ensuring
the adequate level of engagement between different
stakeholder groups and fulfilling necessary governance
procedures, which include making collective
architecturally significant planning decisions as well as
reviewing, approving and officially authorizing decisions
EA artifacts.

57
Thank you!!
Reference:
Svyatoslav Kotusev - The Practice of Enterprise Architecture, A
Modern Approach to Business and IT Alignment-SK Publishing
(2021)

Lecture_2.pdf for Enterprise Application Achitecture

More Related Content

Similar to Lecture_2.pdf for Enterprise Application Achitecture (20)

More from Tribhuvan University (14)

Recently uploaded (20)

Lecture_2.pdf for Enterprise Application Achitecture