SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
Scribd wird die Aktivitäten von SlideShare fortführen und den Betrieb von SlideShare ab 24. September 2020 übernehmen.Ab diesem Zeitpunkt liegt die Verwaltung Ihres SlideShare-Kontos sowie jeglicher Ihrer Inhalte auf SlideShare bei Scribd. Von diesem Datum an gelten die allgemeinen Nutzungsbedingungen und die Datenschutzrichtlinie von Scribd. Wenn Sie dies nicht wünschen, schließen Sie bitte Ihr SlideShare-Konto. Mehr erfahren
The purpose of today's session is to introduce core basic concepts around Enterprise Architecture and discuss the role of the Architect .
We shall Discuss the Architectural Stack and the areas it covers Use a Simple Example of an impending Law which will modify some elements of the Stack Discuss Some of the Products that are produced to Control, Inform and Direct the ICT Function to ensure it aligns with Business Goals We will Discuss the Role/Responsibility of the Enterprise Architect Then we will take questions
On the Zachman website – it states The Zachman Framework™ IS NOT a methodology for creating the implementation (an instantiation) of the objects – We can use this as a ‘tick list’ to support the EA
Supporting material for my Webinar to the ACS - June2017
Enterprise / Solution
( webinar from London )
Daljit Roy Banger MSc FBCS1st June 2017
Zachman Framework™ MODAF
Federal Enterprise Architecture
Public Architectural Frameworks
ETOM (Enhanced Telecom
Numerous Frameworks exist which provide views, approaches and general support to help
deliver / manage an Enterprise Architecture Capability
Enterprise Architecture supports how one builds a reusable Unified
Information Systems/Management capability that supports and meets
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.
Something to Consider…
Enterprise Architecture is NOT Enterprise Systems Architecture and this
difference often results in opposing views in terms of capabilities and
These can be expressed as:
A view towards how we construct / reconstruct the Organisation to
deliver specific Enterprise outcomes.
A view with a strong bias towards Technology and how it can be
best provisioned to meet outcomes.
The deliverables and attributes of
artefacts produced by the EA teams will
be directly influenced by one or all of the
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
Gap Analysis –
Enterprise Architecture Products (Support/Enablers)
If, like me, you are a fan of the US HBO “Silicon Valley” TV show, you will have laughed at the guys in
episode 5 discussing SCRUM – if you have not , here’s a link to exert http://youtu.be/oyVksFviJVE .
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.)
worthy of discussion
• This criteria element relates to
the promotion of enterprise wide
principles around the domain of
business processing, especially
business process modelling and
• Principles relating to the design,
build and deployment of
• Principles linked with the
production, cleansing and
publishing of information
• Principles associated with data
design, usage, persistence etc.
• Principles associated with
management of the infrastructure
(data Centres, Servers storage,
• Foundation Services.
• Foundation services relate to DR,
Security, Incident management
etc i.e. services that are core to
all of the above
• 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
• 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
• 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
• The engagement of the Enterprise
Architecture functions with the
Business Process Modelling and
Design functions and any
• EA should facilitate a move
towards Straight Through
processing i.e. reducing the
number of digital and manual
process hand offs between
• The Information Architecture and
the associated process to capture,
manage and publish EA
• 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.
• The maturity of document
production , publication and
promotion by the Enterprise
• 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
• Does the organisation have a
patterns catalogue? How mature
is the organising in publishing it
patterns, do these publications
adopt standards for syntax,
• How are patterns promoted
through the organisation, are they
rendered via an intranet? Or are
they in a document library
• How patterns are developed – are
they text book extracts or are
they developed with the various
• Do the technical Communities use
these patterns to provide
efficiency gains to the
• Application patterns are to be
found publically available and
thus should be exploited – do
your organisational developers for
example exploit published
patterns when constructing
• As with Applications above – Do
your Service delivery personal for
example use standard patterns
for system configurations
deployed into production.
• Security patterns are emerging as
a key in distributed systems – are
these in use ?, does the technical
community know of the existence
• How often are patterns re-used if
at all and do we as an
organisation promote reuse.
• 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
• 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 could refer to
Enterprise Service Buses,
Messaging or even request
brokers – these should be
managed and in most cases the
interfaces to these systems.
• Information and data object
persistence should be monitored
and managed, i.e. not be the
physical devices e.g. the NAS or
• The portfolio management of the
Physical Servers both in the
production and test
• Other Infrastructure
• Maturity of the portfolio
management of the Physical
devices e.g. network Switches,
• The techniques adopted to create,
capture and manage the
information required to measure
the level of maturity in the
management of the ‘artefact’
Products of Enterprise Architecture Contd..
Transposing the “Architect” onto The Stack / BCS SFIA Plus
Roles & Responsibility (EA)
• Strategic input into the technology roadmaps of the organisation – shape, form and
• Insight – understanding the deficiencies of both products and services deployed in the
• 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
• Police the standards through Project and Programme engagement.
• Represent the organisation with 3rd parties, for example Systems Integrators and
• 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 (SA&TA)
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
• Manage the ‘cradle to grave’ – from conception
through to delivery into production of solution
• Design both the physical and logical components of
solution architectures that will deliver a positive
• 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
• 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
•Understanding the technology estate and the
encapsulated technology components of the
•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.
work with/in Projects
and Programmes to
Interaction Points – EA / SA
• Enterprise Architecture is delivered in the context of the
Organisation – true value can not be realised by simply following
a single 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
• As an Enterprise Architect you must be aware of both the
technology landscape of your organisation and external factors
that can impact the landscape.
• EA’s can not work in isolation – programme / project engagement
is essential as it allows a deeper understanding of the estate.
“In the struggle for survival, the fittest win out at the expense of their
rivals because they succeed in adapting themselves best to their
environment” Charles Darwin
Website : www.s-ea-t.com (Tools, Papers Downloads)
Blog : https://dalbanger.wordpress.com/
Email : firstname.lastname@example.org