Introduction to Enterprise Architecture

title

Introduction to Enterprise Architecture

author

Bernard Szlachta (bs@NobleProg.co.uk)

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

Stakeholder: 
* 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 ⌘

Internal

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

External

• 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?