Introductory Concepts and Practices
Daljit Roy Banger MSc FBCS
Enterprise
Architecture
http://www.s-ea-t.com

• Introduction
 Todays Exam Question
 Sample Definitions
 Enterprise Architecture Views
• Enterprise Architecture Primer
 EA Frameworks
 The Stack / Primer
• Products of Enterprise Architecture
 Context
 Control,
 Inform &
 Direct
 Engagement Model (Projects/Programmes)
 Enterprise Architecture as a career
 Transition
• Thank You
 Final Note
 Question / Answers
Agenda

Introduction

Todays Exam Questions
• What is Enterprise Systems Architecture ?
• What are the Products and Value of Enterprise
Architecture
• Position of Enterprise Architecture within the ICT
organisation

EA seeks to align the Business Supporting processes , Technology
Capabilities (both of today and for tomorrow) to deliver
efficiency and cost gains resulting in some form of competitive
advantage .
EA Aligns the business needs of today & tomorrow with the
technology services and landscape to support those needs in a
cost effective way.
EA attempts to document and understand the Enterprise Eco
System to deliver value adding technology capabilities and
services
Sample Definitions

Enterprise Architecture
• No Single or Generally agreed Standard or
Definition.
• Bias in Approach and Deliverables

SEAT
Zackman
TOGAF
FEAF
MODAF
Enterprise Architecture Frameworks

EA Primer

Value Added / Hygiene Technology Services
NRF Capabilities DR Governance
Enabling Technology (Physical)
Device Hosting Cabling Appliances
Technology Services (Logical)Service
Bus
Messaging Security Logging Containers Monitoring Routing
Name
Services
Data & Information Services
Big Data ETL Custodians Classification Master Data Mgmt. DW
Applications
Custom Off the Shelf Bespoke Development In-house/out-source Development Methods Frameworks
Capabilities / Services
Technical Tactical v's Operational Business Innovation
Business Process
Manual / Automated Formal / Informal Outsourced Straight Through / Call Off Inventory
Business Operating Model
Info / Resources pushed &
pulled
External Forces (Govmnt,
Competitors, Market)
Strategic Drivers Structure B2B, B2C, C2B, C2C
Value Added / Hygiene Technology Services
Consume
Produce/Deliver

Time

Efficiency Gains / Cost
Savings can be achieved
through:
1.Exploiting Technology
Synergies
2.Re-using System Components
3.Exposing System Services to
new processes.
4.Understanding the impact of
new systems on the
performance and capacity of
enabling technologies.

The Products of
Enterprise Architecture

Thus the deliverables and attributes of artefacts produced by the EA teams will
be directly influenced by one or all of the following:
The Structure /
Size of the
Organisation
Characterist
ics of the
Organisatio
n
The Operating
Environment of
the Enterprise
Architecture
Practice
Manageme
nt buy-in of
Enterprise
Architectur
e
Size and
Budget
Available to
the Team.
Team
Capabil
ities
However , irrespective of the structure or capabilities of the team,
all artefacts can be classified into 1 of 3 domains
One Size does not necessarily always fit all No Two Organisations are Identical

Control
Governance –
Process
Boards – Review,
Technical, Business
Boards
Programme / Project
Engagement
Business / Partner
Engagements
Stakeholder
Management
Inform
Architectural Principles
(Segmented by domains)
Portfolio Management
(Application / Data /
Infrastructure)
Funding Models
Technical Reference
Model
Application
Reference Model
Best Practice
Patterns Repository
Impact Assessments
Marketing Plans
Inventory of Business
Processes
Standards / Notations
Direct
Stakeholder
Engagement
Business Architecture
Target Definition
Application Target
Architecture
Data & Information
(Master Data
Management Strategy)
Infrastructure Target
Architecture – Enabling
Technology & Platforms
Roadmaps (Product /
Technology)
Gap Analysis –
Transitional States
Impact Assessments
Service promotion,
catalogue etc…

Control
Governance
– Process
Boards –
Review,
Technical,
Business
Boards
Programme /
Project
Engagement
Business /
Partner
Engagements
Stakeholder
Managemen

Inform
Principles
Policies
Portfolio
Management
Inventory of
Business
Processes
Funding Models
Reference Models
•Technical
•Application
Best Practices
Patterns
Impact
Assessments
Marketing Plans
Standards /
Notations

Direct
Stakeholder
Engagement
Business
Architecture
Target
Definition
Application
Target
Architecture
Data &
Information
(Master Data
Management
Strategy)
Infrastructure
Target
Architecture –
Enabling
Technology &
Platforms
Roadmaps
(Product /
Technology)
Gap Analysis
– Transitional
States
Impact
Assessments
Service
promotion,
catalogue
etc…

CID Touch Points
I
C
D I
CI
I
C
C
I
I
D
D
I
I

Principles
• Business
• This criteria element relates to
the promotion of enterprise wide
principles around the domain of
business processing, especially
business process modelling and
service design.
• Application
• Principles relating to the design,
build and deployment of
applications
• Information
• Principles linked with the
production, cleansing and
publishing of information
• Data
• Principles associated with data
design, usage, persistence etc.
• Infrastructure
• Principles associated with
selection, deployment,
management of the infrastructure
(data Centres, Servers storage,
network etc)
• Foundation Services.
• Foundation services relate to DR,
Security, Incident management
etc i.e. services that are core to
all of the above
Practices
• Business Operations
• Here Enterprise Architects should
be concerned with the practices
associated with capturing,
modelling and digitally executing
the business operations.
• Application Design
• I.e. delivery of designs of. Whilst,
practices adopted may based on
a specific methodology or
approach, the real question ‘ how
efficiently have we adopted the
practices of the approach and are
we meeting the business
demands based on this adoption
?’
• Application Build
• The maturity of the build of
applications both internal and
externally developed applications
should encapsulate test of
software unit, components etc
prior to build
• Governance
• Architectural Governance and the
teeth i.e. power of associated with
the various boards.
• Service Delivery
• The maturity of the practices i.e.
what actually happens during the
deployment, management of
systems on the technology
landscape.
• Support
• Whilst this is close to Service
Delivery it must be noted that we
should rank how effectively the
EA team deliver the support of its
artefacts
Process
• Business
• The engagement of the Enterprise
Architecture functions with the
Business Process Modelling and
Design functions and any
alignment activities.
• STP
• EA should facilitate a move
towards Straight Through
processing i.e. reducing the
number of digital and manual
process hand offs between
processes.
• Information
• The Information Architecture and
the associated process to capture,
manage and publish EA
information.
• Orchestration
• This relates to the processes
associated with orchestrating
business and technology services
• Production Acceptance
• The maturity of the processes
associated with deployment,
management of systems accepted
into the production environment.
• Documentation
• The maturity of document
production , publication and
promotion by the Enterprise
Architecture function
• 3rd Party Engagement
• How effectively does EA engage
with 3rd parties to maximise the
benefits to the organisation e.g.
cost reductions, savings etc
• Contribution to the Enterprise
• What is the general perception of
EA processes e.g. Governance
contributing real value to the
organisation from system users to
senior management?
Patterns
• Publications
• Does the organisation have a
patterns catalogue? How mature
is the organising in publishing it
patterns, do these publications
adopt standards for syntax,
notations etc
• Promotion
• How are patterns promoted
through the organisation, are they
rendered via an intranet? Or are
they in a document library
somewhere?
• Development
• How patterns are developed – are
they text book extracts or are
they developed with the various
technical communities?
• Usage
• Do the technical Communities use
these patterns to provide
efficiency gains to the
organisation?
• Application
• Application patterns are to be
found publically available and
thus should be exploited – do
your organisational developers for
example exploit published
patterns when constructing
applications.
• Infrastructure
• As with Applications above – Do
your Service delivery personal for
example use standard patterns
for system configurations
deployed into production.
• Security
• Security patterns are emerging as
a key in distributed systems – are
these in use ?, does the technical
community know of the existence
• Re-Use
• How often are patterns re-used if
at all and do we as an
organisation promote reuse.
Portfolio
Management
• Services
• Most Organisations have their
own definition of a Services the
EAM measure assumes a service
as a function that is well-defined,
self-contained, and does not
depend on the context or state of
other services. A service can be
either a business or technical
object.
• Application
• The portfolio of applications in an
Organisation can be a mix of
either bespoke or Commercial Off
the Shelf (COTS) either way the
life cycle should be managed in a
single unified location.
• Middleware
• Middleware could refer to
Enterprise Service Buses,
Messaging or even request
brokers – these should be
managed and in most cases the
interfaces to these systems.
• Storage
• Information and data object
persistence should be monitored
and managed, i.e. not be the
physical devices e.g. the NAS or
SANs etc.
• Servers
• The portfolio management of the
Physical Servers both in the
production and test
environments.
• Other Infrastructure
• Maturity of the portfolio
management of the Physical
devices e.g. network Switches,
laptops, etc.
• Techniques
• The techniques adopted to create,
capture and manage the
information required to measure
the level of maturity in the
management of the ‘artefact’
portfolio.
5P’s of Enterprise Architecture

EA Career Path

Transition to an Enterprise Architecture

Final Note
• Enterprise Architecture is delivered in the context of the
Organisation – true value can not be realised by simply
following a single ‘Cook Book’ approach.
• Architectural Realization is a way of thinking and not a
concrete technological implementation. It is however,
supported by frameworks, patterns & best practices that
complement the mindset.

Website : www.s-ea-t.com (Tools, Papers Downloads)
Blog : https://dalbanger.wordpress.com/
Email : dal@s-ea-t.com
Thank
You