CHAPTER 2

Enterprise Application Architecture

 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

* Artifacts are like roadmaps that software developers can use to trace the
entire software development process.
 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 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
EA Documents and Organizational Actors
 To business executives EA documents explain the
implications of planning decisions for the business strategy
• 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?

 To IT executives EA documents explain the implications of

planning decisions for the IT strategy
• 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?
 EA Documents and Organizational Actors
 To business unit managers EA documents explain the impact of
planning decisions on their business processes
• 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?

 To IT project teams EA documents explain the implications of

planning decisions for specific IT projects
• 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?

 To third parties EA documents explain the implications of planning

decisions for the structure of specific contracts
• 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
 Specifics of Enterprise Architecture
 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
 Domains 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.
 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
 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
 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
 The Stack of EA Domains

Generally, enterprise architecture can describe any

domains considered as important from the perspective of
the relationship between business and IT
 The Practice of Enterprise Architecture
 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
 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 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 Other Processes
 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
 The Position of an EA Practice

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 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
 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
 General Responsibilities of Architects
 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
 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
 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
 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
 The Need for Enterprise Architecture
 Enterprise architecture is a natural solution to natural
problems of modern organizations
 The critical interdependence between business and IT
functions requires a disciplined approach to coordinating
business and IT plans
 However, business and IT are disparate areas and
establishing effective communication between them
have always been troublesome
 The emergence of enterprise architecture is a natural
reaction to the desperate need to improve collaboration
between business and IT stakeholders
 Significance of Enterprise Architecture
 Enterprise architecture is here to stay and its importance
seemingly is only going to increase in the future because
of three ongoing trends:
• IT systems are getting more sophisticated, comprehensive and
diverse
• The dependence of business on IT is constantly increasing
• The innovative potential of IT for business is growing
 Enterprise architecture seemingly represents one of the
most significant and widely applicable management
innovations of the last two decades
Direct Benefits of Enterprise Architecture
 Direct benefits resulting from the proper usage of
particular types of EA artifacts include:
• Improved effectiveness of IT investments
• Improved efficiency of IT investments
• Reduced costs of IT operations
• Reduced technical and compliance risks
• Reduced complexity of the IT landscape
• Increased reuse of available IT assets
• Reduced numbers of duplicated and legacy systems
• Increased agility of IT planning
• Improved speed and quality of the project delivery
• Improved overall conceptual consistency
Indirect Benefits of Enterprise Architecture
 The direct benefits of utilizing certain types of EA
artifacts eventually help organizations achieve overall
business and IT alignment
 The improved business and IT alignment leads to
numerous indirect organizational benefits including:
• Better operational excellence, customer intimacy and product
leadership
• Increased speed to enter new markets and overall organizational
agility
• Improved managerial satisfaction
Link Between Direct and Indirect Benefits

The use of enterprise architecture leads to a number of

direct benefits, which in turn lead to a number of indirect
benefits for organizations
 The Value of Enterprise Architecture
 An architecture function is a supporting function and its
business value cannot be easily calculated or measured
 Like an HRM function, an architecture function adds no
direct business value to the organizational value chain
 Since an EA practice is a continuous activity rather than
a one-time project, it is impossible to estimate the return
on investment (ROI) from EA efforts
 However, it is arguably impossible to manage thousands,
hundreds and even tens of information systems without
using enterprise architecture to drive their evolution
 An EA practice is simply not an option any longer
 What Organizations Practice EA?
 An EA practice can benefit all organizations employing
more than 30-50 IT specialists where IT is used to
support main business activities
 Enterprise architecture is practiced in commercial
companies and non-profit organizations from diverse
industry sectors including banking, agriculture, retail,
education, healthcare and public services
 Currently the vast majority of large organizations in
developed countries either already practice enterprise
architecture or plan to start practicing it in the near future
Historical Origin of Enterprise Architecture
 The widespread commercial adoption of information
systems in business began in the late 1950s
 Since then the issue of organization-wide information
systems planning gained significant attention
 Since the 1960s consultancies and experts proposed
numerous step-by-step architecture-based planning
methodologies, and later EA frameworks, to translate
business strategies into architectural plans for IT, e.g.
BSP, Method/1, Information Engineering, EAP, FEAF and
TOGAF
 However, none of these formal architecture planning
methodologies actually worked successfully in practice
 Modern EA Best Practices
 Genuine EA best practices emerged and matured in
industry as numerous system planners tried to address
the problem of business and IT alignment
 The emergence of consistent EA best practices is a
natural reaction of industry, rather than a deliberate
product of some consultants, gurus or “fathers”
 EA methodologies and frameworks might have inspired
current EA best practices, but did not define them
 Although the concept of enterprise architecture is
associated with popular EA frameworks, e.g. TOGAF,
Zachman and FEAF, all these frameworks have nothing
to do with the actual EA best practices
 An EA Practice as City Planning
 An EA practice is a complex and multifaceted
organizational practice representing a sophisticated
interaction of various people, EA artifacts and processes
 The general mechanics of an EA practice is far from
trivial and can be best explained using close analogies
from other, more intuitive areas
 The practice of using enterprise architecture for
managing the evolution of organizations can be
compared to the practice of city planning
 The analogy between city planning and EA practices
provides an elegant illustration of what enterprise
architecture is and how enterprise architecture works
 Analogy Between the Involved Actors
 Main actors of an EA practice have close analogies in
city planning
 Business executives can be compared to city governors
developing their city in the interests of its inhabitants
 IT project teams can be compared to construction project
teams responsible for constructing specific buildings
 Architects can be compared to city planners responsible
for the technical aspects of urban planning
 Both city planning and EA practices are continuous
activities intended to control the ongoing evolution of
complex dynamic systems
 Common Properties of the Subjects
 Cities and organizations share many common properties
important from the perspective of their planning:
• Both have some valuable objects “visible” for their end users as
well as some “invisible” technical infrastructure
• Both cannot be perfectly planned in every detail
• Both cannot be designed and built from scratch
• Both run and evolve simultaneously
• Both evolve slowly in a continuous and path-dependent manner
• Their evolution is always limited by their current structures
• Poor planning decisions can hinder their further development
• Their evolution is endless and has no definite final state
• Both have no single best ways to evolve, but a set of options
 Common Concerns of Planning
 Due to their common properties, all planning decisions in
city planning and EA practices have to take into account
a number of similar concerns:
• Decisions should be satisfactory from both the visible ultimate
value perspective and the invisible technical infrastructure
perspective
• Decisions should fulfill specific short-term needs and solve
current problems
• Decisions should also contribute to abstract long-term goals
• Decisions should take into account the current structures and
leverage them when possible
• Decisions should not create obstacles for the future evolution
 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 can be very diverse and differ in their
informational contents, general meanings and lifecycles
 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
• 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
 Duality 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
 Example of a Dual EA Artifact

This solution overview helps business and IT stakeholders

make optimal collective planning decisions regarding the
launch of a new IT initiative
 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
 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
 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
 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
 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
Decisions and Facts EA Artifacts
 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
 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
 Temporary 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
Permanent and Temporary EA Artifacts
Examples of EA Artifacts
 Six Common Types of Documents
 EA artifacts help manage the evolution of an
organization, while city planning documents help
manage of the evolution of a city
 All EA artifacts can be separated into six general types:
• Considerations
• Standards
• Visions
• Landscapes
• Outlines
• Designs
 These six types of EA artifacts also have direct analogies
in a city planning practice
 Commonalities Between Documents
 Considerations and Standards describe certain rules
defining an organization or city
 Visions and Landscapes describe the high-level
structure of an organization or city
 Outlines and Designs describe specific planned
incremental changes to an organization or city
 Considerations, Visions and Outlines describe an
organization or city through its “visible” ultimate value
 Standards, Landscapes and Designs describe an
organization or city from the perspective of its “invisible”
technical infrastructure
 Commonalities Between Views
 Each type of documents answers different questions:
• Considerations - how an organization or city is organized from
the business or livability perspective
• Standards - how an organization or city is organized from the IT
or urban infrastructure perspective
• Visions - what the high-level structure of an organization or city is
from the business or livability perspective
• Landscapes - what the high-level structure of an organization or
city is from the IT or urban infrastructure perspective
• Outlines - what specific changes to an organization or city are
proposed from the business or livability perspective
• Designs - what specific changes to an organization or city are
proposed from the IT or urban infrastructure perspective
Taxonomy for Documents
 Considerations (Contents)
 Considerations are abstract high-level guidelines or
imperatives defining an entire organization or city
 Considerations are important for business executives
and city governors at the same time also having
significant technology-related consequences for the
whole IT or urban landscape
 Considerations (Usage)
 Considerations represent planning decisions and are
always established collaboratively by business
executives and architects for an organization or by city
governors and city planners for a city
 Considerations provide a common basis for all further
discussions and influence all planning decisions
 The dual nature of Considerations allows business
executives and city governors to implicitly shape their IT
or urban landscape, even though Considerations often
do not mention explicitly the IT or urban infrastructure
 Standards (Contents)
 Standards are highly specialized low-level technical
guidelines prescribing how the IT or urban landscape
should be organized and built
 Standards are critically important for architects and city
planners, but largely irrelevant and meaningless for
business executives and city governors
 Standards (Usage)
 Standards represent planning decisions and are always
established collectively by architects or city planners
based on their understanding of the best interests and
concerns of business executives or city governors
 Standards influence the designs of all individual IT
systems or buildings as well as the overall structure of
the IT or urban landscape
 Standards help reduce complexity and achieve
homogeneity of the IT or urban landscape, reuse proven
technical best practices, ensure compliance with the
existing regulatory norms and accelerate the
construction of new IT systems or buildings
 Visions (Contents)
 Visions are abstract, often one-page diagrams providing
high-level views of an entire organization or city
 Visions are critical for business executives and city
governors, and also have direct implications for the IT or
urban landscape from the technology perspective
 Visions (Usage)
 Visions are planning decisions developed collectively by
business executives and architects for an organization or
by city governors and city planners for a city
 Visions are consistent with Considerations
 Visions reflect the general future direction and suggest
what should be done in order to execute the business or
city development strategy
 The dual nature of Visions allows business executives
and city governors to implicitly develop their IT or urban
landscape in the right direction, even though Visions
often do not mention explicitly the IT or urban
infrastructure
 Landscapes (Contents)
 Landscapes are formal diagrams describing the IT or
urban landscape from the technology perspective
 Landscapes are important for architects and city
planners, but virtually useless for business executives
and city governors
 Landscapes (Usage)
 Landscapes represent documented facts and may be
developed and maintained for an organization or city by
individual architects or city planners alone
 Landscapes are used mostly by architects or city
planners and typically serve two different purposes:
• Help understand which IT or urban infrastructure is redundant,
unfit for purpose or aging and plan the replacement
• Help plan the designs of individual IT or construction projects
and connect new projects to the existing infrastructure
 Landscapes help rationalize the IT or urban
infrastructure, reuse existing assets and accelerate the
planning of new IT systems or buildings
 Outlines (Contents)
 Outlines are high-level descriptions of separate IT or
construction projects from the perspective of value
 They provide relevant summary information regarding a
proposed new IT system or building, but do not contain
sufficient technical details to actually implement it
 Outlines (Usage)
 Outlines represent planning decisions and are created
collaboratively by architects and business executives or
by city planners and city governors
 Outlines are initiated from Visions, consistent with
Considerations and leverage Standards and Landscapes
 Outlines inform business cases for IT or construction
projects and serve as main discussion points for them
 The dual nature of Outlines allows business executives
and city governors to control all IT or construction
investments, even though Outlines only briefly mention
the IT or urban infrastructure
 Designs (Contents)
 Designs are detailed technical descriptions of separate
IT systems or buildings actionable for their implementers
 Designs provide IT or construction specialists with the
precise information required to deliver the project, but
are irrelevant to business executives and city governors
 Designs (Usage)
 Designs represent planning decisions developed
collectively by architects and IT project teams for all IT
projects or by city planners and construction project
teams for all construction projects
 Designs are based on Outlines, follow Standards and fit
into Landscapes
 Designs are used by IT or construction project teams
responsible for implementing the project as planned
 The dual nature of Designs allows IT or construction
project teams to implicitly deliver globally optimized IT
systems, even though Designs do not describe explicitly
any global considerations
 Mutual Alignment of EA Artifacts
 The alignment of one EA artifacts to the planning
decisions reflected in other EA artifacts enables the
connection and traceability between the business and IT
perspectives, strategic and tactical plans, organization-
wide and project-level decisions, global and local
concerns:
• Considerations impact all other types of EA artifacts
• Standards provide guidelines for Outlines and Designs
• Visions initiate the creation of new Outlines
• Landscapes provide the environment for Outlines and Designs
• Outlines provide the initial basis for developing Designs
• Designs to not influence other EA artifacts
Relationships Between EA Artifacts
 Uniqueness of Different EA Artifacts
 Each of the six general types of EA artifacts and city
planning documents fulfills a specific purpose in the
context of an EA or city planning practice:
• Considerations help control the development of the IT landscape
• Visions help define the overall strategic direction
• Outlines help approve tactical steps towards the global direction
• Designs help optimize the IT landscape by means of embedding
globally optimized technical decisions into local IT projects
• Standards and Landscapes are used largely as reference
materials to facilitate optimal technical decision-making
Complementarity of Different EA Artifacts
 Different EA Artifacts and Alignment
 The six general types of EA artifacts reinforce each other
and ensure that all IT projects in an organization:
• Fulfill local needs and requirements
• Contribute to long-term strategic goals and objectives
• Implemented rapidly in a predictable and cost-effective manner
• Reuse and leverage available IT assets
• Do not create redundant IT assets
• Can be reused and leveraged as IT assets in the future
• Built on technologies that the organization wants to continue
using in the future
• Implemented consistently with other similar projects
• Do not introduce complexity beyond necessity
 The CSVLOD Model
 Considerations, Standards, Visions, Landscapes,
Outlines and Designs (CSVLOD) are the core
fundamental components of enterprise architecture
 The six-type CSVLOD model of enterprise
architecture explains the notion of EA as a set of six
complementary types of EA artifacts and provides a
robust evidence-based conceptualization of EA
 The CSVLOD model reflects the essence of all key EA
artifacts, actors and activities constituting an EA practice
 The CSVLOD model introduced in this lecture will be
used as the basis further in this course and described in
more detail later in Lecture 8