The Slides are from my session at "An Evening of Enterprise Architecture Awareness" held at theUniversity of Sussex Hosted by the BCS Local Chapter and facilitated by the BCS EA Specialist Group.

1. 13/11/2018
1
An Evening of Enterprise
Architecture Awareness
BCS Enterprise Architecture
Specialist Group
Hosted by
Wednesday 14 November 2018
Sussex University
#BCS
#BCSEASG
www.bcs.org
Daljit Banger , Lorne Mitchell, Ian West
Running Order
1. Enterprise Architecture an Introduction from the
Real World
2. Agile Enterprise Architecture: Paradox or
Oxymoron?
3. Modelling for Enterprise

2. 13/11/2018
2
Enterprise Architecture
An Introduction
Daljit Banger MSc FBCS
14th Nov 2018
Hosted By
Context
Enterprise
Architecture
What
HowWhy

3. 13/11/2018
3
Some Terms….
Enterprise
• An undertaking ( commercial or not-for-profit ) existing to
deliver specific products/services or capabilities to a set of
consumers - People, Places and Things.
Systems
• A set of things working together as parts of a mechanism or
an interconnecting network
• Methods, Procedures and Routines created to carry out a
specific activity, duty, or solve a problem.
Architecture • The art of designing and building Systems and Structures.
Capability
• The power or ability for a computer system to do something
i.e. performing a specified task or set of tasks.
Service
• The ability to do something or deliver something of material
value e.g. a business capability like Human Capital
Management (HCM)
Governance • The action of governing and controlling a set of technology
capabilities in an Enterprise.
People,
Places and
Things
Inputs,
Processes &
Outputs
New
Business
Models
Considerations…
Operating
Environment
Technical
Debt
Complex
Technology
Estates
InnovationNew Ways
of Working
/ Channels
Systems
Best
Practices
IT Costs /
Budgets
Technology Alignment / calibration
Drivers
for
Change
Enterprise Architecture as a function
ensures that all of the above, at a
minimum, are aligned and managed to
deliver the strategic, tactical and
operational goals of the Organisation.
Business
Strategy
Global
Services

4. 13/11/2018
4
 Enterprise Architecture supports how one builds a reusable
Unified Information Systems/Management Capability that
supports and meets Organisational needs.
 The EA Goal is to Align and Manage the Technology
landscape of an Organisation with its Strategic /
Operational Goals/Objectives for both today and tomorrow.
 Enterprise Architecture is NOT Enterprise Systems
Architecture.
 Enterprise Architecture is NOT a methodology for building a
stand-alone single information system.
 Enterprise Architecture is NOT Enterprise Systems
Architecture.
 Enterprise Architecture is NOT a methodology for building a
stand-alone single information system.
Food for thought ..
A Quick Introduction

5. 13/11/2018
5
The Stack – (BOM to Technology Mapping)
Each layer in the Stack can be further decomposed, with each layer pushing or consuming to the layer above and below.
The Stack – (BOM to Technology Mapping)
Each layer of the Stack is a complex view in its own right of a specific element of
how the layer above and below maps and interacts to support the Business
Operating Model
What are the tools available to us to analyse, visualise and render to stakeholders
the alignment ?
The Stack (Methods/Questions)

6. 13/11/2018
6
The Stack (Points in time )
• What if a new piece of legislation is imposed by a Local, Central or
International body with which the organisation must comply?
 One such piece of legislation that is coming in 2018 is the General Data Protection
Regulation (GDPR)
• Full text of GDPR can be found at http://ec.europa.eu/justice/data-
protection/reform/files/regulation_oj_en.pdf )
• “Do nothing” was not an option as GDPR significantly raised the
stakes in terms of compliance, with maximum penalties of 4% annual
global turnover or up to 20m Euros (whichever is higher).
• How do we ensure that we are compliant using an Enterprise
Architectural Approach and that we have factored most areas of our
technology estate to the problem?
• More info available at my blog :
https://dalbanger.wordpress.com/2017/03/18/general-data-protection-regulation-
gdpr-and-the-enterprise-technology-landscape/
Example Scenario
Example Scenario

7. 13/11/2018
7
Guidance
Consent
• freely given
?
Transparency
Profiling
High risk
processing
Certification
Administrative
fines
• 4% annual global
turnover or up to
20m Euros
(whichever is
higher).
Breach
notification
• where feasible,
within 72 hours of
becoming aware!
Data
transfers
Privacy by
Design
General Data Protection Regulation (GDPR)
http:www.s-ea-t.com
CopyrightDaljitRBanger
Impact / Touchpoints
Data
Breach
Policy
Audit /
Trace
Reporting
Info
Exchange
Policies
Info
Processing
controls
refactoring
refactored
Controls
DR
Systems
Compliance
Procedures
Reporting
SQL Extracts
Audit
Privacy by
Design
principle
Impact of GDPR on the Enterprise / Actions

8. 13/11/2018
8
Products of Enterprise Architecture
The deliverables and attributes of
artefacts produced by the EA teams will
be directly influenced by one or all of the
following:
TheStructure/Sizeofthe
Organisation
Characteristicsofthe
Organisation
TheOperatingEnvironmentofthe
EnterpriseArchitecturePractice
Managementbuy-inofEnterprise
Architecture
SizeandBudgetAvailabletothe
Team.
TeamCapabilities
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/industries are ever identical
Abstract
• Notional
Models
• Views
Functional
interactions &
Inter-
relationships
Artifacts /
Components
Support /
Hygiene
Regulatory
Requirements
Vision -
Goals
Context..

9. 13/11/2018
9
Control
Governance –
Process
Boards –
Review,
Technical,
Business
Boards
Programme /
Project
Engagement
Business /
Partner
Engagements
Stakeholder
Management
Approvals –
Build Permits
Inform
Principles
Policies
Portfolio
Manageme
nt
Funding
Models
Reference
Models
• Technical
• ApplicationBest
Practices
Patterns
Impact
Assessmen
ts
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…
Enterprise Architecture Products (Support/Enablers) ..
Enterprise Architecture - Example Product Matrix
Control Inform Direct Artefacts
x x x API Management
x x Governance – Process
x x Application - Target Architecture/s
x x Architectural Boards – (Review, Technical, Business Boards(Participation))
x x Architectural Principles - System, Process, Generic
x x x Best Practices Research / Promotion/ Socialisation
x x x Business Architecture Target Definition
x x x Data & Information (MDM Strategy), Journey from Data to Insights
x x x Financial / Funding Models (TCO, Investment Plans)
x x x Gap Analysis – New Solutions, Transitional States
x x x Group / System Policies (Sys Admin etc)
x x x Impact Assessments - Projects, Technologies, Solutions
x x x Infrastructure Target Architecture – Enabling Technology & Platforms
x x Reusable System Patterns (Dev, Integration etc.)
x x Portfolio Advisory
x x x Programme / Project Engagement
x x x Reference Models
x x x Technical / Application
x x x Roadmaps (Product / Technology)
x x x Service catalogue
Strategy (Product/technology, Deviation etc.)
x x x Service promotion Plans
x x x Stakeholder Engagement
x Stakeholder Management
x x Standards / Notations (Promotion of BPMN, UML, Archimate, etc.)
Enterprise Architecture – Example Product Matrix

10. 13/11/2018
10
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.
Products of Enterprise Architecture Contd..
Services/Touchpoints of Enterprise Architecture

11. 13/11/2018
11
The Role..
• Strategic input into the technology roadmaps of the organisation –
shape, form and stabilise.
• Influence decision makers on technology investment – current & future
• Provide systems consultancy, guidance and assurance to large
programmes.
• Review and assure Solution Designs produced both internally and by 3rd
party suppliers.
• Ensure that governance mechanisms such as review boards, principles
etc. are maintained and supported.
• Police the standards through Project and Programme engagement.
• Represent the organisation with 3rd parties, for example Systems
Integrators and Standards Bodies.
• Understand the impact of the introduction of new technology into the
technology landscape of the organisation.
Enterprise Architects maintain the organisational abstract view, with a primary
objective to ensure that the technology landscape is aligned to the strategic,
operational and tactical goals of the organisation.
Roles & Responsibility (EA)

12. 13/11/2018
12
Solution Architects work with/in Projects and
Programmes to provide systems consultancy services,
impact assessments, end-to-end designs, cost models..
Solution Architects work within the Projects and
Programmes to deliver the following architectural
services:
• Manage the ‘cradle to grave’ – from conception
through to delivery into production of solution
architectures.
• Design both the physical and logical components of
solution architectures that will deliver a positive
business outcome.
• Work with Project Managers to provide provisional
costs for the components of the architecture.
• Technical Analysis and Design capabilities
• Business and technical requirements capture, when
required
• Facilitate design workshops
• Validate designs / costs produced by 3rd parties
wishing to sell systems to the organisation.
Technical Architects deliver the lower level of technical
design, based on high-level component solution
designs and costs provided by the Solution Architects.
Technical Architects work with projects and the BAU
organisation to provide some of the following:
•Delivering technical designs and standards and the
associated approvals from the formal governance
channels.
•Understanding the technology estate and the
encapsulated technology components of the
organisation.
•Providing technical recommendations and options
based on solution designs which can cost-effectively be
realised in the production environment.
•Mitigating any technical risks that could occur through
the introduction of new technology into the landscape
of the organisation.
•Providing input into the appropriate innovation
funnels for the analysis of new technology.
•Keeping abreast of technology trends, attending
industry events to ensure product roadmaps are
understood by the Solution and Enterprise Architects.
•Ensuring that production acceptance for projects is
delivered and managed.
Roles & Responsibility (SA&TA)
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’ or Framework approach.
• Architectural Realisation is a way of
thinking and not a concrete technological
implementation. It is however, supported
by frameworks, patterns & best practices
that complement the mindset.
• As an Enterprise Architect you must be aware of both the
technology landscape of your organisation and external factors
that can impact the landscape.

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