Introduction to Enterprise Architecture

From Training Material
Jump to navigation Jump to search
Introduction to Enterprise Architecture
Bernard Szlachta (

Processes are not enough ⌘

  • Processes has to be somehow executed (infrastructure, hardware, logical organization of data flow, etc..)
  • Processes themselves do not focus on the other aspects of the enterprise:
    • reuse of services
    • reuse of infrastructure
    • easiness of implementation and change
  • Each stakeholder requires specific information relevant to their position (point of view)
  • Changes made by one stakeholder may impact others
  • There must be a mechanism to predict the impact of changes to other stakeholders

Enterprise Architecture as a process ⌘

  • Process that describe, control an organizations' structure, processes, applications, system and technology
  • Methods and techniques for making and using:
    • Models
    • Visualization
    • Analysis of the impact of changes

Architecture, Model, Visualization, Views, PoV ⌘


Architecture Description ⌘

  • Architecture Modelling Languages
    • Understood by all stakeholders (IT, Business, etc..)
    • Allows to analyse and validate model
  • Viewpoint
    • Aimed at a particular type of stakeholder
  • As-is -> To-be
    • Qualitative impact analysis
    • Quantitative (performance, cost, etc..)

What is architecture ⌘

Building Architecture

  • Suppose you talk to an architect to design a house
  • You tell them how many rooms and what rooms you like, windows, bathrooms, garden, etc...
  • You agree on a master plan, architect produce detailed specifications
  • The specification is used by engineers and builders
  • You can communicate with the architect because you have a common language (e.g. room, staircase, etc..)
  • You know the function of those elements
  • You and the architect use, mentally, an architectural model of a house
  • The model is abstract, it purposely ignores many details

Enterprise Architecture

  • Instead of rooms and windows you will talk about business processes, applications, products, infrastructure

Architecture Definition according to IEEE

Architecture is the fundamental organisation of a system embodied in:
* its components
* their relationships to each other and to the  environment
* and the principle guiding its design and evolution.

What is architecture ⌘

Stakeholder according to IEEE

* an individual,
* team,
* or organisation (or classes thereof)
with interest in, or concerns relative to a system.

Stakeholders and an Architecture

  • Only few stakeholders are interested in a system architecture
  • Stakeholders are more interested in the impact the architecture has on their concerns
  • An architect should be aware of these concerns and discuss them with the stakeholders

Enterprise Architecture (EA) ⌘

Enterprise (The Open Group)

Enterprise: any collection of organisations that has 
a common set of goals and/or a single bottom line

Enterprise Architecture (The Open Group)

Enterprise architecture: a coherent whole of:
* principles,
* methods,
* and models 
that are used in 
the design and realisation of an enterprise's:
* organisational structure,
* business processes,
* information systems
* and infrastructure.

Why do we need EA ⌘

  • The architecture is more stable than a specific solution
  • Provide a holistic view of the enterprise
  • Optimization on the Enterprise Level (System Thinking)
    • Optimization on a system level may decrease flexibility
    • Enterprise is as strong as its weakest link
    • E.g. Sales can receive more orders than the production can cope with
    • Fast infrastructure can be not flexible enough to cope with the changes required by the business
  • EA helps to translate corporate strategy into daily operations (i.e. run processes)
  • Combine models from different domains (UML, BPMN, DSL, etc..)
  • Defines constraints on systems (and increases coherence)
  • Allows choices to be related to the business objectives
  • Allows to manage change in the Enterprise

Does an EA changes? ⌘

We adjust EA because:

  • Growth of the enterprise (organic, acquisition, etc...)
  • Advancements in technology
  • Changes in the corporate strategies/goals (market penetration rather than skimming)
  • We learnt how to do things better

Current state of EA⌘

  • EA discipline is brand new (25 years old, younger than most people in this room)
  • Lack of common language (stakeholders got their own language)
  • Legacy hangover
  • Human languages problem

Architecture as a process ⌘

Architecture is a:

  • product (model, graphs, infrastructure)
  • process (architecture creation, architecture maintenance, communication, alignment)
  • strategy (flexibility vs performance, etc...)


Drivers for EA ⌘


  • Business - IT alignment (top-down, bottom-up)
  • Effectiveness (focusing on relationship between components rather than by the improvements between components)


  • Interoperability with suppliers/buyers (e.g. automatic invoicing)
  • Regulations (e.g. SOX, Clinger–Cohen Act, Basel 3)

Can we do not have EA at all⌘

  • answer the question as in the title?

Questions ⌘

  • Does a good EA hinder innovation?