An Enterprise Architecture Development Framework

An
Enterprise Architecture

Development Framework

The Enterprise Reference Maps, Single Page Business
Architecture, Metamodel
SOA Design, Business Case and Strategic Planning for your
Enterprise
4rdth Edition, electronic format Kindle

Adrian Grigoriu
practicing architecture for a very long time
© Copyright 2005-20011 by Adrian Grigoriu

The copyright for any material created by the author is reserved. No part of this publication may
be reproduced or transmitted in any form or by any means, electronic, mechanical, including
photocopying, recording, or by any information storage and retrieval system, except in case of
reviews, without the express written permission of the author.

“I enjoyed reading this book. It was as if Grigoriu had laid out all the
business and IT elements that make up an enterprise on a table and then
played around until he could fit them all together into a single cube – an
ingenious effort at puzzle solving…
I would happily recommend this book to anyone who is already an
experienced enterprise architect. This book is an excellent “graduate
review” that will force you to think through lots of issues and consider how
you might address them in your own architecture.
I would also recommend this book to someone who was interested in the
issues involved in building a business case for an Enterprise Architecture
effort – the sections on benefits and costs are excellent and comprehensive
–
and I’d also recommend this book to someone who wanted to learn
more about how to classify stakeholders. The section on strategy and
stakeholders is outstanding”.
Paul Harmon, the Executive Editor of Business Process
Trends (www.bptrends.com), a recognized BPM analyst and consultant and
the author of Business Process Change.

The Problem: today's unresponding “legacy” Enterprise in a world of

increasingly increasing complexity, amount of information, rate of change and
competition.
The Solution: the Enterprise Architecture (EA) offering streamlining,
alignment, blueprinting, strategic planning, and agility through SOA, the target
state of the Enterprise.

The book describes:

drivers, benefits and Business Case for an EA evaluating financial
Payback and NPV

the Return on Enterprise Architecture (RoEA)

RoEA = Revenuearch/Costsarch
Revenuenoarch/Costsnoarch

a Single Page Enterprise Architecture, a synoptic view of the Enterprise
operation
Enterprise reference maps, covering business and technology architecture
templates
alignment of your on-going solutions architecture projects to the
Enterprise Architecture
a navigable EA framework and its metamodel describing the Value
Chains, Business & Operating Models, Functions and Flows resourced
by Organization and Technology layers
classification of and mapping to other EA frameworks: Zachman,
TOGAF, DoDAF…
a unifying view of EA, Service Oriented Architecture (SOA), Value
Chains, Business Models, Processes (BPM) and IT Architecture,
patching the divide between the Business and IT
a best practices process for building the EA and SOA,, an EA
development exercise, and how to use the framework for ITIL, M&A,
Outsourcing, Start-ups…
EA patterns, inhibitors, maturity models, politics & sell
a Strategy specification process and alignment to business activities,
organization and technology.
“There are a few books that take a broad perspective, but most focus on
creating an IT architecture. An Enterprise Architecture Development
Framework, by Adrian Grigoriu, is a pleasant exception. Grigoriu takes a very
comprehensive view of things and works to show how everything can be
integrated within a broadly conceived view of things”.

Paul Harmon, the Executive Editor of Business Process Trends

(www.bptrends.com).
CONTENTS AT A GLANCE

1. About the book
2. EA provides a competitive edge to the Enterprise
3. The Problem and Drivers for Change
4. Enterprise Architecture, The Solution
5. Enterprise Architecture Benefits
6. The Business Case and Return on EA (RoEA)
7. Technologies referred to, supporting the EA
8. EA Frameworks and Classification
9. The Function - Flow - Layer - View (FFLV) Framework design
10. Enterprise Reference Maps and Organization design
11. EA Patterns and Single Page Architecture
12. The FFLV Framework and navigation
13. The Enterprise wide IT Architecture
14. Service Oriented Architecture - SOA
15. Strategic Planning and Enterprise Transformation
16. The EA Development Process and Best Practices
17. An EA Design Exercise
18. Framework use cases for M&A, Outsourcing. ITIL...
19. The EA Governance, Program and the Architect role
20. EA Maturity, Value and Sell
21. EA Roadblocks, Culture and Politics
22. EA State, future Outlook and the Virtual Enterprise
23. Enterprise Architecture Recap
References
Acronyms
About the Author

TABLE of CONTENTS

1. About the book

Why this book
Outline
Audience
Review checklist
2. EA provides a competitive edge to the Enterprise
Review checklist
The Problem
Business Trends
Business needs
What business constantly requires from IT
What the Government sector expects from IT
Review checklist
EA, the Solution to the Enterprise Problem
What is Enterprise Architecture (EA)
EA definitions
Own EA definition
Review checklist
Governance Benefits (G)
Enables Business Modeling
Improves Decision Making
Aligns Technology to Business Processes and Goals
Enables Agility, Faster Business Change
Enhances Project Planning and Prioritization Accuracy
Operational Benefits (O)
Maximizes Reuse of Existing Assets
Simplifies the Enterprise operation
Aligns Organization to Enterprise operation
Improves Operating Procedures
Enhances Enterprise Processes
Enables Activity Based Costing (ABC)
Permits Faster New Product introduction
Exploits Synergies between similar operations of the Enterprise
Strategic Benefits (S)
Maps Roadmaps to Architecture
Facilitates Vendor Products Roadmaps alignment to EA
Provides Agility to business change
Enables Outsourcing and Mergers & Acquisitions
Improves Risk Management
Communication, Collaboration and Compliance Benefits (C)
Improves Stakeholders’ Understanding and Communication
Enhances Working with Suppliers and Partners
Makes Regulatory Compliance possible
Review checklist
6. The Business Case and Return on EA (RoEA)
How do you ‘cost-justify’ Architecture
Return on Enterprise Architecture (RoEA)
Key benefits indicators table
Quantifying the Costs and Revenue relative to the non EA case
The EA development Revenue and Cost curves
EA Payback and NPV
Review checklist
Web Services (WS) and XML
Enterprise Integration EAI/ESB
Enterprise Resource Planning (ERP)
IT Information Library (ITIL)
Control OBjectives for Information (COBIT) and Val IT
Business Process Management (BPM)
Six/Lean Sigma
Capability Maturity Model (CMM)
Business Process representation
Porter's Value Chains
Balanced Scorecard
Compliance (SOX, BASEL II. HIPAA…)
Agile Processes and Smart Deliveries
Review checklist
8. EA Frameworks and Classification
EA frameworks overview
Zachman's
EAP, Spewak's
FEA Reference Model
DODAF
TOGAF
Other: NGOSS/eTOM, PERA, E2AF, BPTrends EA Pyramid…
An EA frameworks classification
Review checklist
9. The Function - Flow - Layer - View (FFLV) Framework design
An EA framework definition
EA Framework in analogy to the Human Body
EA Framework Entities
This framework description and components
The EA design approach, in short
Enterprise Context, Stakeholders' Interactions/Use Cases
The Business Functions
The Business Flows
Customer’s View of the Enterprise
Owner's View of the Enterprise
The Functional Architecture: Flows over Functions
The EA Resource Layers: Technology and People
A Function Stack consists of Business, Technology and People
A Flow is executed by a sequence of Function Stacks
EA Layer specific Views
Business Layer Views: processes & orchestration, strategy & objectives
Technology Layer Views
People Layer Views: organization, culture, communications…
Enterprise wide Views: Information, Security, Performance, Finance…
The Information Architecture
The Security View
The Location (Where) View
The Performance View
The Planning and Evolution View
The Financial View
Architecture Principles
Decoupling/Modularization
Encapsulation
Layering
Hierarchical design
Distribution agnostic
Standardization
Duplication minimization
Technology Design Standards
Design on SOA services with ESB and Web Services
Employ Container/Application hosting technology (JAVA, .NET,
Portal)
Virtualise technology
Use technology Appliances
Converge data, voice and video networks
Deploy Web interactive access for stakeholders
Reuse, Buy or Build
Review checklist
10. Enterprise Reference Maps and Organization design
Organization design
Business and Operating Model, Value Chain
Business Models
Operating Models
Value Chains
The Enterprise GODS map
The IT EA Template
The Business (Functions) Reference Map
The GODS single page generic Business Architecture
The Business Flows Reference Map
The Enterprise Group Line of Businesses
Terminology of Business Architecture
The Applications Reference Map
The Information Reference Map
The Infrastructure Reference Map
Mapping Reference models to Organization
Review checklist
11. EA Patterns and Single Page Architecture
Enterprise Architecture patterns
Business Layer
Application Layer
Infrastructure Layer
The Single Page Enterprise Architecture (SPEA)
Review checklist
The EA Function - Flow - Layer - View, FFLV Framework
The three dimensions of the FFLV Framework
The FFLV Framework Tree
The Key FFLV Views
The FFLV Framework Metamodel
The FFLV Framework Navigation
A Customer's request navigation scenario
The FFLV mapping to other frameworks
Mapping to Zachman
Mapping to the four "standard" EA layers
Mapping to DODAF
Review checklist
The role of IT
Business drivers for IT
Key IT projects
Solution Architecture alignment to EA
Applications Inventory
Integration Architecture
IT Obsolescence and EA roadmap
The EA versus ITIL, BPM, Six Sigma, ERP, ITIL…
Review checklist
What is SOA or WOA for that matter
SOA benefits
SOA and BPM
SOA and EA
SOA + EA = SOEA
SOA, To Do or To Buy
SOA Design Best Practices
A SOA Design Case
Evolution to SOA
SOA, lessons learnt
Review checklist
15. Strategic Planning and Enterprise Transformation
Do Environment Analysis: PESTEL, Porter's 5 Forces
PESTEL
Porter's Five Forces
Do Company Analysis
Do Stakeholders' analysis
Outline Enterprise Vision, Goals and Targets
Specify Strategies
Balance benefits between Stakeholders
Check Strategies for Feasibility, Acceptability, Suitability
Cascade Strategy planning to the EA Tree
Specify the Strategic Execution Roadmap & Mapping
Review checklist
16. The EA Development Process and Best Practices
What is the value of Best practices
Define EA Mission and Deliveries
Capture stakeholders’ requirements, determine scope
Build the Business Case for Enterprise Architecture
Get Support from Top Level Management & Business
Build the EA Governance team
Nominate the EA core and virtual team
Specify an Enterprise Architecture Framework
Select an EA Tool set to support the framework
Outline a Design Strategy
Bottom-Up discovery of existing technology and model ERP processes
Design SOA in the middle to wrap Applications as Business Services
Apply Architecture and Design Principles
Specify an EA execution strategy
Prioritize to deliver the urgent fixes for the Enterprise
Leverage existing applications and infrastructure
Work with Suppliers to package applications as SOA services
Design, Plan and Implement iteratively
Use an Agile Processes (AP) approach
Establish SMART Deliveries, CSFs, KPIs
Agree Best Practices
Design the Business Functions and Flows Architecture
Discover As-Is Using the Business Reference Map and framework
layers
Cascade Strategy objectives and initiatives to EA tree
Sketch the target Enterprise state
Assess Gap between current and target states, establish roadmap
Establish project portfolio and program plan
Establish EA operational governance
Execute Enterprise transformation iteration and evaluate EA maturity
Review checklist
The Design process steps
An EA development exercise or virtual case study
Specify Enterprise Mission & Products, Vision, Strategy and Objectives
Document Stakeholders' Interactions and internal requirements
Design the Business Functions Map
Design stakeholders' scenarios as Flows over Functions
Draft the Single Page Architecture
Specify the Applications executing processes in Functions
Draw the Infrastructure aligned to Applications
Map Information entities to Functions
Map Organization units to Functions
Link all Views in the EA framework
Specify Target Objectives and Vision for the Enterprise
Design the target EA, employ SOA paradigm
Assess gaps and devise the Transformation roadmap and program
Instead of Case Studies
Review checklist
18. Framework use cases for M&A, Outsourcing. ITIL...
EA Framework use for Investment
EA Framework for IT services management (ITIL) architecture
EA Framework for Security Architecture
How to design your Enterprise around the customer
EA Framework use for Mergers and Acquisitions
EA Framework use for Outsourcing
EA Framework use for a Start-Up Business
Review checklist
19. The EA Governance, Program and the Architect role
EA Governance
The EA project organization and funding
An EA site taxonomy
The role of the Enterprise Architect
Enterprise Architect kinds
How does one select an Enterprise Architect
The job description for an Enterprise Architect
The Tasks and authority of the Enterprise Architect
Enterprise Architect as a leader
The growth of EA jobs
Review checklist
Measure your Enterprise Architecture Maturity
EA development maturity
EA exploitation maturity
Measure the Value of EA
Sell the EA
Review checklist
21. EA Roadblocks, Culture and Politics
EA Development Triggers
EA Roadblocks
The Enterprise Inertia, silo organization and the Business - IT divide
The lack of reference Business Architectures
The diversity and non-coordinated approaches to fix the Enterprise evils
EA vague definition, is it a blueprint, process, program, strategic
planning…?
EA scope, no non-IT technology, no people or other stakeholders' views
The EA program developed solely by IT
Lack of an agreed EA framework
Overly simplified EA framework
Lack of Business Case at initiation
EA deliverables not fit for purpose
EA governance and implementation failures
Enterprise Architect not invested with authority
Politics slowing EA development
Independent SOA programs competing for resources
ERP development competing with EA
Not using EA tools
The vast knowledge required and paucity of Enterprise Architects
Roadblocks recap and recommendations
Enterprise Culture and EA
EA Politics
EA Risks and Change Management
Review checklist
22. EA State, future Outlook and the Virtual Enterprise
EA current state
The Virtual Enterprise
The Virtualization of the Enterprise IT
The Virtualization of the Enterprise Architecture (EA) Layers
The Enterprise Value Chain modeling and Virtualization
The Future Outlook for EA
Review checklist
The EA Framework recap
The Key Steps of an EA Development
The EA Deliveries Checklist
Why use the FFLV framework
EA stakeholders' benefits review
The Enterprise Transformation Strategic process
Final Say
Review checklist
References
Acronyms
About the Author

LIST OF FIGURES
Figure 1–1 - The Enterprise Black Box
Figure 1 - 2 - The EA framework key views, BRM and Single Page EA
Figure 1 - 3 - The Enterprise synoptic picture
Figure 44 - EA, the Solution to the Enterprise Problem
Figure 65 - EA Key Benefits Indicators Table
Figure 66 - EA Benefits Indicators mapped to Time to Market
Figure 67 - The EA development Relative Revenue and Cost curves
Figure 68 - NPV and Payback/Breakeven for the development of EA
Figure 79 - A swimlane diagram showing a flow
Figure 710 - The Lean Sigma illustration of a Value Stream
Figure 711 - Porter's Value Chain
Figure 8 - 12 – Zachman's framework, a matrix
Figure 8 - 13 – Spewak's, early Enterprise Architecture Planning Framework
Figure 8 - 14 – FEA Reference Model
Figure 8 - 15 – DODAF viewpoints
Figure 8 - 16 - A comparison between DODAF and the EA four standard
layers
Figure 8 - 17 – TOGAF's layers and process in one view
Figure 8 - 18 – TOGAF views
Figure 9 - 19 - Human Body systems in Analogy to EA entities
Figure 9 - 20 - Enterprise Stakeholders and their Use Cases
Figure 9 - 21 - Enterprise GODS Functions
Figure 9 - 22 - The Customer’s view of the Enterprise
Figure 9 - 23 - The Owner’s View of the Enterprise
Figure 9 - 24 - The Enterprise functional architecture: Flows over Functions
Figure 9 - 25 - Enterprise Layers
Figure 9 - 26 - GODS Functions Stack: Process, Technology, People
Figure 9 - 27 - A Flow is executed by a sequence of Functions stacks
Figure 9 - 28 - Key Enterprise Architecture Layers and Views
Figure 10 - 29 – Organization Models
Figure 10 - 30 - A Business Template modeled on the Value Chain
Figure 10 - 31 - The IT EA template
Figure 10 - 32 - Enterprise Functions aligned to the GODS and IT Template
Figure 10 - 33 - The Business Reference Map/Template
Figure 10 - 33bis - The GODS single page generic business architecture
Figure 10 - 34 - A Business Flows Reference Map/Template
Figure 10 - 35 – An Enterprise Group and its Lines of Business (LoBs)
Figure 10 - 36 – An Applications Reference Map
Figure 1037 – An Information Reference Map
Figure 10 - 38 - An Infrastructure Reference Map
Figure 10 - 39 – EA layers architectures mapping on the organization
Figure 1040 – Functional vs Workplace alignment
Figure 11 - 41 – EA patterns: Nodes and Lines at each layer
Figure 11 - 42 - A Single Page EA modelled on the Business Reference Map
Figure 11 - 43 - A Health Insurance Single Page Architecture-IT template
Figure 12 - 44 - The Function-Flow-Layer-View (FFLV) EA Framework
Figure 12 - 45 - The 3 EA framework dimensions: Function. Flow,
Layer/View
Figure 12 - 46 - The Enterprise Framework Tree
Figure 12 - 47 - Key FFLV Views, Business Reference Map & Single Page
EA
Figure 12 - 48 - The FFLV Framework plain metamodel
Figure 12 - 49 - The FFLV Framework Navigation Cube from menu bar
Figure 12 - 50 - The FFLV Framework Navigation Cube with side menus
Figure 12 - 51 – The basic EA navigation screen
Figure 12 - 52 - FFLV Framework mapping to Zachman
Figure 12 - 53 - A comparison between DODAF and FFLV
Figure 13 - 54 - Business Drivers and IT priorities in summary
Figure 13 - 55 – Developments at IT Application layer
Figure 1356 – Initiatives at IT Infrastructure layer
Figure 13 - 57 - Solution Architectures in the EA context
Figure 13 - 58 - The Solution Architecture component views
Figure 13 - 59 - EA layers as the overlay of all Solution Architecture Views
Figure 13 - 60 - Alignment of EA to Solution Architectures projects
Figure 13 - 61 – An Applications Inventory basic table
Figure 13 - 62 – Applications Integration table
Figure 14 - 63 – The As-Is Single Page EA of an Enterprise
Figure 14 - 64 – The SOA design solution for the target EA
Figure 15 - 65 - The Enterprise strategy specification process
Figure 15 - 66 - Strategy specified to benefit every Stakeholder
Figure 15 - 67 - Balance strategies against stakeholders' needs
Figure 15 - 68 - Strategy cascade to Function, Process, Technology & People
Figure 15 - 69 - The Enterprise Transformation Roadmap process
Figure 15 - 70 - The Strategy execution roadmap
Figure 15 - 71 - A Strategy mapping on an Applications Architecture
Figure 1772 - The EA metamodel diagrams, layers. entity relationships
Figure 17 - 73 - Context Diagram, Stakeholders' Interactions
Figure 17 - 74 - Stakeholders' requirements from Architecture
Figure 17 - 75 - Specify the Business Functions Map
Figure 17 - 76 - Specify the Product delivery Flow over Functions
Figure 17 - 77 - The Single Page Architecture, key Functions and
connections
Figure 17 - 78 - Map IT Applications
Figure 17 - 79 - The EA Infrastructure View, servers and storage
Figure 17 - 80 - Information View, structured around Operations Functions
Figure 17 - 81 - The EA Organizational View mapped to business Functions
Figure 17 - 82 - All Business, People & Technology Views
Figure 1883 - A sample customer's interaction navigation scenario
Figure 19 - 84 - EA governance
Figure 1985 - The EA program organization
Figure 19 - 86 - EA site organization
Figure 19 - 87 - The growth in jobs of EA architect
Figure 22 - 88 - The Virtual SOA Enterprise
Figure 22 - 89 - The IT Virtualisation, Outsourcing and EA layers
Figure 23 - 90 - Strategy Execution & the Enterprise Transformation plan

Chapter 1

1. About the book

Why this book

The book aims to answer some of the common sense business questions
related to Enterprise Architecture. It attempts to solve the problem of why, what
is, and how to build an Enterprise Architecture (EA). What are the issues? What
is Enterprise Architecture? Why should an organization consider Enterprise
Architecture? What are the trends and drivers of business change? What would
be the benefits and the costs? What is the Return on Enterprise Architecture,
Payback or NPV? Which are the factors inhibiting EA initiatives? And how to
build the EA; good practices in the development of an Enterprise Architecture
are discussed. Most of all, the book attempts to draw the Enterprise picture from
business, technology and organization perspectives.
The book describes:
• The Enterprise problems and the Enterprise Architecture (EA)
solution
• The drivers and benefits of EA
• How to build a business case for an EA; introduces the formula for
the Return on Enterprise Architecture (RoEA ) and calculates the
Payback and NPV financial indicators, newly applied for an Enterprise
Architecture development
• A Single page logical Architecture to satisfy and provide the
communications means and common vocabulary to all stakeholders
• A Business Reference Map or a Business Template to help you
structure the Enterprise Architecture according to commonly accepted
patterns such as Value Chains in business, and in IT, multi tier client
server architectures
• An innovative EA framework, not only showing compatibility with
major existing frameworks, but exhibiting a unifying view of People,
Process and Technology architectures, linked together and described by
views specific to each and every stakeholder, designed from an UML
perspective and described in terms of Functions (what) and Processes
(how)
• A metamodel describing the links between artifacts and their entities
and schema of the EA tool repository
• A coherent view of many related Enterprise technologies: Business
Process Management (BPM ), Enterprise Application Integration (EAI
), Service Oriented Architecture (SOA ), Enterprise Resource Planning
(ERP ), Software as a Service (SaaS )…
• Mapping to other frameworks (Zachman , DoDAF , TOGAF, FEA ),
• EA maturity models, triggers and inhibitors, EA politics, Enterprise
Architect’s role and responsibilities
• A Strategic Planning process driving the Enterprise Architecture
transformation
• The EA development process describing EA governance and Best
Practices at every step
• Integration of Solution Architecture designs, result of the everyday
projects, into the Enterprise Architecture outcomes
• The Virtual Enterprise concept, the Enterprise entirely built of
outsourced functions, except Governance
The book is not only an attempt to solve the Shakespearian dilemma of the
Enterprise Architecture: “To Be or Not To Be”, but it is also a try to unify the
many aspects of an Enterprise Architecture: is it an IT only application
integration program? Is it a rather typical organization alignment to business
objectives? Or is it a Business Process Management (BPM ) development? Is it
a program, a document, a process or organizational issue?
All are parts of the same answer: the Enterprise Architecture (EA) is the
structure of the Enterprise, its business processes, its IT applications, technology,
its people and organization all performing as a single entity, the Enterprise. But
EA is more: it is about financial performance, compliance, business continuity,
the real estate, fleet… And EA is more than the sum of its parts.

Outline
The Enterprise Architecture (EA) is the structure and the operational
blueprint of your company, showing its organizational and technology resources.
The EA ultimately becomes the knowledge DB of your Enterprise.
EA is a necessary "evil". Any system needs a blueprint to enable proper
operation, maintenance and planning. Look at the blueprint of a car describing
its components, interconnections and all key systems: electrical, fuel, engine...
EA does the same thing for your Enterprise; it also covers development and
support functions.

The EA is commended because of the state of high entropy of the Enterprise,

soaring complexity, poor availability and understanding, induced by years of
patching, point solutions, silo operation, organic growth, mergers, outsourcing
and an increasing divide between business and IT.
Businesses need to change and compete faster and faster, while IT can no
longer cope with mending the legacy of the past. EA unwires the architecture
“hair ball” and integrates technology generations from various eras, including
the mainframes, the dinosaurs of IT.

From an EA viewpoint, the Enterprise is seen here as a blackbox, a cube,

with interactions to external entities or stakeholders. Inside the box there is
everything that belongs or happens in an Enterprise:
• Business
o Activities (processes) such as Marketing and Planning, Make Products
and Delivery, Sales and Service, Development and Support (payroll,
recruiting, planning…)
o Information on customers, products, suppliers, investors, financials,
objectives, strategy, business plans…
• Resources performing the activities
o Technology – IT, production bands, SCADA, networks, assets (real
estate, equipment, fleet…)
o People – organization, culture
o Financial
The EA is described top down beginning with the stakeholders interactions,
processes that support them and the resources– people and technology -
performing the processes and acting on information.

Figure 1– 1 - The Enterprise Black Box
By looking critically at the Enterprise, an EA development aims to document
it, optimize it, align its resources to programs delivering business objectives,
increase its agility to change, reduce time to market and prepare it for
consolidation and outsourcing. We realize this by documenting the current
Enterprise and devising the desired future state; then, through a transformation
program of simplification and re - engineering, we streamline the Enterprise to
last and implement the target Enterprise in line with business strategy and
objectives.

EA delivers:

• Streamlining (simplification of the enterprise unnecessary
complexity)
• Alignment (of Technology and Organization to Business Processes)
• Agility (assembled of technology independent, modular services)
• Strategic Planning (mapping of Business Strategy to technology
roadmaps)
and consists of
• a set of blueprints for the Current, Transition and Target Enterprise
states
• the governance and delivery process
• the business, organization and technology transition roadmaps
• the EA program allocating EA implementation resources
• and not least. an EA framework, method, best practices and
principles
The Enterprise Architecture is described by a few layers adopted by most
existing EA frameworks: Business, Application, Information and Technology
(frequently limited to IT technology though).

Nevertheless, the modeling of an Enterprise, unlike that of other systems, is

based on the fact that people, organization and its governance are major factors.
Thus, people (and organization) become an integral part of the EA framework
since no Enterprise operates without people; humans are executing processes,
are operating and maintaining technology and organizing and governing the
Enterprise. After all, the company is the people. And technology is not solely IT.
A Business Reference Map (or Model) (BRM) is supplied to ease the first
steps of mapping the Enterprise, describing an Enterprise generic structure. This
map is the result of experience, like most of the book. The Enterprise
Architecture existing body of knowledge is still immature.

The BRM is in reality a business design template. It is structured in four

ubiquitous domains: Governance, Operations, Development and Support, i.e.
GODS - concept introduced in this book -, under which the business functions,
the logical entities of an Enterprise, are aligned. The GDS functions map to
[i]
Porter's Value Chain (VC) secondary functions while Operations (O) to the
primary one, being further partitioned in Marketing and Planning, Operations
and Delivery and Sales and Service Value Chains. The BRM model is a new
concept developed during the EA practice. Nevertheless, for similar work in this
[ii]
field please consult the Value Reference Model of the Value Chain Group
[iii]
and the SCOR process reference model of the Supply Chain organization.
IT people usually divide the architecture in Presentation, Business Logic and
Data Services, since the dawn of software development, to which one might add
a layer of interaction with partners and suppliers (B2B) and a common layer for
utility like common services such as User Identification, Content Management,
Request Routing, and Portal aggregation services. In the BRM, the customer
access is placed at the top of the Operations function to enable interaction at all
times during marketing, delivery, sales and service.

An Enterprise may be then logically decomposed in a tree called a Business

Functions Map/Tree. The functional architecture describes the Enterprise flows
(workflows) as a sequence of processes in business functions. It is usually
represented as swimlane or sequence chart diagrams. As a logical view, it serves
as the baseline for the design of the current and target EA architecture.
The Business Functions Map, while specific to a company, it is based on the
generic Business Reference Model, valid for any Enterprise. An Enterprise is
modeled both as a hierarchy of business functions (Business Functions Map) and
flows (Business Flows Map). Any business function can be described, like the
whole Enterprise, in terms of a minimum set of views.

Figure 1 - 2 - The EA framework key views, BRM and Single Page EA
The key Enterprise layers and views in the picture show stakeholders'
interactions, the business functions hierarchy, business flows, the technology (IT
applications, infrastructure) and the organizational resources supporting the
business processes. Layers are composed of many other (sub-) views that,
describe in more detail specific functionality.
The business function is the glue of the EA by enabling grouping of
Processes and the Technology and/or People resources executing them in
functions, thus correlating the three layers of the EA, business, technology and
people.
A note: for the scope of this book, business functions and flows/processes,
are similar in meaning (both are process groups) except that functions consist of
related processes (serving the same stakeholder for instance) while flows consist
of sequences of processes. Functions and flows are two ways to categorize the
same processes. A process is part of both a flow and a function. A flow consists
of a sequence of processes belonging to more functions.

A business process belonging to a function is executed by people and/or

technology resources. The resource layers describe applications, infrastructure
and organizational resources executing the processes.
A graphical EA framework representation (like in the picture) emphasizes at
a glance, the relationship between the EA business view and the resource layers,
people and technology. The GUI represents an entry point in the EA enabling
the navigation amongst framework entities (and artifacts) of the Enterprise tree.
Architectural views, the stakeholders' filters, capture aspects of an Enterprise
layer or, on an Enterprise wide basis, capture specific stakeholders' concerns
crossing all layers, such as document management, financials, compliance,
community functions, real estate etc. The EA framework is open to any number
of stakeholders' views (perspectives, filters) that can be added at later times, as
for instance email, reporting, fleet or parking architectures. An EA view (filter)
can be associated for instance, to every solution and capability. In truth, most
representations are views since it is impossible to show in detail all aspects of
interest to stakeholders on a single diagram.

The EA Framework proposed employs a Model Driven Architecture (MDA)

like paradigm by initiating the design of the functional architecture top-down,
starting from the Business Reference Model customized for the industry and
company, branching down to the whole Enterprise decomposition tree.
The proposed EA framework can be mapped on major existing approaches
(Zachman, DoDAF, TOGAF, …) so that you should not be concerned with
compatibility. Nevertheless, in addition it offers navigation between layers and
views due to the all views crossing nature of the business functions. The EA
metamodel also describes in a DB schema the navigable relationships between
the objects in layers.
A Business Flows Reference Map guides the Enterprise Architect in the
discovery of the end to end flows over functions as swimlane or sequence
diagrams.
Basic Flows:
o From Suspect to Prospect to Customer
o Service Delivery
o From Order to Invoice to Cash (Customer)
o From Call to Service
o From Financing to Payback
o From Hire to Retire
o From Order to Payment (Supplier)
o From Market Research to Segmentation and product Concept
o From Concept to Product
o From Vision to Strategy
o From Forecast to Plan
o From Compliance to Audit
o From Budgeting to Accounting to Reporting
o Make to Order: from Sourcing to Distribution
o From Discovery to Sale
o From Return to Repair
At the same time, processes in flows support the business functions map
definition. Some flows are internal while some are external serving the
stakeholders. This is a complementary view to the Business Functions Map. The
Business Flows Reference Map is introduced to guide the effort of business
process design. There are isolated efforts in the business domain to standardize
this area with no agreed outcome.

As Zachman was quoted to say: "when you need it you would better look at a
diagram artifact than a document because there is no time for reading them." The
Single Page (logical) architecture is that diagram that facilitates stakeholders'
communication. It consists of a single diagram showing the key business
functions and their interconnections, like an electronic circuit diagram showing
links rather than all the signal flows passing through them. It is often reduced to
the operational aspect of the Enterprise.

Figure 1 - 3 - The Enterprise synoptic picture
A metamodel extends the theoretical framework into the realm of practice
and tools since, in effect it describes the types of diagrams and the relationships
between entities so that the stakeholders can understand what specific object in
the repository is exchanged or mapped between layers. The metamodel
constitutes in fact the DB schema of the Enterprise Architecture framework
repository.

Overall the EA development process consists of:

A. The capture of business information, such as strategy, objectives,
business model, current roadmapping, planning and stakeholders'
requirements
B. Specification of the EA framework,: business functions
architecture, business flows, resource layers views (People and
Technology), architecture and technology transformation principles ,
Best Practices and deliveries check lists
C. Current architecture discovery for documenting today’s Enterprise
workings
D. Target Enterprise State sketch
E. Current/Target gap analysis , transition milestones and migration
planning
F. Enterprise design-plan-transform iterations
The process of building the Enterprise Architecture is iterative, going into
further depths and new entities and views as the EA is conquered.

The business case for EA proposed in the book and its associated formula
were validated in a telecom operator services architecture environment, with
credible results. Since, in practice, very few project business cases are verified
after the fact, I also proposed a table of key benefits indicators to measure the
EA value returns after the implementation of an iteration.
The every day life solution delivery projects are integrated to the EA since
the solution architecture recommended design has the same components as the
EA directly updating it as such.
In practice, many attempts at developing the EA have ignored the people and
organization or have been limited to just aspects of an EA: IT architecture, SOA,
or business process engineering. Seldom a practical Enterprise Architecture
development covers all layers and views. I have not had the chance to be part of
such a complete EA development to be able to describe a full Case Study. As
such, an abstract EA design exercise is included, as a virtual case study to
illustrate the usage of the EA framework, the development process and Best
practices.
The book does not discuss EA tools although a tool set is recommended to
provide a common Enterprise objects repository and facilitate effortless
navigation between the EA entities and artifacts as described in the metamodel
schema, starting from a graphical representation of the EA framework.

The book also discusses many other EA issues from EA maturity, roadblocks
and politics, the role of the Enterprise Architect and how to select one, the
virtualization of the Enterprise to the EA future outlook..
Terms like: firm/company/Enterprise, data/information, current/As-Is,
target/To-Be, migration/transition/transformation are used somewhat
alternatively. As a guidance, the term "information" is used in the context of
business architecture while "data" in the applications domain. Throughout the
text, where thought necessary to distinguish an EA framework entity term from
the common usage of the word, the first letter of the term is capitalized.

The book is meant to be a practical guide for such a challenging

development. It is presented in a concise format to make possible its everyday
consultation during the EA development effort, in a similar fashion to an
engineering handbook.
I would like to draw attention to the fact that the book does not describe
every framework, technology or method mentioned in the book since this will
change the nature of the book, which is to be a development guide rather than a
compendium. Also it does not contain a bibliography or mentions numerous
references since I have not found many relevant to this work. Nonetheless,
nowadays it is easy to find information on the Web about all topics referred to.

This is not, by any means, the end of this work. In fact, for some time this
has been work in progress, since most of the content is still evolving, much like
the Enterprise Architecture discipline itself is.

Audience
The book, at least chapters of it, are suitable for a wide range of audiences
from CEOs to employees, EA architects, consultants and business analysts alike,
as it presents the blueprint of the Enterprise and its workings. The book eases
Enterprise comprehension, enabling the audience to understand, from the
architecture, their work in the context of the whole.
Generally, the book is aimed at all people responsible for building and
implementing an Enterprise Architecture, since it provides definitions, method,
a framework, business reference model, guidance for strategy design and
mapping as well as some of the Best Practices for building an Enterprise
Architecture.

By defining the EA, the book enables:

• Enterprises to initiate the development of EA and SOA enabling the
transformation of the Enterprise armed with a business case, best
practices, a business reference map, a development framework and best
practices
• CEOs, in general top management, to align the organization and its
resources to its business mission and vision, streamline the Enterprise to
achieve agility and cost efficiency and facilitate Mergers & Acquisitions
and outsourcing
• CTOs and Line-Of-Business executives to align technology
investment to business strategy and stakeholders' SLAs to operational
flows
• CIO and Chief IT Architects to transform business strategy into IT
programs and technology roadmaps, integrate Enterprise applications,
simplify infrastructure, optimize IT governance, implement SOA, and
ultimately, improve the return on IT
• Business and Technology Strategists to build a strategy put into
action by and traceable to the Enterprise functions, processes,
departments and IT
• Business people and management consultancies by providing them
with a common vocabulary, a business reference map and views of
specific business interest
• IT Solution Architects, Software Architects, Program Managers and
Quality Engineers for providing IT architecture guidelines and standards,
a common Framework, methodology, metamodel and facilitating an
Enterprise wide Project Portfolio approach, taking into account all their
concerns
• Shareholders and other stakeholders, to understand how the
Enterprise returns value to them by looking at the business architecture
and measuring investment returns in the EA context
• Regulatory bodies, to position compliance (SOX, Basel II, …) in the
context of EA business flows, technology and people architecture.
There is no prior knowledge one has to have to understand the book. Yet, an
awareness of business concepts such as Value Chain, Business Model, Strategy,
Business Process Management as well as IT experience, SOA and UML
modeling will aid this reading. The book should be taken as an Engineering
design manual, consulted when need arises, rather than a weekend read since it
contains a large amount of information.

Review checklist

1. What are the main business views describing the Enterprise?
2. What is the difference between, business processes, functions and
flows?
3. How do you use a Business Reference Map?
4. Tell the difference between a Business Function Map and a Flows
Map
5. What is a Single Page Architecture?
6. What are the EA benefits?
7. Enumerate key EA components.
8. Describe the most important steps of the EA development process.
9. What are the benefits for the CXO management

Chapter 2

2. EA provides a competitive edge to the

Enterprise

Due to the growing complexity of technology, the daily increase in the
amount of information and the ever fastening pace of change and competition,
the very existence of many Enterprises will be challenged in the next few years.
Ray Kurzweil states that every ten years the rate of change doubles; in the next
hundred years we may experience the same amount of change as in the past
[iv]
20,000 years .
Historically, companies built products, deployed services and structured the
organization rapidly in response to market demand and new regulations. This
was achieved through point solutions, patching and silo organizations, all at the
expense of an increasing complexity of a “spaghetti” like architecture, fostering
duplication in functions, data, platforms, processes and projects. The
unnecessary complexity slows down business change, the decision making
process and fosters longer time to market which ultimately increases the costs of
operations.
At today’s pace of change, to conquer the soaring complexity, to deliver
faster and better and be sustainable the Enterprise has to be:
A. Streamlined: simplified to minimize unjustified variety, reduce
unnecessary complexity, remove silos and improve focus

B. Aligned: technology (IT) and people (organization) resources
aligned to business processes and strategy to achieve the firm objectives
C. Agile: modular, layered, standardized, technology independent, built
out of services, quickly to adapt to change
D. Built to last: strategically planned according to business and
technology trends and vision
E. Documented: a blueprint to document the current and target
architecture to enhance comprehension and management of its
performance.
To repair a car, the mechanic has to know its blueprint and, based on it, its
operation. To design a car or improve it the firm needs to understand where
technologies and markets go. The mechanic has to become a planner, a
marketing man, a business man. Same with the Enterprise Architect.

An EA will integrate in a single effort many fragmented or loose coupled

Enterprise developments such as SOA, IT Architecture, Application Integration
(EAI), ITIL efforts and many independently performed activities such as
Enterprise alignment to Business Strategy and Objectives, Enterprise
Simplification, Compliance to Regulation Frameworks, Business Process
Improvement, Six/Lean Sigma, Business Performance Management, Mergers
and Acquisitions, Integration and outsourcing (such as BPO, SaaS…).
What will be the role of the Enterprise Architecture (EA) in the Enterprise
evolution in the decade to come? How can an Enterprise operate in a predictable
manner, change fast enough to lead or at least swiftly follow the market and
offer high quality products at the same time, without the modular structure and
blueprint of an Enterprise Architecture?
For the next decade, there is little chance for a legacy Enterprise to survive
the accelerating change, the ever reducing time to market, increasing customer
expectations, the industry consolidation and outsourcing trends without a clean,
streamlined, optimized and documented operation.

The EA is an asset which, once in place and properly maintained, will return
value for many years (RoEA) since the investment in EA can be leveraged over
and over again to pay back dividends. EA is the knowledge database of your
Enterprise.
The EA asset promises you a Competitive Advantage by streamlining your
Enterprise, enabling faster product delivery at lower costs, handling the
exploding amount of information and providing greater Enterprise agility to cope
with change.

Conservative quotes from different industries vary between 10-30%

reduction in cost and time to market due to EA.
The hypothesis and conclusion of the book is that the EA will offer the
Enterprise the edge needed in the survival race through blueprinting,
streamlining, roadmapping and agility.
The US now requires government departments to provide their Enterprise
Architecture to justify investments. Your shareholders will demand the EA soon
in order to increase the guarantees of their return of investment.

Review checklist

10. What is the hypothesis of the book? What do we want to prove?

11. What are key benefits of the EA?
12. What developments does EA integrate in a single effort?
13. Why is the EA indispensable to the Enterprise for the decade to
come?

Chapter 3


The Problem
Remember how many times you have spoken to a large organization
providing you a service, only to discover that they still have your previous
address, where some of their correspondence is still sent, as well as having your
current address. This is because for each service there is a platform which retains
your personal data. A change in address often has to be operated in many
platforms, at the same time, and sometimes manually, which is slow and error
prone. In fact, duplicated data is created for each platform.
On occasion, as a customer, you need to identify yourself several times to get
a service from a company. This is because each service owns its data and
requires its own authorization since there is no cross platform authentication and
authorization service.

The current state of the Enterprise as seen by Zachman : “Enterprises have a

large inventory of current systems built out-of-context, not integrated, not
supporting the Enterprise, that are consuming enormous amounts of resources
for maintenance and are far too costly to replace; as a matter of fact, the
[v]
inventory of existing systems has come to be referred to as ‘the legacy’” .

Enterprises met many challenges in arriving at their current structure. Many
have been through a rapid customer growth and technology changes which
fuelled an organic growth, based often on one-off, point solutions. Shortening
timelines for new products, and immediate priorities to minimize CAPEX and
OPEX , resulted in a silo culture where, quite often, each part of an organization
cares only for its own products, budgets, applications and technology. The
Enterprise, as a result, is made of patched legacy with multiple and various
solutions for same or similar capabilities.

The current state of the Enterprise requires simplification since it has grown
complex, after many mergers and acquisitions. The complexity makes
applications patching impossible. Adding new point solutions, re-using little
from the existing capabilities, can only make things worse. Can we call this
Enterprise manageable, predictably delivering quality to customers and value to
shareholders? And the cost of running this Enterprise is growing higher and
higher with the level of complexity increased by mergers, point solutions and
patching.
The divide between business and IT departments is frequently deep since
there is no common vocabulary, skills to facilitate communication and shared
objectives to align efforts. Business understands processes, rules, markets and
products. IT people specialize in IT support, maintenance, helpdesk and software
development.
Usually, business inflexibility is associated either with the IT or with the
organization which is changed ever so often. It does not matter how much
emphasis is set on the Customers' needs, if the products themselves and the
operational processes deliver at low quality. This, ultimately, hinders the efforts
made by the customer facing units. And the faulty products are the result of
faulty processes which require business process improvement using Six/Lean
Sigma and BPMS etc.
Currently, in an Enterprise, there are so many plans, designs and
architectures. Everybody has a drawing: the Supply Chain, the Customer
Services department or IT. They do not look alike, they have different
vocabularies, entities, conventions and levels of detail, they are drawn with
various tools as Word, Visio, Power Point… and they sit everywhere and
nowhere when you need them. What do we do? We call a meeting with all
domain experts to make a decision. And we just pick their minds during a
brainstorm. It's like the architecture is floating in the air, above the expert
audience where nobody can see it. And we are not even sure that we are talking
about the same thing.
By the way, where is the Business Architecture blueprint to be used by IT
to align Technology Architecture to business processes? Unfortunately, no
Enterprise has been built according to a blueprint, at best it was re-engineered.
But we solely let IT provide the Enterprise Architecture.
To our relief, the ERP application suites are saving the Enterprise by
providing both the business processes and application layers of the Enterprise.
More often than not, this comes at the price of inflexibility, poor integration,
high cost, dependency on one vendor and poor comprehension of the underlying
functionality. EA is more than an ERP.

Every Enterprise has a structure, an architecture, and it works, more or less.

The structure is often the result of an organic growth and not the outcome of a
deliberate process. Without the synoptic view of an EA, the Enterprise is marred
by duplication in platforms, projects, roles, data, applications and even products.
Quite often, units of the same company compete with each other and do not
share good practices, processes, applications and strategies.
From a business perspective, the Enterprise problem is the inflexibility, slow
change and high costs of IT. From an IT perspective, it is the lack of business
process and requirements clarity, inherited obsolete technologies and the tangled
IT spaghetti architecture.

The Problem: the silo organization, the point solutions duplicating

functionality, the unnecessary complexity and the poor understanding of the
Enterprise operation, causing a lengthening of the decision making; not able to
implement, quickly enough, the change required by business.

The problem lies with the today's unresponding and undocumented

Enterprise in a world of growing complexity and change.

Business Trends
The next decade is characterized by an ever increasing trend in speed of
change, complexity, amount of information and customer expectations, reducing
product life cycles and industry consolidation.
Often, an Enterprise needs to enter a new line of business or to enhance its
product portfolio by acquiring or merging with another company rather than
taking the time and absorbing the cost to produce the product in house. Mergers
and acquisitions happen so often now because, before an Enterprise can acquire
the skill and deliver the product, the window of market opportunity is lost. The
new company has to be aligned to the Enterprise. But because companies have
overlaps in products and functions, and exceedingly different applications to
implement similar processes, a merger may simply fail to bring benefits since
there is no common blueprint of operation to deliver a single service proposition
to customers and cost reduction, from economies of scale, to owners. On the
other hand, the opposite result could occur; customers are confused by offers of
similar but slightly different products and technologies, employee’s motivation
may suffer from internal competition and potential redundancies and the share
price may drop until the confidence is restored, that is, when the new products
are integrated and the Enterprise is streamlined again. But there are numerous
issues with acquisitions, for instance alignment of organizations, IT
infrastructure, applications and in general Customer Relationship, Supply Chain
and all the Enterprise Support functions. Not to mention different strategies,
cultures and values.
It is hard to understand how it is done without a common blueprint, provided
by the EA. The current best practice is to align the organizations' charts.
Outsourcing and managed services are also one of the strongest trends in any
industry now. They are essentially about work division. Nowadays we can do
very few things well, at the level of quality expected by customers. Companies
outsource functions which do not align to the perceived core business activities.
Interestingly although companies pretend, more and more, to be customer
oriented, they outsource Customer Care functions such as Call Centers. But what
functions in the Enterprise should we outsource? Should we outsource
operations? It happens, often off-shored. Before making the decision you need
to determine in detail the services to be provided to your Enterprise and their
present Total Cost of Ownership (TCO). Is there a context, a blueprint to help us
make our outsourcing decisions?

Can the Enterprise be certified against quality frameworks (CMM, Six
Sigma)? This may be a trigger for initiating an EA program, besides acquisitions
and outsourcing as these maturity and quality frameworks require business
process optimization.
Six Sigma, Capability Maturity Model (CMM) and recent regulations and
auditing procedures as Sarbanes-Oxley, Basel II … demand a structured, well
understood, managed business process architecture, data architecture, security
and privacy controls, accompanied by proper document and financial
management systems, all in the scope of an Enterprise Architecture. The
business process and information flows modeling offer a framework for auditing
and compliance to regulatory requirements like Sarbanes-Oxley.

There are numerous external and internal forces that lead towards the
development of an Enterprise Architecture:
• Business management need for direct control of change of the
Enterprise, IT and investment process; for a long time now, business
users have struggled to obtain the IT support they need to deliver process
change for flexibility
• The need for Enterprise simplification and integration of point
solutions and silo organizations due to the current state of organic
growth and patching
• Increasing customer demand and expectations for quality, growing
raw material and energy prices forcing companies to deliver new levels
of scalability, quality, cost efficiency and performance
• Rising worldwide business competition manifesting in
o Rapidly reducing lifecycles/Time to Market
o Increasing consolidation trend through mergers and acquisitions as the
cost of developing new products in house is growing
o Rising trend for outsourcing of Business Process (BPO) , applications
(SaaS), data centers and managed services
o increasing request for modular, service based business architecture
(SOA) and growing popularity for web services to increase business
agility
• Drive for quality frameworks (Six Sigma, CMM) and new regulatory
compliance (SOX, Basel II, HIPAA…) demanding documented and
auditable structures and processes
• EA, becoming a regulatory requirement in the US: the Clinger-Cohen
Act of 1996 for Federal Agencies mandates the EA.

Business needs
Of course, a business has to return value to all its stakeholders: owners,
employees, community... But what are the main categories of issues a business
always has to have in perspective, what are the business needs in this day and
age?
• Differentiate products for customers' benefit, and establish business
models to create a continuous competitive advantage to increase profit
for your shareholders/owners (Financial view).
• Increase agility to be able to respond quickly enough to market
changes (Operational view)
• Streamline and architect current Operations to enhance effectiveness
and reduce costs (Operational view)
• Automate as much as possible, reduce redundancies in functions,
processes, platforms and projects, reduce the tangled architecture,
document current business functionality and implementation to get in
control of your business.
• Build the Enterprise to last (Strategic view)
• Analyze trends (industry, economical, social, political and regulatory,
technological) and plan your strategy and business models accordingly
(market segments, products, costs, new technology capabilities).
• Improve Corporate Social Responsibility (Community and
Regulatory view)

What business constantly requires from IT
• Technology alignment to business and strategy intentions
• Customer self service
• Customer/Employee/Partner Reduced/Single (Reduced) Sign On
• “Single Customer View:” a real time operational response to
customer data request to return all personal data, subscription,
interaction history… ,

• “Single Version of Truth”: only one source of data for reporting,
Business Intelligence and ultimately decision making
• Straight Through Processing: process automation, document imaging
and character recognition to reduce human error and processing time
• Agility to change, access security, data privacy…
• Reduce IT costs and investment

What the Government sector expects from IT
In short, a collection of issues the government agencies are confronted with
at this stage in time:
• Joined-up government, inter-working & information sharing between
departments
• Common services and infrastructure across government
• Government portal and intranet, authentication/authorization/Id Mng
service …
• Information systems to respond faster to business change
• Efficiency & customer focus through business process re-engineering
• Electronic delivery of services, E-business to business
• Usage of communication and cooperation technologies such as Web2
(2 way Web)
As such, the Government demands a streamlined operation with reduced
duplication and improved processes, common inter-departmental shared
resources, cross boundary services and electronic services delivered over the
Internet, using the latest Web2.0 communication technologies.

Ultimately, the book intends to prove that the Enterprise problems and
trends can all be acted upon in coordination in an Enterprise Architecture to
defeat the increasingly threatening enemies of the Enterprise: growing
competition, rate of change, complexity and ultimately the increasing entropy of
the Enterprise.

Review checklist

14. Which are the key issues with the Enterprise today? What is the
"problem"?
15. State a few important business trends.
16. Describe the main business drivers and the business requirements
from IT.
17. What are the Government drivers?

Chapter 4


Enterprises have organically grown into systems, sometimes reminding us of
jigsaw puzzles, the result of years of patching and point solutions. Sometimes
one feels the desire to scrap everything and start from scratch. But then again,
the situation repeats itself.

But how can you control your Enterprise without a plan?

How can the Enterprise operate in a reliable, predictable, and planned
manner?
How can you prepare it to change quickly enough to respond to risks, threats
and opportunities?
How do you reconcile the business imperatives and IT interests in the
Enterprise?

EA, the Solution to the Enterprise Problem
If organizations are to become more agile and effective at leveraging their
technology investments and managing their own processes, they must develop
and maintain an Enterprise blueprint first.
It is not rare that the Enterprise blueprint is little known, not documented but
partially, inconsistently, with different tools and various aims in mind, by many
groups. The Enterprise management team looks at a jigsaw puzzle, without the
benefit of the assembly picture. In fact, there was never a complete Enterprise
picture. It is high time to provide the Enterprise Architecture, the picture of the
Enterprise jigsaw puzzle.

Figure 44 - EA, the Solution to the Enterprise Problem

What is Enterprise Architecture (EA)
An Enterprise is a group of people that organize to deliver products or
services to customers and return value to stakeholders, using technology.
Conventionally, the main activities of an Enterprise are product
manufacturing, inbound and outbound distribution logistics, sales and services
and support functions such as Human Resources, technology maintenance,
procurement, financing, and planning.
EA is the Enterprise picture, the shared blueprint over which, business and
IT people address their concerns in a common vocabulary. EA patches the divide
between business and IT.
EA enables the alignment of technology - IT applications/infrastructure and
non IT - to business requirements, strategy, objectives and processes. It also
lines up people, organizational roles and responsibilities against business
processes and technology.
In an Enterprise there are many architecture artifacts in different domains,
produced with various intentions and tools. An Enterprise Architecture is in fact
a complete and integrated set of such artifacts designed consistently with same
conventions and tools and covering the whole Enterprise operation.

EA definition s
According to IEEE, the architecture is:
“The fundamental organization of a system, embodied in its components,

their relationships to each other and to the environment; the principles
governing its design and evolution.
The formal description of the system e.g. the detailed plan at component
[vi]
level to guide its implementation” .

Architecture identifies the main components of an organization and the ways

in which these components work together to deliver the products. I sample a few
Enterprise Architecture definitions, from a variety of web sources:
"An enterprise architecture is a blueprint for organizational change defined
in models [using words, graphics, and other depictions] that describe (in both
business and technology terms) how the entity operates today and how it intends
to operate in the future; it also includes a plan for transitioning to this future
[vii]
state."
“An enterprise architecture (EA) is a conceptual blueprint that defines the
structure and operation of an organization. The intent of an enterprise
architecture is to determine how an organization can most effectively achieve its
[viii]
current and future objectives".
"An EA defines the components or building blocks that make up the
Enterprise, their interrelationships and guidelines governing their design and
[ix]
evolution” .
“The enterprise architecture is the organizing logic for business processes
and IT infrastructure, reflecting the integration and standardization
requirements of the company's operating model… It provides a long-term view
of a company's processes, systems, and technologies so that individual projects
[x]
can build capabilities - not just fulfill immediate needs.”
The Enterprise Architecture is frequently described by a few common
denominator layers: business, information, applications and infrastructure. The
Business layer maps over applications which lie on top of the
Infrastructure layer, composed of the hardware and software components hosting
the applications. The Business layer is composed of business processes and
information. Collectively, applications and infrastructure can be grouped in a
Technology layer. Typically, technology refers to Information Technology (IT).

Information is not categorized as a single layer in this book, since it spans all
others: business, applications and infrastructure. Information, as a term, is
predominantly used at the business layer while “data” at the IT applications
layer. As a consequence, the information architecture is seen as a composite
view sine information exists at all layers. In a similar manner to processes,
information at the business layer maps on the technology application layer as
data.
A key EA layer, often not included in frameworks but considered in this
work, is the people and organization layer. People, like applications and
machines execute the activities in processes and are a main factor in
productivity, since most processes are not automated. And Human
Performance is increasingly seen as a key factor in the Enterprise optimal
operation. As such business objectives are often cascaded to departments and
further down to individuals and their job descriptions.

A note: Enterprise Architecture is much too often associated to solely an

Enterprise wide IT architecture perhaps because it is initiated by IT or because
of the “Enterprise” name of such technologies as Enterprise
Application Integration (EAI), Enterprise Service Bus(ESB), (offering
integration of existing applications in the Enterprise, and Java EE – Java
Enterprise Edition –, supplying a container technology with the potential to host
any application in an Enterprise.
Change, growing at an exponential rate, becomes a constant in technology
and our society. As a result, the Enterprise target state changes continuously.
Hence, the EA is often associated to the on-going process of delivering the target
state of the Enterprise: “A logically consistent plan of activities and coordinated
projects that guide the progression of an organization’s applications systems and
infrastructure from its current state to a desired future state -- EA is a process not
[xi]
an end state.” This means that Enterprise Architecture gradually moves from
a program status to a Business As Usual (BAU) activity. The process of delivery
of an EA is iterative, cyclic, spirally converging towards the changing target
state of the Enterprise. The EA will deliver the basic views and as time
progresses, it will reveal the depths of your Enterprise, showing new functions,
workflows and views such as the file server, compliance architecture,
community projects, fleet, etc.

Own EA definition
The structure of an Enterprise and the blueprint describing its operation
consisting of an integrated, consistent and complete set of architecture
diagrams, describing the behavior and interaction of all business functions in
flows delivering the products to customers and value to stakeholders.
A definition may also be formulated by asking Zachman’s questions:
• What: EA is the structure and blueprint of an Enterprise describing
• How: its operation as the execution of flows over business functions
• Who: by the people (and technology) resources who execute the
flows
• Why: to deliver the mission and value to stakeholders
• Where: at various locations of the Enterprise
• When: according to roadmap and planning
And, in terms of EA development outcomes:

EA is the structure and blueprint of the Enterprise showing how it operates

by describing the current, transit and future Enterprise states in such artifacts as:
• Products and stakeholders’ interactions/Use Cases
• Enterprise Value Chains, Business and Operating Models
• Business Functions and Flows Architecture
• Information/Data Architecture
• Technology Architecture
• People Architecture/Organization
• Stakeholders’ views depicting aspects of the above architectures
• Enterprise Transformation roadmap according to business strategy,
architecture principles and technology standards and Enterprise Project
Portfolio Planning
• An implementation program with resources
By providing a complete picture of the Enterprise, the EA enables an
organization to:
• streamline the Enterprise by identifying and reducing the redundancy
in business functions, processes, data, technology, projects and
organizational units and roles
• align technology and people's jobs to business processes and strategy
• be agile, by enabling rapid business change through modular, service
based architecture (SOA)
• perform an informed decision making and investment process in the
context of the whole Enterprise blueprint
• do Enterprise strategic planning by lining up technology strategy and
organization evolution in a single Enterprise Project Portfolio delivering
the business vision.

Review checklist

18. Explain why the Enterprise looks like a puzzle?

19. Define the Enterprise.
20. Why is EA the solution to the Enterprise problem?
21. What is EA?
22. Describe the EA using the key "w" questions.
23. What are the main outcomes of an EA?

Chapter 5


Any CEO will name business growth, operational efficiency, strategic
direction, controlled risks, enterprise agility and regulatory compliance on the
short wish list. Enterprise Architecture supports the delivery of all these wishes
with superior resource and performance management.
Alignment to strategy, Business Process Management (BPM), automation
and improvement (Six/Lean Sigma), Service Oriented Architecture (SOA)
Enterprise Application Integration (EAI/ESB), outsourced services (BPO, SaaS),
are all praised independently for improving business efficiency and agility,
customer service and reducing the time to market. An Enterprise Architecture
then, based on all these, would multiply the advantages provided by each and
every development independently.

Governance Benefits (G)
The Architecture is the common blueprint which can be used to improve the
structure, governance and organization of the company, align roles and
responsibilities, projects to strategy, ease decision making and enable direction
and priority setting.

Enables Business Modeling
The common blueprint enables the impact analysis of potential business or
technology changes, by examining the impact on supporting information systems
and organization. EA makes possible the end to end product delivery
performance management. What if scenarios are easier to project against the EA
blueprint.

Improves Decision Making
Business decisions can be easily taken, considering the whole EA context
rather than projects and platforms in isolation. The Enterprise is seen and
understood in similar terms by all decision making fora. EA is employed as a
decision support tool.

Aligns Technology to Business Processes and Goals
An architecture, by definition, lines up the IT systems to business processes
and company goals delivering stakeholders' services.

Enables Agility , Faster Business Change
Companies are often slowed down in effecting change because of the
technology implementing business processes. In the EA case, the IT technology
affected by a business change will be quickly identified by navigation on the
blueprint. Implications would be straightforward to assess.

Enhances Project Planning and Prioritization Accuracy
Architecture ensures that projects are associated to EA components and
managed together as an Enterprise wide project portfolio. There are fewer delays
in the execution since there is clarity and synergies since projects are executed in
synchronization to supply Enterprise level rather than point solution
functionality.

Operational Benefits (O)
Enterprise Architecture drives improvements in maintainability, operability,
availability, scalability, extensibility and hence operational performance.
EA reduces the overall product development lifecycle as it provides
standardized component interfaces enabling quicker design and faster solution
selection, considerably shortening the entire time to market for new products.

Maximizes Reuse of Existing Assets
Reduces CAPEX investment through reuse. EA will identify redundancies
within business areas as well as in IT, providing significant cost savings over
time. Such redundancies exists at project, process, data, application, platform
and people levels. Organization’s existing investments in technology and
systems are leveraged rather than replaced.

Simplifies the Enterprise operation
through reduced number of parts, types, duplication and application of reuse.
Within a company, different departments may be developing products with
overlapping capabilities requiring similar expertise. Minimizing this duplication
and enforcing standardization will reduce costs.

Aligns Organization to Enterprise operation
The organization and people alignment to the EA functions and processes
will provide clarity of roles and a clear governance and as such, an effective
workforce, reduced costs and increased agility.

Improves Operating Procedures
by enabling repeatability, maintainability, availability, security and quality
control since EA requires modeling, documenting and improving the operating
procedures.

Enhances Enterprise Processes
EA requires business process documentation, re-engineering and
improvement to enhance use of resources, lower costs and reduce delivery cycles
at the same time. The highest Capability Maturity Model(CMM ) capabilities
levels can be achieved by documenting, measuring and optimizing Enterprise
processes.

Enables Activity Based Costing (ABC)
to measure the financial performance of the Enterprise, enabling
benchmarking and outsourcing. A cost can be evaluated for and attached to a
business function - the Total Cost of Ownership (TCO ) of the Technology and
the operating expenditure (OPEX ) in that function. Costs, attached to end to end
workflows could be used as KPIs for process efficiency improvement.

Permits Faster New Product introduction
Design is enhanced by the existence of standards, common horizontal
services and documented standard interfaces.

Exploits Synergies between similar operations of the Enterprise
A capability is designed once and deployed many times in a company with
multiple operational units. It reduces costs by eliminating duplication in
programs, functions and platforms in similar operational units.

Strategic Benefits (S)
by aligning technology and organization to business strategy. The high costs
of late implementation of various features and interfaces of a project could be
dramatically reduced by creating an Enterprise Architecture beforehand.

Maps Roadmaps to Architecture
Product roadmaps will align to EA processes, applications and technology
capabilities roadmaps in the EA transformation program.

Facilitates Vendor Products Roadmaps alignment to EA
The EA standards and roadmaps, communicated to strategic partners, will
enable rapid integration of vendor solutions with interfaces and capabilities
already supported by EA.

Provides Agility to business change
Offers a modular, service based, layered architecture based on SOA .

Enables Outsourcing and Mergers & Acquisitions
Due to globalization and increasing competitive pressure, companies are
looking, more and more, towards mergers and acquisitions. When two
organizations, with different management styles, internal processes and controls
attempt to merge they have to have a common Enterprise Architecture blueprint
in order to plan transformation and achieve synergies.

Improves Risk Management
Alternative strategies for risk management can be devised and mapped
against the EA blueprint and roadmap to evaluate probability and costs.

Communication, Collaboration and Compliance Benefits (C)
EA is a communication tool, enhancing comprehension, internal
collaboration and inter-working with partners. It supplies documented
stakeholder interaction scenarios, diagrams of components and interconnections,
a common component repository and data vocabulary. The EA is a Knowledge
DB of your Enterprise.

Improves Stakeholders ’ Understanding and Communication
EA enables employees and all stakeholders to understand how the
organization works, why and how decisions are taken, and what their role is in
the organization. Hence it reduces induction and training time and ultimately
staff churn.

Enhances Working with Suppliers and Partners
with standardized vocabulary, specifications and interfaces, all set out in the
architecture principles, transformation guidelines and roadmaps.

Makes Regulatory Compliance possible
Compliance controls/checkpoints, e.g. for SOX, may be implemented in
certain Enterprise financial processes, readily described by the EA diagrams. For
instance, an EA view may show business functions with their associated
financial accounts feeding into the General Ledger system. EA also enforces
clear responsibilities, transparency and audit capabilities required by regulatory
compliance.

Review checklist

24. What are the main type of benefits?

25. Describe a few operational and strategic benefits and explain why.
26. Why is regulatory compliance enabled by EA?
27. Can you see any other benefits? Please list them.

Chapter 6

6. The Business Case and Return on EA (RoEA

)

How do you ‘cost-justify’ Architecture

“Architecture is an asset. You invest in assets in order to enable you to do
something you otherwise are unable to do. Assets are reusable infrastructure.
What makes an asset any different than an expense (a consumable)? It depends
on how many times you want to use it. If you want to use it once, it is an
expense. If you want to use it more than once, it is an asset. Architecture is an
[xii]
asset, infrastructure, an investment, not an expense”.
ROI demands that the costs of an investment are returned in the context of
the same project. In the EA case, the ROI is generated by the new streamlined
structure, IT alignment, blueprint and planning of the Enterprise which prepares
the ground for a reduction in all future Enterprise expenditure in
• operations (OPEX), from simplification, optimization, lower costs
• capital investment (CAPEX), from re-use, minimized duplication, IT
alignment
• Time To Market (T2M), from diminished "Time to …" make
decisions, design, deploy…, for all future projects delivering new
features, products, capabilities
The Business Case is constructed in a few consecutive stages:
• Assuming a percentage "p" of cost reduction and "p1" more profit
from EA, the Return on the EA asset (RoEA) is calculated relative to the
non EA case, i.e. continuing with business as usual.
• The EA benefits listed in the previous chapter are gathered in a table
with columns explaining why and how profitable they are in financial
terms (OPEX, CAPEX, Time to Market) as percentages; the table aims
to
o loosely associate key benefits to typical financial indicators and various
phases of a New Product Development (NPD) lifecycle
o be a simple tool to support evaluation of the Value earned through EA,
after an EA iteration, by filling in your numbers in the % column
• Equating Enterprise costs to capital investment, operational
expenditure and product and capability development project costs and
presuming that all key benefits indicators in the table are an integral part
and contribute equally (same p%) to the financial indicators then
Typical cost of an Enterprise operation
Cost = CAPEX + OPEX + Product Development
And the cost of the Enterprise operation after the EA implementation
Cost = Cost before EA * (1 – p%), i.e. less by p%
And with a similar judgment for the Revenue of an Enterprise
Revenue after EA = Revenue before EA * (1 + p1%)
• Introducing the initial Investment and the transition costs to calculate
the NPV and Payback
• Analyzing the sensitivity of calculations with regard to "p", "p1",
initial investment, transition period to 80/20 (EA functionality/effort)

Return on Enterprise Architecture (RoEA )
What is the Return On Enterprise Architecture or better yet, what is the
Return on the EA asset (RoEA)? Once designed, the EA becomes an important
asset of your Enterprise. The RoEA is calculated as Benefits/Costs rather than
(Benefits - Costs)/Costs and the calculus will be relative to the non-EA
architecture baseline, the "do nothing" case, to avoid the need for absolute
numbers which are so variable depending on industry, company and the maturity
of the implemented EA.
The reader, at this stage, is advised that this is a proposal of a high level
intuitive process of estimating the Value of the EA for your Enterprise. I could
find no rigorous or otherwise process, for this purpose. It is suggested as an
example which should not pre-empt your own specific approach.

Once implemented, EA simplifies the structure and confers modularity and

IT alignment to your Enterprise. It also provides the blueprint of the Enterprise,
associating process, technology and organization and the strategic
transformation roadmap. Due to these factors (clear structure, alignment,
blueprint and roadmap), EA will ultimately offer, compared to the no EA case,
cost savings from future lower operational costs (OPEX), products and
capabilities investments (CAPEX) and more profit from being agile and as such
early on the market.
Assuming that the EA enables an overall cost savings percentage ‘p’ and
‘p1’ more revenue compared to the ‘No EA" baseline, the Return On Enterprise
Architecture (RoEA) is:
Costsarch = (1 - p) Costsnoarch
Revenuearch = (1+ p1) Revenuenoarch

RoEA = Revenuearch / Costsarch = (1+p1)/( 1 –

p)
Revenuenoarch / Costsnoarch
RoEA = (1+p1)/( 1 – p) = 2, if assuming p = p1 = 33%

In simple terms, RoEA shows that, assuming a cost saving and a revenue
growth of around 33% after the implementation of the EA, your Enterprise
benefits and productivity, relative to the "No EA" case, will be doubling.
These calculations are not meant to be prescriptive or definitive. They just
show that intangible benefits can be quantified if you believe the effort is
worthwhile and the assumptions are true enough. They are just aimed at enabling
the surfacing of a simple conclusion, which is to state that Enterprise
Architecture is entirely justified, if properly implemented and documented.

Key benefits indicators table
Subsequently, a number of proposed key benefits indicators are consolidated
in a table that contains columns which explain why and how the benefit indicator
works, what financial indicator is affected and by how much. The Capital
(CAPEX) and operational expenditure (OPEX), the time to market (T2M) of a
standard product or the capability development lifecycle are such financial
indicators used in project management.

A % column is included for quantifying the impact on the financial indicator.

You may fill in the percentage for each benefit row with figures specific to your
development, to come up with the overall EA gain. And you may estimate the
gain after the implementation of an iteration, to measure the EA added Value.
This table could be also used to evaluate the earned value at important
milestones of the EA transformation program.
For generalization, by choosing all percentages equal to an average value in
%, the overall CAPEX, OPEX and Time to Market is reduced by the same "p"
relative to the "No EA" case. The NPD time and as such the Time To Market
(T2M) decreases by p% and hence enables an increase "p1" in profit.

Figure 65 - EA Key Benefits Indicators Table

Quantifying the Costs and Revenue relative to the non EA case
with the overall Enterprise Costs = Operational + Capital + Development =>
Costs = OPEX + CAPEX + NPDCosts
Assuming a reduction "p" for financial indicators, the overall costs of the
operations of the Enterprise, after implementing EA, are:
OPEXarch = (1 - p) OPEXnoarch and CAPEXarch = (1 - p)
CAPEXnoarch
and assuming this mapping for "Time to" … indicators to NPD Time To
Market (T2M) and same percentage of savings “p” agreed for all Time to …
indicators:
NPDCosts = T2M * CostOfTime;

T2March = (1 - p)T2Mnoarch;

NPDCostsarch = (1 - p) NPDCostsnoarch

Figure 66 - EA Benefits Indicators mapped to Time to Market

=> Costsarch = (1 - p) Costsnoarch

and with Revenuearch = (1 + p1)
Revenuenoarch

=> RoEA = (1+ p1)/(1-p)

By quantifying the key benefits in the table in a few consolidated financial
measurements, we prove that the revenue increase (p1%) and costs reduction
(p%), assumed in the previous section, are feasible and the RoEA stands,
meaning that your Enterprise will deliver faster and better at lower costs, due to
the EA asset.
The table and the whole business case logic were validated against a telecom
operator services architecture development benefits evaluation.

The EA development Revenue and Cost curves
How do we include though the initial capital investment in developing and
implementing an Enterprise Architecture? How do we calculate the Payback
period, the Net Present Value (NPV) or the Internal Rate of Return (IRR) for the
Enterprise Architecture? These are the measures the business people need to
agree to give you the green light for the project.
The proposed business case framework has been designed to enable
understanding of the EA benefits realization mechanism and the impact on
benefits when playing with sensitive parameters such as "time to implement" EA,
"initial investment" etc.
It brings to light the fact that if the EA development is not performed in time
and quality, the NPV will be negative that is, the benefits will not materialize.
Rather than using sample costs and benefits figures, the NPV diagram relies
on a proposed generic curve for expenditure and benefits growth that may apply
to any architecture development program. Furthermore, the calculation and
curve are implemented as a spreadsheet model to enable the analysis of when
and why the EA investment does not pay back.

Figure 67 - The EA development Relative Revenue and Cost curves
Assumptions made:
• An initial investment in the first year, linearly decreasing in the
subsequent years until the curve settles to the business as usual costs
minus “p” % saving from EA when delivered (using an 80
functionality/20% effort rule)
• a linearly growing revenue value till the EA is delivered (as it is
developed EA begins to increasingly generate value).
Both Revenue and Cost curves are relative, that is they represent the
difference between the EA and the No EA development cases.

EA Payback and NPV
The tool facilitates calculations of sensitivities with regard to the main
variables. It enables the analyst to change the variables, such as the cost
reduction percentage ‘p’, the revenue increase percentage ‘p1’, the transition
period and initial investment. The migration time, the quality of deliveries and
the initial costs are essential as with any other successful project.

The main variables: the year 0 investment, the transformation time, and the
sizes of the percentages “p” for cost saving and “p1” for increased revenue, valid
when the EA is implemented. The tool, represented in the graphic, shows that
the faster the development is, the better the NPV and earlier the Payback
(Breakeven). It is essential to reduce the development time frame. High initial
investment combined with low cost saving (p) and revenue generation (p1) from
a poor EA quality may also render the EA development business case negative.
The NPV discount rate assumed here is 12% (for the telecom industry). The
annual costs for the assessed Enterprise are about $35 mil. with annual revenue
around $65 mil.

The initial investment was assumed a fraction (40%) of the annual costs for
operation and development of new products and capabilities of the company.
The migration time is 3 years. The cost reduction "p" is 20% while the increased
revenue "p1" is 10% both relative to the Non Architecture baseline.
The Payback, calculated automatically, is achieved, in the given example, in
year three, while the 10 years NPV is calculated by the spreadsheet at about $39
mil.

This NPV calculation framework has been employed in practice for a
telecom services architecture business case evaluation and gave similar results to
an evaluation in absolute dollar numbers, worked out by a large team.

Figure 68 - NPV and Payback/Breakeven for the development of EA

Review checklist
28. Why is EA an asset and not an expense?
29. What are the assumptions and formula for the Return on EA?
30. Explain the relative Revenue and Cost curves for the development of
EA.
31. Discuss the sensitivity of the NPV and Payback.

Chapter 7


Enterprise related methods and tools, referred to in this book, are briefly
described in this chapter. Technologies such as BPM , ESB /EAI and IT
management methods, tools and best practices are naturally contributing to the
Enterprise Architecture definition and design.

Web Services (WS ) and XML
In a WS system, all components are web services, in that they encapsulate
behavior and publish a messaging API to other collaborating components on the
Web. Web Services reflect the Service-Oriented Architecture (SOA) approach,
based on the idea of building applications from available services, discovered on
the Internet.

With the Web Services approach, application design becomes the act of
describing the capabilities of its functions, transformation into services and
orchestration. In a layered approach, new applications built out of services,
become themselves services.
WS are based on SOAP (or REST) over a transport such as HTTP for
XML documents exchange. UDDI and WSDL serve the purpose of discovery
and description of a Web Service.

Enterprise Integration EAI /ESB
Applications from multiple suppliers, based on various technologies, running
on different platforms are co-existing in the Enterprise. An EAI technology
delivers application integration with the drawbacks of custom integration, lock
into a vendor and expensive adaptors, all common to proprietary solutions.

ESB is a standards based Enterprise Architecture Integration (EAI)

technology; enabling the integration of many IT applications - including
partners' - in an overall business flow. The ESB, like EAI minimizes the number
of point-to-point interconnections. It is based on a resilient messaging
middleware, providing message routing and transformation. JDBC/ODBC
adaptors provide to linked applications connectivity to relational databases.
The ESB also promotes a catalogue of services (typically UDDI) and their
interfaces and definitions. It supports the two main interaction paradigms: a
synchronous mechanism for tightly coupled, request/response requirements,
alongside an asynchronous, loosely coupled message based transport.

Enterprise Resource Planning (ERP )
Originally, ERPs were intended for planning the resources of the Enterprise
operations. Today, the scope is broader, aiming to cover all basic functions of an
organization in an attempt to integrate all data and processes.

From an Enterprise Architecture point of view, the ERPs provide the process
and application layer, offering an Off-the-Shelf integrated solution from a single
supplier. ERPs are slowly invading the territory of other specialized Enterprise
applications, such as CRM, SCM, order and inventory management etc since
they are a convenient "one stop shop" for such services and their integration
technology.
Presently, ERPs seem to have a few disadvantages: they are often seen as too
inflexible to adapt to specific Enterprise workflows; not all functional modules
suit your business or some are less performing than their Best of Breed (BoB)
counterparts; integration with your other systems is an issue; they are expensive
and difficult to install and replace, thus creating an unwelcome dependence on
the supplier. SOA, in a way, is what ERPs supplier fears most as it would open
up the suite to third party, best of breed applications.

IT Information Library (ITIL )
ITIL was developed by a department of the British government, in the late
'80s as a standard operating model for planning, delivery and management of IT
services.

IT Service Management Forum (itSMF) coordinates the evolution of ITIL .

An Information Library consists of a series of eight books:
• Service Delivery
o Availability & Capacity Management
o Service Level Management
o IT Service Continuity Management
o Financial Management for IT Services
• Service Support
o Change Management
o Release & Configuration Management
o Incident, & Problem Management
o Service Desk
• Business Perspective
o Key principles and requirements for business organization and operation
in relation to the development, delivery and support of IT
• ICT Infrastructure Management
o processes, organization, and tools to provide a stable infrastructure
o ICT Design and Planning
o ICT Operations Management
o ICT Deployment
o ICT Technical Support
• Applications Management: the Software Development Life Cycle
(SDLC)
• Security Management
• Planning and Implementation
o How to initiate ITIL ; steps to identify how an organization benefits

Control OBjectives for Information (COBIT ) and Val IT
COBIT is an IT governance framework and supporting toolset that allows
managers to bridge the gap between requirements, technical issues and business
risks, in general between business and IT.

IT is segmented in four domains and 34 control objectives:

• Planning & Organization
• Acquisition and Implementation
• Delivery and Support
• Monitoring
Val IT is a governance framework that consists of a set of guiding principles
and processes proposed as key management practices for providing guidance to:
• The relationship between IT and the business governance
• Manage an organization's portfolio of IT-enabled business
investments
• Maximize the quality of business cases for IT-enabled business
investments through key financial indicators, quantification of 'soft'
benefits and appraisal of risks.
It also provides a benchmarking capability to allow performance figures
exchange. Val IT extends and complements COBIT . It focuses on the
investment decision and the realization of benefits while COBIT focuses on the
execution.

Business Process Management (BPM )
BPM is about modeling, managing and orchestrating your business
processes. BPM. Called re-engineering (BPR) at the beginning of the 90’s, is
aimed at business process improvement.

A business process is a sequence of tasks, performed by technology and/or

people. A workflow typically involves human interaction and long running
processes. Workflow and business tend to and should become one and the same.
Businesses can use BPMS (Business process Management Systems)
technology to integrate existing applications and build higher level processes
through orchestration. The tools to do this are intended for the use of the
business analyst: they operate at a graphical level which provides orchestration
or choreography (distributed orchestration) of the underlying processes,
executed by applications.

Business process orchestration is executed by a Business Engine working

over a distributed middleware (EAI /ESB ). Processes are orchestrated in a
business process language such as Business Process Execution Language –
BPEL enabling web services calls. This allows the Business Architecture to be
implemented as an orchestration of IT Services and human interaction with
orchestration effectively bridging Business Processes and IT applications.
BPEL , former BPEL4WS, addresses Web Services Business Process
Orchestration (for integration, e-commerce …). Centralized control of WSs
resides in a BPEL engine. BPEL addresses:
• Exposes processes as Web services, orchestrated by BPEL
• Loose coupling between services
• Portability
• Parallel and Asynchronous Web service invocations
• Offers security, exception management and logging
BPEL4People (and WS -HumanTask) add the human dimension to the
process with its specific kind of interactions. It adds process states (Created,
Ready, InProgress, Completed, Suspended), roles with privileges (task initiator,
task stakeholder), work allocation to resources in push or pull modes, deadlines
and ensuing actions and escalation. BPEL enforces SOA design based on web
services or, as people call it sometimes WOA (Web Oriented Architecture).
BPEL4People suits the proposed EA framework well since in its context
processes can be executed by either people and technology.

Six/Lean Sigma
A business improvement method that finds and eliminates causes of defects
in business processes that are critical to product delivery. Failure is measured in
Defects Per Million Opportunities, DPMO.
• A “1 sigma” process has 31% yield i.e. 690,000 DPMO
• A “4.5 sigma” process has 99.9% yield or 1350 DPMO
• A “6 sigma” process has < 3.4 DPMO
Usually a company operates around 3 Sigma. A typical 6 Sigma cycle
consists of the DMAIC phases:
• DEFINE – the customer need, in terms of quality
• MEASURE – the defects
• ANALYSE – the entire process; what causes the variation?
• IMPROVE – the process
• CONTROL – process stabilization
Lean Sigma , a “simplified” version of it, more or less, looks at improving
the workflows while Six Sigma at fine tuning the processes to reduce
variability. They are complementary, with overlaps though. Six Sigma applies
more to mass production environments. People advice you to start up with Lean
and continue with Six Sigma (SS). A “value stream” in Sigma terminology is in
a fact a flow, in the terminology used in this book, having attached KPIs for
measurement.
The Business Processes are often designed as part of Six/Lean Sigma ,
business improvement development. Nevertheless, this effort should be aligned
to Enterprise Architecture development, in my view.
6/L Sigma does not use the same vocabulary as BPM or the same
diagramming languages such as IDEF or BPMN . Sigma looks at control,
material and data flows, timing, resources and process governance. This style of
design can and should apply to all business process architectures specification.
BPMN is not quite suitable for that though.

Capability Maturity Model (CMM )
Capability Maturity Model (CMM ) is a model for evaluation of the maturity
of processes of an organization and identification of the key practices to
increase it. CMM is organized around 5 (sometimes six) maturity levels:
• Ad hoc
• Initial
• Repeatable
• Defined
• Managed
• Optimizing
For each above phase the development would have to be evaluated based on
the degree of:
• Commitment
• Ability to deliver
• Completeness of implementation – measured against a few artifacts
• Quality of EA deliveries
Process documentation, automation, requirements management,
configuration management, subcontract management, QA, project planning and
tracking… are all good practices to enhance the maturity level.

Business Process representation
The main type of diagram is the swimlane diagram, common in the business
world, and its equivalent, coming from the IT world, the sequence diagram. It
depicts a flow as a sequence of activities executed in business functions or units.
Here is a sample of Swimlane from Wikipedia. And a S/L Sigma diagram.

Figure 79 - A swimlane diagram showing a flow

Figure 710 - The Lean Sigma illustration of a Value Stream

Porter 's Value Chains
[xiii]
The Value Chain (VC) , described by M. E. Porter in his book,
"Competitive Advantage", consists of a series of activities that build value in
delivering the product. An Enterprise is split into Primary and Support activities,
according to Porter.

Figure 711 - Porter 's Value Chain
• Primary Activities
o Inbound Logistics: the handling of goods received from suppliers and
storage till their utilization on the production/assembly line
o Operations : manufacturing of products or delivery of services
o Outbound Logistics: the distribution of products to wholesalers,
retailers or final consumer
o Sales: sales and advertisement activities
o Service: Installation, after-sales service, complaints handling, training...
• Support Activities
o Procurement: function responsible for purchasing of goods, services and
materials
o Technology Development : products and production capability
development, in general any technology development
o Human Resource Management: Recruitment, development, rewards and
remuneration
o Firm Infrastructure : activity is driven by corporate or strategic planning.
It includes accounting, legal, finance, planning, public affairs, public
relations, quality assurance and general management
At the time, there was little IT technology worth mentioning in this model.

[xiv]
Balanced Scorecard
A Balanced Scorecard is an approach for Enterprise performance
measurement and management. It consists of four dimensions:
• Customers
• Learning and growth
• Processes
• Financials

Compliance (SOX , BASEL II. HIPAA…)
Compliance is about financial management, data privacy, fraud (Anti-Money
Laundering) regulations and other. Generally, any compliance demands:
• Accountability
• Auditability
• Data privacy
• Data storage for long periods
• Risk management (risk register)
• Business Continuity planning and implementation
Compliance is implemented through:
• Managed processes (therefore BPM) with control and audit points
• Document management
• Compliance rules and policies
Examples are SOX in the financial and accounting domain and HIPAA in
Health.

Agile Processes and Smart Deliveries
Agile Processes (AP) were adopted in software development to respond
rapidly to market needs in the dot.com era. AP do away with the heavy, formal
processes and are characterized by:
• a tight knit informal development community
• emphasis on people, not process
• continuous consultation with the customer
• frequent, iterative, software deliveries
A minimal process and plan are still necessary to measure progress against
and guarantee deliveries.
SMART deliveries
Specific: should be clearly defined about what, when and how are achieved.
Measurable: deliverables quantify targets and benefits.

Achievable: take in consideration time period and industry/market
conditions.

Realistic: can be achieved the objectives with existing resources.

Timely: clearly define milestones to state when the objective will be
achieved.

Review checklist

32. How would you use Value Chains in the EA development?

33. What are the main domains of ITIL?
34. What are BPM and BPMS?
35. What is the place of S/L Sigma in an EA?
36. What CMM is used for?
37. How do you explain the balanced scorecard in the context of EA?
38. What other technologies would you see useful in the EA context?

Chapter 8

8. EA Framework s and Classification

Most known EA frameworks are Zachman ’s, TOGAF for the business
community, the US government’s at Federal (FEA ) and departmental levels
(TEAF for Treasury…) and DoDAF for the US Defense framework.

EA frameworks overview
EA frameworks were specified, in different eras with different goals in mind.
Not many of them support the entire EA development since they cover only
aspects of the EA as shown in the classification section.

Zachman 's
The pioneer of Enterprise Architecture was Zachman . His framework for
information systems architecture - first proposed in 1987 and later extended in
1992, represents the archetype of the EA frameworks.
“It is defined totally independently of tools or methodologies and therefore
any tool or any methodology can be mapped against it to understand their
implicit trade-offs ... that is, that they are doing, and what they are NOT doing.
The Framework for Enterprise Architecture is not "the answer." It is a tool ... a
tool for thinking. If it is employed with understanding, it should be of great
benefit to technical and non-technical management alike in dealing with the
[xv]
complexities and dynamics of the Information Age Enterprise.”

Figure 8 - 12 – Zachman 's framework, a matrix
The framework enables examination of a topic by asking common sense
questions. It is often used for mapping the artifacts resulting of other frameworks
and methods to its cells. It consists of a matrix having the "what, how, who,
where" questions on one dimension and different system development
perspectives (owner, designer, contractor…) on the other.

EAP , Spewak's
Another early framework is Spewak's EAP (Enterprise Architecture
Planning). It assembles EA layers and development process in a single picture.
In fact it spells out the four EA architecture layers for the first time. Both
Zachman and Spewak come from the IT world so their views do not cover other
technologies.

Figure 8 - 13 – Spewak's, early Enterprise Architecture Planning Framework

FEA Reference Model

Figure 8 - 14 – FEA Reference Model
FEA , for the US Federal Government, and DoDAF , for the US Department
of Defense are two of the most elaborate but unfortunately, rather specialized
frameworks.

FEA apart from the four architecture layers, business, Information,

applications and technology proposes a "business and performance driven
approach" from Business and Performance reference models to Services,
Information and Technical models.
FEA requires a checklist of EA artifacts, called reference model, that
specifies deliveries for the agencies implementing the EAs. This is a positive
constraint since EA outcomes often appear in various forms, of which, some
may not even serve the basic purpose of understanding or documenting the
architecture. Deliveries themselves are often unstructured, "heavy" documents
cataloging issues and solutions without a coherent view.

The government's EA development is quite complex, given the size and

diversity of its operation. There are a few layers of organization from federal to
local which have to be considered. The aim is to outline services to the public
and align IT to the services architecture with the purpose to reduce duplication
between agencies in platforms, programs and public functions and interfaces. It
was introduced in order to rationalize IT investment in the public sector.

DODAF
DoDAF is a reference model composed of three layers called Operational,
System and Technology viewpoints. The artifacts of DoDAF in the Operation
and Systems viewpoints describe nodes, activities, rules, state transitions,
information exchanges, relationships to organizations charts, event traces and
logical data model. Operational views:
• Operational Concept Graphic, a graphical and textual informal
overview
• Operational Node Connectivity: operational nodes, activities and
interconnections
• Operational Information Exchange Matrix between nodes
• Organizational Relationships Chart lists roles, relationships
• Operational Activity Model with activities performed and their
interrelationships, including input/output relationships
• Operational Rules Model which identifies business rules that govern
or constrain operations
• Operational State Transition to show sequencing and timing of
activities
• Operational Event Trace for actions in a scenario or sequence of
events
• Logical Data Model showing data in the operational view

Figure 8 - 15 – DODAF viewpoints
The Systems viewpoint is described in terms of functionality, components,
interconnections/communications/interfaces and a mapping showing which
Operational Activities are performed by which Systems.
• Systems Interface Description lists systems, system components and
interconnections
• Systems Communications Description
• Systems - Systems Matrix with connections between systems in a
group
• Systems Functionality Description lists functions performed by
individual systems and related information flow
• Operational Activity-to-Systems Function Traceability Matrix maps
systems information back to the Operational viewpoint
• Systems Data Exchange Matrix provides detail of data exchange.
There are also DODAF technology Standards, Standards Evolution and
Performance viewpoints and, in DODAF variants (such as MODAF in UK),
Strategic and Project Views . The table points out similarities between DODAF
Operation and System views and a comparative view to the four layers
"standard", commercial EA framework.

The
OV-2 Operational Nodes model map on the SV-1 Systems Nodes model much
like Business Functions on Applications. The OV-5 Operational Activity Model
and SV-4 Systems Functions Model are similar in nature, both describing
activities/processes. In fact OV-5 looks like the ideal business process while the
SV-4 like the process truly implemented in the Systems Nodes, the ultimate
level of detail of OV-5.

Figure 8 - 16 - A comparison between DODAF and the EA four standard
layers
DODAF v1.0 proposed a minimum set of artifacts (Wikipedia): AV-1, AV-
2 for informal overview, OV-1, OV-2, OV-5, OV-3, (operational nodes,
processes and data exchanges) SV-1 systems nodes and TV-1 technical
standards.

TOGAF
TOGAF's roots are in the Defense framework. It recommends four
"standard" architectural layers and a number of views. Essentially, TOGAF
describes an EA development process (ADM), suggests views and lists artifacts
to be delivered at various process milestones. The documentation is
comprehensive, may be too much so. It is often combined with Zachman and
has made inroads in EA certification.

Figure 8 - 17 – TOGAF's layers and process in one view

TOGAF's parts:
• Architecture Development Model, ADM
• The Foundation Architecture, an architecture of generic services and
functions that provides a foundation on which specific architectures and
architectural building blocks can be built. This Foundation includes:
o TOGAF TRM provides a taxonomy for generic platform services
o TOGAF SIB is a database of open industry standards
o The Integrated Information Infrastructure Reference Model (III-RM),
based on the TOGAF Foundation Architecture and is meant to help
design architectures that enable and support the vision of "Boundaryless
Information Flow ."
• TOGAF Resource Base: guidelines, templates, and information
The ADM is iterative, over the whole process, between phases, and within
phases. For each iteration of the ADM, a fresh decision must be made as to:
• Breadth of coverage of the enterprise to be defined
• Level of detail to be defined
• Extent of the time horizon aimed at, including the number and extent
of any intermediate time horizons
TOGAF recognizes the need for multiple architectures within the enterprise
which represent progressions from logical to physical, horizontal to vertical,
generalized to specific. The continuum comprises two parts: the Architecture
Continuum, classifying reusable architecture assets, and the Solutions one,
supporting the former. Different architectures exist across a continuum:
foundational architectures (TOGAF), system architectures and industry specific
architectures to specific Enterprise architectures. Architectural assets to be
leveraged in the organization's Enterprise Continuum, include:
• Assets created in previous iterations of the ADM cycle within the
enterprise
• Assets available elsewhere in the industry (e.g., other frameworks,
systems models, or vertical industry models)

TOGAF Views :

[xvi]
Figure 8 - 18 – TOGAF views

Other: NGOSS /eTOM , PERA, E2AF , BPTrends EA Pyramid…
[xvii]
The enhanced Telecommunications Operations Map (eTOM ) is in
fact a telecom business process reference model. It is part of NGOSS that also
covers data and other aspects. It is in fact, an EA framework for the
Telecommunication Industry. It exhibits vertical and horizontal views .
[xviii]
E2AF framework of IFEAD , is built on a few of the fundamental "w"
questions and perspectives. It is similar to Zachman and considers viewpoints,
in addition.
[xix]
PERA (Purdue Enterprise Reference Architecture) proposes the
following layers: Production Facilities Architecture, People/Organization and
Control and Information Systems Architecture. Hence, PERA introduces People/
Organization and non-IT Technology. It is not very much in use, apparently.

BPTrends EA pyramid has the advantage of clarity and the inclusion of

human performed processes.

An EA frameworks classification
It is important to distinguish between different types of frameworks since
they serve different purposes. Some frameworks help you structure the EA
thinking by asking investigative questions (what, how, who…) from various
development perspectives. The matrix "question-perspective" is then filled in.
This is, essentially, Zachman 's framework. I call it a "cognitive" tool as it
structures the process of discovery of the Enterprise or of any other system for
that matter. Another example is the IFEAD's E2AF framework. Both
frameworks look like matrixes.
Many frameworks consist of four basic layers: business, information,
applications and technology (the common denominator framework). Some
frameworks add on top a business strategy and objectives layer. These
frameworks look like cubes or pyramids.

Some add a deliveries checklist, known as reference models (e.g. FEA ) to

align the products of all development parties. These look like lists of diagrams,
standards, technologies and matrixes of information exchange and components
interconnections.
Some are specifying a business process map (e.g. eTOM /NGOSS )
consisting of a process hierarchy, describing a telecom reference architecture.
Some EA frameworks offer development and implementation best practices
and program management guidelines such as Spewak's EAP . They are mostly
described in text documents and business plans. TOGAF is mostly about process
and method (ADM). Some are combinations of most of the above.
Many frameworks limit the scope of the technology to IT, although, 50 years
ago, there were few Enterprises served by IT, if at all. Few frameworks are
pointing at organization and people issues which appear to be in different
knowledge domains such as Organization Development and Human
Performance . A few are offering views or viewpoints, e.g. aspects of interest
for various stakeholders.
Navigation and linkage between EA entities in artifacts remain a point of
debate for most EA frameworks. Typically, applications, technology and
information architectures have little in a common: separate diagrams with
different entities, drawn by different architects without a common picture. In
truth, the existing EA frameworks recommend you do the usual business,
information, applications and technology layers and leave you at that. Is this a
problem? No analysis transcends from one view to another, changes are not
propagated, impacts are not resolved and IT is not aligned to business or
strategy. Hence it is a problem.
Existing EA framework types can be loosely categorized as :
A. Matrixes (Zachman , E2AF …) for artifacts classification,
Thinking/Cognitive aids for scoping and discovering the Enterprise and
providing answers to What, How, Where and Why the Enterprise
delivers from various development perspectives
B. Business Reference Map s (eTOM ) for generic business process
hierarchies
C. Layered structures: Cubes and Pyramids (FEAF, TEAF, PBGC,
BPTrends …) describing the Enterprise layers: Process, Information,
Applications and Technology, from strategy to resources layers
D. Process /Method (TOGAF)
E. Planning and Best Practices (EAP )
F. Reference checklist of deliveries (FEA )
Most are combined frameworks since they cover more approaches.

Review checklist

39. Explain Zachman, EAP and FEA.
40. Depict the key Views of DODAF.
41. What are TOGAF ADM and Architecture continuum about.
42. Enumerate other frameworks.
43. Describe briefly the types of frameworks and the EA aspect they
touch.

Chapter 9

9. The Function - Flow - Layer - View (FFLV)

Framework design

Any Enterprise has a structure, i.e. an architecture. It may be convoluted,
ancient, spaghetti like but it is there. Partial descriptions of this architecture
exist; every department has a kind of blueprint. To assemble the entire
Enterprise architecture from parts we need a framework, the backbone where the
parts fit in.

An EA framework definition
The most common method of creating an Architecture is to use a framework
to break down and categorize the various parts of the architecture; this
approach allows focus on design while retaining the overall context within
[xx]
which the object is being designed” .

A framework, in general, is a supporting system, similar to the skeleton of a

body or the chassis of an automobile. In the information domain, it is also
defined as a structure, i.e. a metadata or taxonomy of data.
An architecture framework is the organization of EA components. The
framework is the meta-architecture, that is the architecture of the architecture. It
describes the system structure and decomposition tree even though it does not
define itself the architectures of nodes (represented by artifacts in the
architecture), but solely the frame joining them, showing placeholders.

Using a framework, different parties deliver repeatedly the same outcomes.

By allowing focus on independent efforts on parts in the context of the whole,
the framework makes possible the development of the parts as independent
streams constrained only by the framework interfacing mechanisms. The
framework includes rules and principles to ensure the consistent design and
integration of parts.
The development process, method, its best practices and deliveries checklist
are part of an extended framework since they support the repetitive system
implementation.

A novel EA framework is proposed in this book. It merges various aspects of

existing frameworks and introduces new elements in an attempt to provide
navigability from the business architecture to the technology and organization
resources. Generic business, applications and technology reference maps
(templates) are also provided to help structure your Enterprise Architecture.

EA Framework in analogy to the Human Body
How do we describe a system, any system? A well known example is the
city planning. But let me take a "" known by everybody, the human body and
illustrate the way it is described, by comparison.

[xxi]
Figure 9 - 19 - Human Body systems in Analogy to EA entities
Anatomy illustrates the body by depicting its systems (circulatory, nervous,
skeletal, muscular systems…) and parts (the head, torso, neck, limbs and organs
like lungs, heart, liver..). Each of these parts implements a few vital functions.
Physiology describes how the vital functions such as breathing, sensory
processes etc operate over these various systems and parts. The digestive
process, for instance, depicts the food ingestion, distribution and transformation
into energy from mouth to stomach and beyond. The respiratory process shows
how the body processes and transports oxygen to organs.
The description of the structure and operation of the Enterprise is done here
by analogy with the anatomy and physiology of the body. The structure is dealt
with by anatomy while the operation by physiology.
• A body part (organ) implements a few vital processes; for an
Enterprise Architecture, the term “Function” plays the same role
• A body system, such as the muscular, nervous, circulatory system etc
depicts the assembly of all parts of a body with similar functionality. In
the EA Framework, a body system is a Layer
• A specific aspect of a body system (arterial system of the circulatory
system) is described in the EA as a View, representing a cross-section in
the Enterprise, looking sometimes like a virtual cut or a CT (computer
tomography) body scan picture
• The organs or body parts, are interconnected by nerves, arteries… In
the EA, the interconnections between business functions are called Lines
and are implemented by network connections, production bands etc
• A body vital process is a sequence of activities performed in organs;
in the EA framework, a Flow is defined as a sequence of Function
processes delivering a service
A body interacts with the environment i.e. eats , breathes, feels…. In the
Enterprise, Use Cases scenarios describe the interaction with the environment
and stakeholders. The brain is the supreme governance "body" although parts of
it and other organs are responsible for their own functions.

A doctor, a surgeon cannot diagnose or operate without being familiar with

all the body parts, systems and vital processes. Similarly, an Enterprise Architect
cannot operate without knowledge of business Functions, Layers and Views and
business Flows. Even more, doctors specialize in one of these systems like in the
Enterprise, the domain architects do.

EA Framework Entities
A novel framework Function - Flow - Layer - Views (FFLV) is introduced
in this chapter. Definitions for the key Enterprise Architecture entities:
• A business Function, grouping related business processes and
information, is specified on the principles of high internal cohesion and
loose external coupling. In this respect, a Function is similar to an
Object, in the OO design terminology, that is, it contains data and
behavior.
The EA Function is the Enterprise Architecture building block,
grouping similar processes and the related resources executing them.
• An EA Process is an activity in a Function operating on inputs to
generate outputs, executed by people and/or technology resources.
• A Flow (workflow) is a sequence of processes (including human
actions) delivering a product.
Often enough, you’ll hear debates on the difference between
Functions and Processes. A process is an activity. A Function is a group of
related processes. A Flow is a sequence of processes with inputs and
outputs. Hence, a Flow consists of a sequence of processes belonging to
various Functions. Functions and Flows are different ways to group the
same processes based on commonality and respectively sequence. CRM is a
Function, i.e. a collection of customer related processes. A Customer
“Order to Cash” is a Flow, composed of a sequence of processes initiated
by an order and ending with receipt of the cash. A few processes in this
Flow may belong to the CRM Function.
The business Functions and Flows are part of the EA Business Layer. A
swimlane diagram shows a sequence of processes in a Flow against the
executing business Functions, represented as swim lanes. Function and
Flow have the first letter capitalized only in the context of this EA
framework (FFLV).
• A Product is the output of a Flow/Process, consisting of a piece of
information, a document or a part.
• A Line is a connection transporting a Product between two
Functions or to a stakeholder; it is implemented by resources such as
technology (network connection, production line …) and/or people
(courier).
• A Layer spans the whole Enterprise which consists of three Layers:
Business, People and Technology.
A single architecture diagram showing all Enterprise functionality is
simply too complex for any stakeholder for comprehension. It is way above
the scope of the work. As such the framework allows for Views.
• A View is a perspective of a system, describing only a component
sub-set and relationships. A View is an aspect of the overall architecture,
addressing only a concern of a specific type of stakeholder. Views
enable separation of concerns at design and operation times; are used to
manage complexity so that various parts of the total architecture or
operation are owned by different groups.
According to IEEE 1471, a view is a “representation of a whole system
from the perspective of a related set of concerns”. The same definition,
simplified, applies here.
An EA View is a filter showing only an aspect of an Enterprise Layer,
with a specific functionality. A View carves up a simple picture out of a
complex system. It looks like a cross-section in a tri-dimensional body, a
CT scan picture through a human body.
An unlimited number of Views describe the functionality of a Layer. For
instance, the Business layer comprises of processes, information, business and
operating models, strategy and objectives Views. The People layer consists of
people architecture (organization) and other Views such as culture, values,
recruitment…
A View may be divided in finer grained Views, in other words may be seen
as a composite View. It is typically centered on a Function that provides the core
functionality. The View depicts the interaction of the focus Function with all
other Functions in order to deliver its functionality. A financial View, for
instance, shows budget, cost and profit per departmental unit, at a point in time,
and the connections to the General Ledger application in the focus Function.
Flows are Views in the Business Layer in that they reveal only one end to end
process, in isolation. In a larger sense, any Enterprise representation is a View
because it covers only certain aspects of its operation.
An Enterprise View is a filter across all Layers. An Enterprise product
View shows all entities (Functions, Flows, Processes, Technology, People,
Lines, Views) specific to the process of delivery of a single product. Entities
which are not relevant are not shown, thus simplifying the picture significantly
to solely address a specialist audience. For a bank, a loan architecture View will
only show the Functions, Flows , applications and technology contributing to the
loan process.
Information and Security architectures are composite Views at the Enterprise
level, consisting of other Views. Security, for instance, spanning all Layers,
contains Views describing physical security (in buildings), people security
(person authentication and authorization) and technology such as electronic pass
gates or firewalls.

This framework description and components
The EA framework proposed in this book, merges various EA and IT
architecture development approaches to deal with all the aspects of the EA
development: functions, processes, execution resources, reference deliveries,
planning and implementation best practices.
The Enterprise is generally described by stakeholders' Flows executed by
business Functions resourced by People and/or Technology.
The business Function, the fundamental entity of the Enterprise Framework
and the basic metamodel, groups processes and the technology and people
resources executing them.
This EA framework describes:
• Context: stakeholders, mission, products, Vision and Strategy (Why)
• Structure: business Functions Reference Map (What), Value Chain
• Operation: business Flows, (How)
• Resources executing the Flows in Functions:
o people and organization executing processes (Who) and/or
o technology supporting processes (Technology Architecture)
• Enterprise Views:
o Information/Data Architecture
o Locations: places and buildings Where resources are distributed
o Planning: When, the roadmap of Enterprise Transformation
o Security: How to protect the Enterprise assets
o Other Stakeholders' Views: Networks, Financial Compliance…
An extended EA framework would also contain:
• business case framework
• business and technology Enterprise reference maps/templates
• design method
• development process and best practices
• governance at development and usage
• how to measure the value of EA

The EA design approach, in short
The design process of the EA is similar to Object Oriented (OO)
approaches. It is initiated from a "black box" view of the Enterprise, by
describing the actors (stakeholders), and their interaction with the Enterprise, in
UML Use Cases , (UC). Subsequently, the interior of the black box (the
Enterprise) is structured, by employing a Model Driven Architecture (MDA ) top
down approach, starting from the Value Chain down to a few levels of business
functions. Then, technology and people resource layers are added to document
the implementation of the Enterprise operation.
The interaction scenarios may be described by process diagrams, swimlanes
or UML activity and sequence diagrams. A Function’s behavior may be
described by a state diagram.

Enterprise Context , Stakeholders ' Interactions/Use Cases
An Enterprise is a Black Box providing services to stakeholders, described
by Use Cases. All stakeholders should be considered, not only customers, since
stakeholders’ interaction defines the Enterprise operation. There are functions
and processes dedicated to stockholders, to the cooperation with regulatory
bodies, communication to media (public relations), government etc. These
interactions should be described in a similar manner to the processes delivering
products to customers. For instance, to return value to the Community and
protect the Environment there are projects providing resources for voluntary
work, fund raising for charities or delivering to disadvantaged.

The flows and architecture delivering value to other stakeholders may be

important enough to your Enterprise, to be documented, later on, after the first
few EA iterations.

Figure 9 - 20 - Enterprise Stakeholders and their Use Cases

The Business Functions
An Enterprise entity can be classified as one of four basic Enterprise
activities Governance, Operations, Development and Support (GODS). The
Operation function is equivalent, for the scope of this analysis, to Porter's Value
Chain Primary activities. Michael Porter is one of the business theory gurus of
the ‘80s. Porter's Value Chain Secondary activities are included in the GDS
functions of the GODS Enterprise structure. The Operations function itself can
be further roughly partitioned in:
• Marketing and Planning
• Operations per se
o Source
o Make
o Deliver, according to SCOR (Supply Chain Operation Reference) model
• Sales and Service
A Business Reference Map is proposed as a business architecture design
template.

Figure 9 - 21 - Enterprise GODS Functions

The Business Flow s
A workflow, or a Flow, is a sequence of activities/processes performed in
business Functions to deliver value to stakeholders.. Processes exchange
information, documents, money or parts. A Flow is expressed in an UML
objects interaction, sequence or other diagram. Flows implement stakeholders’
Use Case scenarios. A process is an activity executed by technology and/or
people resources. There are a few typical workflows, such as “Order to Cash”,
“Concept to Product”… A Business Flows Reference Map (proposed later)
provides a template for documenting key Flows.

Customer’s View of the Enterprise
Products are the reason the Enterprise exists. Hence product Flows must
have priority.

Figure 9 - 22 - The Customer’s view of the Enterprise

Owner's View of the Enterprise

Figure 9 - 23 - The Owner’s View of the Enterprise
Owners (shareholders…) are returned value i.e. a dividend or an increase in
share price. There is a Flow delivering this value the shareholder may not be
aware of, but it exists and consists of the process of extracting a part of the profit
and re-distributing it to shareholders.

The Functional Architecture : Flows over Functions
It is the combined outlook of all stakeholders' Flows over business
Functions: all Enterprise flows, operating simultaneously, serving customers,
shareholders, investors, community, financial institutions, suppliers…
The Enterprise has to be so managed to return balanced value to all
stakeholders. That is, it should not create excellent products for customers but
return nothing to shareholders, pollute the environment or fail to return a bank
loan installment.

From an EA framework point of view, it describes the operation of the

Enterprise. The As-Is and To-Be business process maps will be designed over
Functions and their interconnections.
The swimlane diagramming technique would describe well the two
dimensions of the model, the Functions and Flows.

Figure 9 - 24 - The Enterprise functional architecture: Flows over Functions

The EA Resource Layers: Technology and People
The Enterprise resources consist of people and technology (IT technology
and other such as manufacturing bands, telecom networks). The Enterprise
Processes in Functions, assembled in Flows, deliver services to stakeholders;
Technology and People are the resources executing the processes in Flows.
Effectively, every Function (a logical entity), is associated to the People and
Technology resources executing the Processes in that Function.

Figure 9 - 25 - Enterprise Layers
The Business Architecture contains not only business Functions and Flows
but information as diverse as business strategy, business model and objectives. A
Flow, describing a single aspect of the Enterprise operation, can be seen as a
View in the Process Layer.
The Technology architecture consists of IT (Applications and
Infrastructure) and non IT technology (for instance manufacturing), facilities and
real estate. Business processes are embedded in applications. Typical
applications are ERP, CRM, SCM … and business specific applications. The
Technology Infrastructure is made of networks, servers, storage etc.
The People architecture, includes apart from organization, culture and
values, recruiting, training and other Views.

Information Architecture as such, while not a layer, can be abstracted as a

separate View for compatibility with existing architecture efforts. In effect, the
business Functions contain Information, business Flows exchange it, and
Applications store and communicate it. Information falls in the same category as
process, in that it is abstract, exists at the business layer and it is physically
instantiated at the application layer by "data"

A Function Stack consists of Business, Technology and People

Figure 9 - 26 - GODS Functions Stack: Process, Technology, People
Any Function in the GODS model can be decomposed into processes,
executed by technology (IT applications and infrastructure) and people.
Functions have sub-functions which are also performed by people and
technology. An elementary Function is no longer decomposable and as such,
should only contain one process. Flows are executed as a sequence of Function
processes. Functions and Flows represent the first two dimensions of the FFLV
framework.

Layers add a 3rd dimension. While People and Technologies are physical,
Business layer entities like Processes are abstract entities.
The business Functions are the bricks of The Enterprise organizational
design. In a real organization, a departmental unit consists of a few business
Functions stacks that is, the People, Technology and the Processes they execute.
Functions stacks look like vertical partitions across the EA framework layers.

A Flow is executed by a sequence of Function Stacks
A Flow looks like a sequence of Functions stacks.

Figure 9 - 27 - A Flow is executed by a sequence of Functions stacks

EA Layer specific Views
A Layer may be hardly described in one diagram showing all functions and
connections. The amount of the information shown though disheartens the
audience as it obstructs understanding, blueprint’s readability, and stresses the
real estate of the diagram. It is often the case, that complex systems are
described aspect (View) by aspect, by different teams, so that complexity can be
handled. There are various Views in each Layer of an Enterprise. Usually a
View reveals the aspect of interest focused on a single Function providing the
service: for instance, recruitment is executed by the HR Function but serves all
other Functions. Views look like cross-sections in a tri-dimensional object. They
are abstractions revealing the selected functionality. A View may solely show
the Flow under analysis, e.g. the main product/service delivery.

Figure 9 - 28 - Key Enterprise Architecture Layers and Views
The key EA Views are: the Context, describing stakeholders and
interactions, the Business Functions Map, illustrating the logical blocks, the
Business Flows /Processes (with Flows mapped over Functions = Functional
Architecture), the IT Applications Integration and Data Flow View, the Servers
and Storage (Data Center) architecture, the Network architecture and People
roles/organization chart. Other potential Views would be dedicated to the Data
Warehouse, Business Intelligence, Financial architecture…
A HR (people) View will display only the payroll functionality; a View in
the Technology Layer may reveal the storage equipment in a Function or the
whole Enterprise. A Strategy View unveils answers to the "why" question for
every Function. When a strategy View is selected, the information returned is
showing the related strategy initiative and business objectives for the Function or
group of them, since strategy and objectives are cascaded down to each and
every Function and Flow in the Enterprise. Hence, process, people and
technology, should have objectives related to strategy.

Business Layer Views : processes & orchestration, strategy & objectives
A Flow in the Business Layer, is in fact a View, a filter showing only the
workflow of concern. The implementation of a Flow is a sequence of Function
stacks (i.e. a stack = the process and/or the people and technology executing it)
in a tri-dimensional view.

Other business layer views (not all are diagrams):

• Financial Flows (Accounts Receivable, Tax, Cash Management)
• Governance organization and principles
• Business Strategy and Objectives
• Ten years business plan
• Business Model
• Operating Model

Technology Layer Views

IT Applications grouping
Many companies have adopted packaged applications/ suites.
• The ERP becomes a View - part of the Applications sub-layer – that
may be further partitioned in ERP functions sub-views such as
procurement, payroll…
• CRM (Customer Relationship Management) architecture Views
• SCM (Supply Chain Management) architecture
• DW and BI (Data Warehouse and Business Intelligence) Architecture
• Identity Management
• Portal services
• Rendering/Presentation service
• Integration architecture

IT Infrastructure
Beneath the operations level, networking and IT infrastructure Views show
how the support functionality is implemented.
• Servers View
• Storage Area Network (SAN) and Server architecture
• Email architecture
• Printing architecture
• BC/DR (Business Continuity/Disaster Recovery) architecture
• Voice telephony architecture
• WAN Network
• LAN (Local Area Network) architecture
Here are a couple of references to FEA taxonomy for technology
[xxii] [xxiii]
standards and TOGAF Standards Information Base (SIB) .

Non IT views
• Production band, manufacturing machinery
• SCADA architecture
• Buildings/real estate architecture
• …

People Layer Views : organization, culture, communications…
People Views are specified around people organization, performance,
culture, training, payroll, skills, more or less HR Functions. The interconnections
of a View radiate from a (focus) Function in Support such as Payroll to all
associated people roles and employees, showing their remuneration, expenses...
Potential Views:
• Organization chart
• Company Values and Culture
• Recruitment and Training requirements for each Function
• Employee survey results per department
• Payroll View for every Function in a department
• Absentee statistics per organization unit

Enterprise wide Views : Information, Security , Performance , Finance
…

The Information Architecture
Information architecture is not a Layer in itself, for the reason that data
exists in all Layers and Views. Data is represented by an Enterprise wide View.
Selection of the Information View will return a data menu with further choices
available. In other words, the View can be decomposed in other Views,
eventually added later since this EA Framework is open.

The information architecture is structured around business functions just like

processes. Processes manipulating information, can be manual, mechanical or
digital (IT). Information is exchanged internally and externally with Enterprise
stakeholders. As such, information is transported and modified by Enterprise
Flows with CRUD type of Create-Read-Update-Delete operations. A table of
information in business functions can be devised to show how data is associated
to various processes. Information (document) flows (such as order to invoice…)
accompany a product delivery process. A document or message, represented as
the outcome of a Flow over an interconnection Line, should be clicked upon in
the FFLV framework, for more information.
In general, data can be categorized as structured (stored in databases) and
unstructured (content: documents, web content, digital assets and records are in
this category).

Information exists in every Function and at every Layer of the Function

stack: about people, business processes and technology. Information
Views filter and show information of various types in a Function and/or Layer:
with regard to customers, service history, products subscribed or information on
partners, employees, costs, assets, licenses, content, business rules…
Information may be stored, as well, in paper form, not only digitally.
Information may be grouped per Function: information provided (owned)
and information consumed by a Function. Each piece of information will be
assigned ownership by a Function and a list of consumers/stakeholders could be
associated with their specific type of CRUD interaction. The Enterprise Flows
transfer documents between the processing Functions.
Information may be further classified on type (about customers, partners …)
To build the target Information Architecture composite view proceed with:
• Describe business information top-down from workflows exchanges
• Discover and assign the information to Functions
• Discover, bottom-up, your existing structured data in databases and
applications and content in documents, records, multimedia etc.
• Categorize information in types (Customer, Assets, Policies,
Suppliers, Content, Market, Competitors, Contracts, etc), i.e. create an
Enterprise taxonomy for structured and unstructured data with UML
class like relationships between information topics i.e. classify
information in an Information Architecture (see An Information
Reference Map in next chapters)
• Document the Flows maneuvering the information lifecycle; list who
(what Functions) consume the information - use CRUD - and create a
data View showing which is the focus Function (owning the data), which
Functions are consumer
• Specify at the next layer, the applications maneuvering the data
• Processing information, managing its state (business applications)
• Storing it (operational or data warehouse DBMSs)
• Discovering it (Search, Business Intelligence, BI) and reporting it
• Controlling its lifecycle (Knowledge, Content Management)
• Specify for each data privacy, security constraints, access control,
lifecycle, regulatory attributes and
• identify legal and regulatory compliance (privacy for one, audit,
storage period) requirements
• define policies for storing, access, encryption
• For the To-Be architecture design: initiate “normalization” of the
existing data to reduce duplication; consider the Enterprise as a database
• Specify the Enterprise wide data vocabulary (e.g. “order” has the
same meaning everywhere)

The Security View
Most Enterprise entities have security controls. Protection measures should
be implemented at all Layers (business, people, and technology) for all
Functions and Flows. The security architecture is described by a full set of
Views showing risks, controls and security measures for every business function
at process, information, applications, infrastructure and people layers.
The rule of thumb is to analyze each and every business Function for access
and communications to specify security controls and policies. A virtual
perimeter should be drawn around each physical entity associated with a
Function (system, location, people) followed by an inspection of access channels
and deployment of security measures.

After the design of the functional architecture (Flows over Functions), the
outcome should be analyzed from a risk perspective: what is the information
value, what will be the impact in case it is retrieved, damaged, made public or
stolen. Based on this, security controls should be put in place: Access Control
Lists, Authentication and Authorization mechanisms, transport security for data
and parts. The security controls should apply to both information and
technology, physical and remote access such as systems and buildings.
This View has to be owned by your company security group. It is a serious
effort to design such Enterprise wide Views like Security or Information
architecture.

The Location (Where) View
By selecting "Location", the EA return a map with the position of equipment
or people depending on the Function and Layer (Technology or People) you
currently display. Every piece of equipment should have an attribute "location"
describing its physical position. Alternatively an Enterprise should be browsed
by location.

The Location View shows the geographical position of a few related

functions and their entities to various degrees of detail (country, county, floor,
room). There will be, for instance, a location map (View) for the real estate
property and a printer architecture for each building, floor and location in a
company.

The Performance View
Service Level Agreements, SLAs, defined and agreed with stakeholders
should be cascaded to the Enterprise tree; KPIs for each entity (Functions ,
Flows, Technology, People) should be established, measured and stored for all
day to day operations. Six/Lean sigma methods should be employed to improve
the process performance. This will enable a performance control framework
similar to the PRM (Performance Reference Model) of FEA .

The Planning and Evolution View
The fourth dimension is, as always, Time, i.e. the answer to the "when"
question. The Planning View shows the short term activities and projects,
planned, awaiting resources or ongoing for a specific Function, LoB or
Enterprise wide, depending on your selection in the EA navigation framework.
In addition, the time dimension View illustrates the long term view, the
roadmaps and organization evolution. The transformation of the As-Is Enterprise
into To-Be could be shown at each and every Function, Process and Layer level
as a roadmap and subsequently in the Enterprise Project Portfolio View which is
filled in and owned by the project, program planning groups.

The Financial View
Although not specified in EA frameworks, the financial view is relevant to
the good health of the Enterprise. In fact, finance is a resource at the same level
with people and technology. It is considered by many a key factor in the well
being and survival of an Enterprise. A financial architecture would depict the
interconnections of all cost and profit centers to the finance business Function. It
also shows the associated budgets, ongoing costs, financial controls,
accountability and so on. The financial view is linked to financial applications.
Sub-Views as the profit and loss, balance sheet, assets inventory and lifecycle
may be built to show the situation for each organization unit and associated
business function. It is essential for auditing and SOX compliance.

Architecture Principles
The Architecture Principles and Technology Standards are an essential part
of the framework in the design of the Target EA. They shape the As-
Is transformation into the To-Be Enterprise.

The technology standards guide the technology roadmapping which guide

the technology change, selection and replacement.
An obsolescence systems and technology roadmap is also a must to address
technology change. Listed are a few basic architecture principles.

Decoupling/Modularization
Design modular functions on the principle of minimal coupling and maximal
internal cohesion.

Encapsulation
Define access to modules only through well defined interfaces
• to limit random access to internals
• to hide implementation technology

Layering
Design architectural layers, so that a layer always provides services to the
layer above through defined interfaces.

Hierarchical design
Insulate designers of unnecessary detail in the system decomposition tree.

Distribution agnostic
Nodes and services should be designed with transparent distribution in mind.

Standardization
Discover patterns and standardize components, interfaces, processes.

Duplication minimization
A system function shall be specified only once as a single service and then
reused to minimize duplication in functions, processes, data and platforms.

Technology Design Standards

Design on SOA services with ESB and Web Services
Use services, service bus pattern and technology for application integration.

Employ Container/Application hosting technology (JAVA, .NET, Portal)
Since it provides off the shelf horizontal services as transparent distribution,
security, access to databases etc.

Virtualise technology
Introduce interfaces, a layer between the access and implementation
technology to abstract the technology and its entities such as servers,
connections. Deploy virtualization for servers, storage, storage, I/O, networks,
flies, desktops.

Use technology Appliances
Use Off-the-Shelf appliances (Firewalls, XML gateways…) like chips in
the hardware industry.

Converge data, voice and video networks
to replace current two or more separate networks into one.

Deploy Web interactive access for stakeholders
for self service and two way interaction with Ajax, Wikies, Blogs, Social
Networks …

Reuse, Buy or Build
Chose options in this order.

Review checklist

44. Describe the analogy with the human body anatomy.

45. Describe the concepts of Functions and Flows.
46. What are the resource layers of the EA framework?
47. What is Function Stack?
48. What Views and their types are?
49. List Architecture design principles.

Chapter 10

10. Enterprise Reference Map s and

Organization design

The Reference Maps (templates) are based on various proposed Enterprise
patterns.

The Enterprise organization design is a topic in itself. But so are BPM for the
business Layer, Application Integration (EAI/ESB), SOA etc. It can be done in a
number of ways according to the chosen Business and Operating Models.
The Enterprise Reference Maps are templates that describe the structure of
the Enterprise and its EA layers. The proposed Business Reference Model is a
mix between a business Value Chain perspective and a "traditional" IT multi-
tiered view. Both are building on the proposed GODS pattern: Governance,
Operations, Development and Support Enterprise pattern (level 0 in a functional
decomposition hierarchy).

Organization design
An Enterprise, in practice, is organized on a few criteria:
• regional/national boundaries
• Lines of Business (LoB), product lines
• business functions (a logical point of view)
• geography (location)
• workplace (Office, Shop, Call Center, Data Center, Factory,
Warehouse…)
• customer types and segments
• processes in a flow (for instance manufacturing)
• projects: matrix organization which the dimension of project
lifecycle across a functional (rather silo) organization
In practice, the Enterprise is described by all these points of view, combined
at different levels. The Enterprise Architecture templates reflect this reality, each
preferably structured around the best fitting of these criteria.

Figure 10 - 29 – Organization Models
The EA people resource layer is best organized around locations and national
boundaries due to language, specific regulations, market preferences etc.
Most companies have Shared Services, Development and corporate
Governance functions and one or more Line of Business (LoB) organized around
products. A different Value Chain may apply for each LoB (see Supporting
technologies chapter).

Business and Operating Model , Value Chain

Business Models
A Business Model is “a description of the value a company offers to one or
several segments of customers and of the architecture of the firm and its
[xxiv]
network of partners for creating, marketing, and delivering this value” .
For the purpose of this book, a Business Model describes a specific
configuration of the Value Chain selected by your business to pursue a
competitive advantage.
Take for instance a low cost versus a full services airline. They essentially
offer the same service, but under different business models in that they address
different customer segments, different flight destinations, connections, meals,
seat arrangements and partners. This affects the functionality of the Enterprise,
the technology implementing it and the organization
Operating Model s
"The Operating Model is defined as the necessary level of business process
integration and standardization for delivering goods and services to
[xxv]
customers.”
The scope of your Enterprise Architecture is dictated by the firm's Operating
Model. How far are you going to extend the EA application to the businesses of
your company? That is, to what extent are you going to integrate and
standardize the units of your Enterprise?
Before you start designing your EA, the business has to choose how
integrated and standardized the parts of an organization should be across
business functions, organizational units, regions and market segments. The
reasons are many: a business may function very well as it is, it could be sooner
rather than later outsourced or span off; one may only own a stake in it and
hence there is little reason to integrate it. Allowing for integration and
standardization as two orthogonal dimensions, the book "Enterprise
Architecture as Strategy" proposes a few operating models:
• Diversification: low Integration, low Standardization
• Replication: low Integration, high Standardization
• Coordination: high Integration, low Standardization
• Unification: high Integration, high Standardization
I would relate the four models to the Enterprise organization and the four
layers of the Enterprise Architecture. Integration and Standardization apply at
Business (strategy, process…), Information, Applications and Technology
layers. These four types of operating models can be combined in many ways for
the business units of a Group company.

In some units the Group has only financial interests and as such the
Diversification model is suitable.
For core assets the Unification model may be the best fit. That means the
unit is in the scope of a full Enterprise Architecture.
Replication is a modality to organize your business for many geographical
units of the same kind. The units would have duplicated structures. The EA
functional architecture is the same but the physical units may have slightly
different business models, like low cost vs fully fledged services.
And Coordination may fit an organization where the products or business
units are highly interrelated but standardization may not fit all business units
well. This will reduce the EA work to integration rather that standardization.

Integration applies well at the Applications (and business orchestration) layer

while Standardization especially at the Technology layer.

Value Chains
The basic Business template remains Porter's Value Chain (VC) since the
80s. Enterprise VCs consist of activities linked to deliver products to customers
and, in general, value to stakeholders. An Enterprise may be described by a
logical structure, derived from the Value Chain.

Figure 10 - 30 - A Business Template modeled on the Value Chain
It defines a partitioning of the Enterprise according to Value Chains such as
Supply Chain, Sales and Service…
The Market & Plan segment contains business functions such as market
research and segmentation, prospect acquisition, brand and forecasting.
Marketing, as opposed to other models, is placed before all other phases, since
solely the “advertising” function appears later in the Value Chain.
Make & Deliver is about "manufacturing" the product, the Sourcing, Make
and Deliver stages of SCOR.

Sell & Service is self explanatory. Traditionally, the Make & Deliver phase
comes before Sales and Service since it delivers the products. This case applies
to an Enterprise of the type of Make products to Stock (like in SCOR). In the
services industry though the Sell & Service part may come before since the
subscription, contract, order, agreement, ticket sell are happening before,
followed by Operate & Deliver. This is equally valid for firms which Make to
Order (SCOR). As such, depending on firm, the Sell & Service is swappable
with Make & Deliver.

The Enterprise GODS map
An Enterprise Function can be classified in one of four basic Enterprise
activities Governance, Operations, Development and Support (GODS). During
my practice in Enterprise Architecture, I realized that, all Enterprises have this
structure even if some functions are outsourced. While Development and
Governance functions are not mentioned in Porter’s Value Chain, they are
important for EA. For instance, for the Virtual Enterprise the corporate
Governance coordination function is the only function left identifying the
Enterprise., all others being outsourced. The Development function is equally
important since it covers the Enterprise development. What GODS means:
Governance is in charge of coordination and supervision of all other
Functions. Governance, in general, is about: what decisions are being made, who
makes them and how (process, policies and rules for decision making). At an
Enterprise level, decision bodies would be
• Company Board of directors
• CEO office (Legal, Communications…)
• The Strategy and Planning Board
• Operations Board
• Investment Committee
Operations is responsible for delivering the products to customers. It
consists of business Functions like inbound/outbound logistics, manufacturing
and distribution in Porter's Value Chain view. For this work, Operations consists
of:
• Markets (segmentation, customer acquisition, advertising…) &
Planning
• Operations per se (and according to SCOR)
o Source
o Make
o Deliver
• Sales and Service (Support)
Development delivers Enterprise capabilities:
• New product and capability development
• R&D
• Business process improvement
• Organization evolution
Support of all other Functions in the Enterprise and management of
resources:
• People (HR, Payroll)
• Financial Management
• Project Management Support
• IT: Helpdesk, Data Center, Application Management
• Technology maintenance
• Real estate and facilities management
Each of the GODS Functions may be divided into lesser level functions.

The IT EA Template
The IT Architecture pattern emphasizes the
• Customer Front Tier
o Access and delivery channels: web, mobile, telephony and application
front ends
o Aggregation and presentation layer
• Common Utility functions
o Authentication, Authorization, Accounting
o Workflow, BPM/Orchestration over Services/Integration Bus
o Content management
o Collaboration
• Business logic
o Business Application
o Business Data
• Business to Business (B2B) for partners and suppliers

Figure 10 - 31 - The IT EA template
This partitioning has roots in the history of IT starting with the MVC
paradigm, the Model (data schema) View (Presentation), Controller (Logic)
division.

The IT architecture changed from mainframe and dumb terminals to multi

tier client-server architectures and later to the web based architecture, with a
universally available browser at the client device, a web front end and the
application logic.
Data storage is typically in databases separated from business logic although
at run time data is embedded in persistent objects. The Front Tier is in the
demilitarized zone, behind a firewall layer, while the business logic and data are
behind two rows of firewalls protection.

This may be the only template employed for an Enterprise Architecture

typically in IT intensive Enterprises. This IT reference architecture also maps on
the business Supply Chain model SCOR, specifically Source, Make, Deliver.

Figure 10 - 32 - Enterprise Functions aligned to the GODS and IT Template

The Business (Functions) Reference Map
This model is the result of the merge of the business and IT templates.
At the top of the model are the Customer channels while at the other end are
the Suppliers and Partners interaction and the B2B access. The Customer
interaction happens all across the Value Chains, from market research, prospect
acquisition to Sales and Support.

Let's explain how an Enterprise works on this simple model. The Marketing
function researches the market to determine product characteristics for specific
market segments. The Planning function forecasts the size of these markets and
produces strategic plans. The Development function studies new technologies,
prototypes them and builds new products from marketing concepts and the
capabilities needed to produce them. The Operations sources the parts,
assembles them, stores stocks and distributes to outlets. The Sales and Services
sell the products, service them, manages customers complaints and returns.
The Support functions as HR recruits and trains people, manages training
performance appraisal, benefits… The IT functions procures and manages
technology, Facilities manage real estate and fleet. Program management
controls capabilities deliveries. Finance plans, procures, measures and controls
budgets. The Governance coordinates all the rest, maintains public relationships
and provides legal advice.

Figure 10 - 33 - The Business Reference Map /Template

The GODS single page generic Business Architecture
The resulting picture is the generic one page GODS business architecture
consisting of the main business functions and flows that illustrate the Enterprise
structure and its operation.
The generic business architecture further decomposes Michael Porter’s
Value System to show the critical enterprise functions and flows of a business
cycle: Planning, Demand Creation, Production, Sales and Order Fulfillment,
Revenue Accrual, and After-Sales Services.

Figure 10 - 33bis - The GODS single page generic business architecture

The one page generic GODS business architecture is building on Porter’s
Value Chain and System concepts; it consists of the key enterprise functions that
form the enterprise structure and enterprise flows of the business cycle, that
deliver value to stakeholders.
The GODS generic business Flows:
• The Planning Flow that begins with the market investigation,
followed by forecasting; this Flow prepares all Operational,
Development, and Support cycles.
• The Demand Creation Flow stimulates the market, through various
channels, to acquire the products.
• The Production Flow or Supply Chain delivers the Products, from
sourcing to distribution.
• The Demand Flow or Sales and Ordering is the process through
which the customers obtain the products.
• The Revenue Flow or Money Flow charges the customers at sales
and ordering, bills and invoices them, and accrues the revenue attained
for the firm.
• The After-Sales Flow or Customer Services depicts the customers'
feedback/complaints, product returns, and repairs Flows.
The Services Industry Flows are slightly different:
• The Service Provisioning (Subscription) Flow describes how the
customer acquires membership to a scheme, or subscribes to a service.
• The Service Delivery Flow depicts how the customer, once
identified, claims and uses the service, often provided by a business
partner; analogue to the Production Flow.

Benefits of the GODS generic business architecture model

Here are a few benefits for business modeling:
• It is complying to IEEE/ANSI 1471 since it consists of both business
functions and flows, that is components in relationships, rather than
either capability maps or business flows in separation.
• It makes distinction between business capabilities, processes and
flows that are not clearly distinguishable today in other business
modeling approaches.
• It aims to be complete at the top in that it describes all categories of
functions of a typical enterprise Value Chain (as GODS), and all flows
of a typical business cycle.
• It represents the customer’s interaction and channels consistently - at
the top of the diagram - for every flow of the Value System so that one
can trace and improve the customer journey from prospect to after-sales.
• It represents the top tier of an EA framework, elucidating the first
steps of an EA development
• It is technology and organization neutral in that it does not contain
elements of them; nevertheless, the IT architecture can be readily aligned
to the BA within the same EA. Architectural Views can be linked to BA
to reveal necessary detail, systems and organization roles that execute
the business architecture functionality.
• It supplies the functional vocabulary and business objects repository.
• It represents a reference architecture that can be tailored to industry
and company to create a specific framework for own business operation
discovery, documentation and roadmapping. Your practical business
architecture would be a customization of it, representing your own
Enterprise as a common model shared around the Enterprise. It would be
the single most used artifact of an EA.
• Ultimately, it enables the fusing of the current business modeling
methods in a single approach uniting the Business Capability Maps of
EA with the Value Chains and Business Models…of Business
Management and Value Streams of xSigma and Quality Management
disciplines.

The Business Flow s Reference Map
Any Enterprise operation can be described by a few key Flows (From…To
range of processes in sequence), starting with the stakeholders' interaction with
the company.

Figure 10 - 34 - A Business Flow s Reference Map /Template
This would be the starting point for the discovery and design of the Process
Architecture. There are external Flows, interacting with a stakeholder, and
internal flows - describing end to end processes executed over Functions. The
internal processes can be used to refine the Functions in the Business
Functions Map.

This experimental model may be enhanced to suit your specifics. You will
[xxvi]
find though that there are extensive models , typically describing process
decomposition hierarchies, although often it is not clear if the decomposition is
Functional or Flow based, which is confusing. It is important to distinguish here
between the “business Function” and Flow. A Flow is a group of other
processes sequenced to deliver an outcome while a Function is a group of related
processes in no specific sequence.

The Enterprise Group Line of Business es

Figure 10 - 35 – An Enterprise Group and its Lines of Business (LoBs)
Nowadays, Enterprises have grown into complex multi-nationals delivering
portfolios of products to multiple markets.
Many companies become part of an Enterprise group. Some of them fully
owned, some partially so and many only financially controlled. Frequently, only
some core businesses enter the EA scope. Each Line of Business (LoB) is
structured on the GODS pattern, on the Value Chain and in general on the
overall Business Reference Model with the exception of the corporate
Governance, Support shared services and Group Development functions.

Terminology of Business Architecture
Business Functions Map/Architecture: the hierarchical decomposition of
the Enterprise business functions.
Business (Functions) Reference Map: a generic industry wide or specific
Business Functions Map valid for any Enterprise, to a degree.

Business Flows Map/Architecture: the hierarchical decomposition of the

Enterprise end to end processes.
Business Flows Reference Map: a generic industry wide or specific
hierarchical decomposition of an Enterprise in end to end processes.

Functional architecture: Flows executing over business Functions; the

combined view of Business Flows executing over the Business Functions Map.
because it can become very complex it is only specified for a few processes at a
time. Swimlane diagrams may be used for representation.
Business Architecture: consists of the context architecture (stakeholders’
interactions), Business Functions Map, Business Flows (Map), Single Page
Architecture and Information Architecture. It also consists of key business
documents like Business Models, Operating Model, Strategy and Objectives, its
mapping to Business Functions and Flows Trees, Roadmaps, Ten Years Plans
and so on.

The Applications Reference Map
This map represents a simplified view, typical of an Applications
Architecture. It shows types of applications. Applications are lined up with the
business template. In practice there are many variations. Applications can be
counted in the hundreds. Many are of the same kind, In general this variation has
to be decreased and standardized.

Most importantly, applications have to be integrated to enable process

automation and data exchange. Integration of applications requires
communication using the same paradigm (messages, calls), protocols and
information structure. This can be achieved through a distributed middleware
that in general transforms messages and data formats as required by the
interacting nodes, routes them to the destination no matter the location, verifies
access constraints, provides reliable transport and services as transactions.

The Information Reference Map
It depicts a few generic types of information found in most Enterprises. In
practice there is much more information than this. It depends on what specific
aspect of data architecture you are looking at.
In general the data architecture is useful to discover and avoid redundancy in
data and variation in structure and formatting for ease of integration. IT can be
loosely described in a class diagram exhibiting relationships.

The Infrastructure Reference Map
It describes the Enterprise servers and networks, typically in two diagrams
since they are in different domains of expertise. This architecture may be
described, by more specific Views. The template describes the typical
environments for infrastructure: the Shop, Call Center, Data Center, Office etc.

Figure 10 - 36 – An Applications Reference Map

Figure 1037 – An Information Reference Map

Figure 10 - 38 - An Infrastructure Reference Map

Mapping Reference models to Organization
The organization map is one of the ubiquitous Enterprise artifacts. All other
EA layers architectures could be mapped to it so that business processes and
technology are associated to the people in charge. Often the organization chart
itself needs updating during this process to enable a better mapping. A modified
organization chart is shown in the picture with "workplace" type taxonomy
introduced. This would easily support infrastructure mapping.
The EA business and applications layers are best structured by a logical,
functional view.

The EA technology resource layer is well partitioned in workplaces:

Office… mapping well on the IT EA pattern described in this chapter.

Figure 10 - 39 – EA layers architectures mapping on the organization

Figure 1040 – Functional vs Workplace alignment
The EA business layer is best structured by a logical, functional view.

The EA technology resource layer is well partitioned in workplaces:

Office… It maps well on the IT pattern.
The EA people resource layer is best organized around locations and national
boundaries due to specific conditions.

In practice, the Enterprise is described by all these points of view. The

Enterprise templates reflect this reality, each structured around a different
criteria.
At As-Is discovery time, a bottom up approach starts from resources
description structured by location and types of workplaces. At To-Be design
time the process is initiated from the ideal logical view of the business.

Review checklist

50. Why do we need templates, reference maps?

51. What are the main criteria for organization structure design?
52. What are Value Chains?
53. Describe GODS.
54. What is a Line of Business?
55. What is the IT template based on?
56. Describe in words the Business Reference Map.
57. Why do we need a Business Flows Map?
58. How would you use an Information Reference Map?
59. Enumerate workplace types .
60. Enumerate key types of applications and suites.
61. Explain mapping of various architectures.

Chapter 11

11. EA Patterns and Single Page

Architecture

EA layers are built on few simple patterns: Nodes, Lines, Rules and Plans.
The metamodel describes the relationships between EA entities observing
patterns. The Single Page Architecture is an overall single page view of the
Enterprise.

Enterprise Architecture patterns
EA layers are built on few simple patterns: Nodes, Lines, Rules and Plans.

Business Layer
The Nodes are implemented by Processes in Business Functions ; the
Lines by Flows of control (events), information (documents) or parts.

Application Layer
The Nodes are implemented by Applications.
Lines by information exchanges over middleware such as EAI .
A Service sub-layer is introduced by a SOA EA development. Nodes are
implemented by Services while Lines by Requests in SOAPXML , REST Web
Services and ESB messaging.

Infrastructure Layer
Is composed of two sub-layers: Servers & Storage and Networks.
Server and Storage sub-layer
Nodes are implemented by Servers and Storage units. Lines by
TCP/IP transport protocols and respectively SCSI and Fiber Channel
links..
Servers:{
• SW side:
o Application Servers (Java EE, .Net)
o DB Servers (Relational, XML , Object, Hierarchical… DBMSs)
o Web Servers (+ Server Pages)
o Network File Servers, Printer Servers
o Audio/Video Servers
o Email, Chat, FTP, telnet…
• SW servers interconnection protocols
o JMS, RMI, SMTP, SNMP, FTP, Telnet…
• HW side
o Windows, UNIX. LINUX…, Hypervisor (virtualization)
o on Blades, rack drawers, mainframes, AS/400…
• HW servers interconnections:
o Sockets, TCP/IP
}
Storage sub-layer nodes {
o DAS: Direct Attached Storage
o NAS: Network Attached Storage
o SAN: Storage Area Network (RAIDx)
• Storage interconnections
o iSCSI
o Fiber Channel (FC)
o …
}
Networks
• LAN (Local Area Network) implemented mainly by Ethernet Hub
switches
• WAN nodes implemented by Switches, Routers, Gateways, DNSs…
over fiber (Dark Wave, SONET…) and copper ( Tx/Ex, xDSL)
transmission networks

Figure 11 - 41 – EA patterns: Nodes and Lines at each layer

The Single Page Enterprise Architecture (SPEA )
The Single Page Enterprise Architecture is a diagram (see diagrams at end
of chapter) providing a synoptic view of an Enterprise operation, describing the
key business functions and the interconnections channeling key flows; it shows a
reduced view of a functional Architecture (all Flows over Functions ) depicting
solely key business functions and flows. It looks like an application integration
architecture with applications exchanging information over pipes.
The applications (systems), the Functions they map to, the flows and
stakeholders are represented in subsequent EA views.

SPEA is structured on the Business Functions Map . As the Business Flow

s Map is discovered and designed, entities are added to the Single Page EA.
SPEA is the most popular EA artifact. It is used by everybody to understand
the Enterprise operation and communicate in the same language. It remains, in
some cases, the only Enterprise Architecture artifact. It addresses the whole
Enterprise audience and should be designed with a largely available drawing tool
since most people must have access to it.

It is similar to the Operational View 2 (OV-2) in DODAF that shows nodes

(Functions here) and needlines (Flows).
Since SPEA represents the logic operation of the Enterprise, the level of
detail has to stop to a couple of levels below a Line of Business (LoB ).
Frequently, an Enterprise consists of a few Lines of Business, each delivering a
product. Further detail going beyond level 2, can be provided by a specific
business Function architecture and be referenced from the parent Function in the
SPEA.

A couple of samples of Single Page EAs are shown in the following.

Support functions are typically not shown, for simplification.
In the Single Page EA diagram: a box is a Business Function which is a
subdivision of a Line of Business .
• A Line of Business is an area of the enterprise delivering a specific
service or product
• A line is an information/material/control flow; an arrow ending a line
shows the destination of the flow.

Figure 11 - 42 - A Single Page EA modelled on the Business Reference Map

Figure 11 - 43 - A Health Insurance Single Page Architecture- IT template

Review checklist
62. What are the EA main patterns?
63. How do they map on each EA layer entities?
64. What is a metamodel?
65. What are the key artifacts of the metamodel?
66. Explain the key relationships between entities of the metamodel
artifacts?
67. What is the Single Page Enterprise Architecture (SPEA )?
68. What are the main SPEA components?

Chapter 12


The EA reference maps/templates supply a generic structure for an
Enterprise. It should be used to jump start the EA development efforts.

A framework is the backbone, the frame of a system to which most parts are
fitted. An EA framework looks like a contents page, a mindmap or a document
tree with all components of the EA having to hook onto the framework. It does
not define the architecture of the components, but solely the frame joining them,
exhibiting component placeholders. It enforces reuse of components, an
interface philosophy, design constraints and notations and architectural
principles to provide consistency in design so that artifacts fit back into the
framework.

The EA Function - Flow - Layer - View , FFLV Framework
The EA framework consists of business Functions , Flows and Layers
(Business, Technology and People) described by Views .
The FFLV framework proposes an EA meta-architecture consisting of a
Flows over Functions functional architecture - shaped by a Business Reference
Map - executed by the Technology and/or People resource Layers with Views
describing various layer specific or Enterprise wide stakeholders' concerns.

Figure 12 - 44 - The Function-Flow -Layer -View (FFLV) EA Framework
An extended business Function can be seen as a stack traversing the EA
layers. The business processes. the technology and people resource layers,
belong to the Function stack. To that, one might add strategy, objectives,
performance criteria etc, all cascaded to the Function stack entities.

In a Flow diagram, any line between Functions or to stakeholders can be

described in terms of an output of a process (Product) which can be a part,
information (bill, order, message) or event and a connection (Line ) which is its
transport, implemented by a network, a mechanical transport band or courier.
The framework could initially be implemented with a minimum of flows
describing the customer’s services, two or three levels of Functions in a
hierarchical decomposition and a minimum number of Views . As the
framework is open, Functions, Flows and Views can be added at later times.
There are also the 4th dimension, “Time” and the 5th, the detail or level of
granularity.

The three dimensions of the FFLV Framework
The FFLV Framework specifies three dimensions: Functions , Flows and
Layers/Views . A swimlane functional architecture diagram shows business
Flows consisting of processes executed by Functions/participants in lanes. The
Layers/Views dimension exhibits the executing resources view.

Figure 12 - 45 - The 3 EA framework dimensions: Function. Flow , Layer
/View

The FFLV Framework Tree
The EA design and analysis is hierarchical; a specific level of detail could be
chosen for analysis, depending on stakeholder's interest. An Enterprise can be
seen as a hierarchy of Functions structured in an Enterprise tree i.e. the Business
Functions Map; it can be also seen as an Enterprise hierarchy of Flows (Business
Flows Map); and also categorized in a number of Layers: Business, Technology
and People or Organization, each and every one of them further described by
Views filtering only the aspects of interest to you.
Hence, the entry points into the EA navigation framework and tree are the
Functions, Flows, Layers and Views. This tree can and should be devised for the
Enterprise Architecture. It also guides the sitemap of the EA web site which may
also contain other information business, technology or people related such as
strategy…

Figure 12 - 46 - The Enterprise Framework Tree

The Key FFLV Views
The Business Reference Map (BRM) provides the initial structure for all EA
views, including the Single Page EA. The Business Functions Map may be
shaped by the BRM Enterprise reference map.
The key Views were selected to minimize the effort to design the first
iteration of an EA. They are the Context (Stakeholders' interactions), the
Business Functions Map, the Business Flows, The Organization chart and the
Technology (IT Applications, Servers and Storage and Networks) architectures.

Figure 12 - 47 - Key FFLV Views , Business Reference Map & Single
Page EA

The FFLV Framework Metamodel
Largely, a metamodel describes the structure of a system. The EA
metamodel illustrates the types of EA artifacts, their components and
relationships. It is imperative to be implemented in an EA tool since the
metamodel is the DB schema of the repository of the EA framework in the tool
database.
The Enterprise can be depicted as a Black Box with surrounding
stakeholders’ interactions described by business Flows. The Black Box is
decomposed as either a hierarchy of Business Functions or Organizational units.
A map linking the Functions to organizational units should exist, and it is
important for the organization alignment to business and technology.

Business Flows contain entities such as processes, interconnections,

information exchanged, events and participants (in swimlanes). A sequence flow
between two processes can represent an information item, event or a physical
part transported over a connection. A swimlane in a Flow diagram represents a
Function in the Business Functions Map diagram. As such, processes become
part of Business Functions. Resources such as People, Applications and
Infrastructure, show a relationship to the process they execute.
A Function, as the basic unit of the Enterprise, is related to the Applications
and People groups or roles it is executed by. Hence resources executing the
processes - such as organization roles and applications – may appear in a lane.

At the business level, an Information Architecture Model exists, in fact a

taxonomy of Enterprise key Information Items.
At the resource level, the physical or electronic documents with data
schemas, described in the Data Model are implementing the Business
Information Model.

Process sequence flows are implemented by applications interconnections.

All objects in the diagrams are stored in the tool repository with relationships
as in the metamodel for enabling navigation between EA artifacts.

More relationships and components could be added to the basic metamodel

from new EA architecture artifacts.

Figure 12 - 48 - The FFLV Framework plain metamodel

The FFLV Framework Navigation
One may choose to see the whole picture of the Enterprise or a department, a
Function, a View, a Line (connection). One may navigate horizontally along a
Flow or vertically over a Function to inspect the process and resources involved,
such as people, applications and supporting technology.

Figure 12 - 49 - The FFLV Framework Navigation Cube from menu bar
The FFLV framework representation constitutes the Graphical User Interface
(GUI) to the EA artifacts with direct entries to the EA tree elements: Functions,
Flows, Layers and Views, for selection. The navigation is initiated by clicking
on the graphical image components (Function, Flow, Layer or View. For
horizontal navigation you need to click on a product/line. Navigation can also be
performed with Up/Down, Back and Home buttons.

Figure 12 - 50 - The FFLV Framework Navigation Cube with side menus
From a tool perspective, a View, is the graphical representation of all
objects in a repository that have been selected to have a specific attribute value,
chosen from the EA GUI. A mouse click on a menu or cube GUI generates an
SQL statement selecting a combination of objects and interconnections from the
repository, assembled as a diagram by the tool. Ideally, once a View or a group
of Views is selected for display and visually edited, the tool should be able to
retain the visual configuration and re-create the diagram on subsequent
selections; a first time editing will allow diagram shaping and configuration.

A Customer's request navigation scenario
The following figure illustrates how to trace a customer's interaction flow
and navigate to the layers of applications and infrastructure implementing it.

Figure 12 - 51 – The basic EA navigation screen

The FFLV mapping to other frameworks
The FFLV framework covers:
• Zachman's designer and implementer perspectives: as Business and
Technology layers respectively
• the What and the How perspectives of Zachman: the Functions and
Flows in FFLV
• EAP and TOGAF like layers: Business, Information, Applications
and Infrastructure
• People and Organization layer (the Who) (TEAF, PERA …)
• Views, aspects of interest to Stakeholders as in TOGAF, IFEAD's
E2AF
• As-Is, To-Be and the Transformation process and Best Practices as in
TOGAF, EAP & others
• Architecture principles and technology guidelines, as in TOGAF,
FEA
• Enterprise Strategic Planning as in EAP, TOGAF
Both TOGAF and FFLV refer to an EA development process, layers, views,
principles. TOGAF does not really put forward a framework structure
synthesized as a single graphical representation. TOGAF ADM is similar in
approach to the proposed EA development but a comparison is difficult since
TOGAF is so plentiful.

And, like in OO methods, the FFLV employs UML and Use Cases to
describe the interaction with stakeholders.
Some other frameworks as MIMOSA, Gartner's … are outside the scope of
this book since they are not widely in use or I was not able to collect relevant
information.

Mapping to Zachman
Zachman’s framework from an FFLV point of view:
• the What: FFLV business Functions - rather than information
• the How: FFLV Flows, describing the operation of the Enterprise
• the Where: the location View applied at the Enterprise or Function
level returning the location of resources
• the When: EA roadmaps and planned developments
The FFLV functional architecture maps on Zachman's designer’s logical
perspective.

Figure 12 - 52 - FFLV Framework mapping to Zachman

Mapping to the four "standard" EA layers
The mapping to Zachman, the early guideline and mapping model for most
frameworks, is described in the figure.
The Business, Information, Applications and Infrastructure architectures
appear in most EA frameworks, as the de facto "standard" four layer
architecture. In the FFLV, Business, Applications and Infrastructure are each
described by different views relevant to stakeholders rather than by a single
architecture diagram.

The Information Architecture is a composite Enterprise View as information

exists in conceptual form in the business layer, in electronic data versions in the
Technology layer or in physical paper copy on your desk..
In addition, FFLV has a People and Organization layer, essential in
describing the Enterprise organization and performance in alignment to business
processes and technology.

Mapping to DODAF

Figure 12 - 53 - A comparison between DODAF and FFLV
Leaving out, for clarity, the concept (OV-1), the summary (AV-1/2), and
standards (TV-1) the remaining artifacts compare well to FFLV.
The summary of a potential mapping a minimum DODAF to the FFLV:
OV-2 Business Functions Diagrams
OV-5 Business Flows Diagrams
OV-3 Information exchange generated from Function/Flow models
SV-1 Applications Architecture
The FFLV Flow diagrams are similar to DoDAF OV-5 or SV-4 views while
the FFLV Applications architecture diagrams to DoDAF systems SV-1.

The FFLV frameworks enables navigation between Functions, Flows, Layers
and Views at different levels of detail; it unifies most EA frameworks
approaches and provides answers to all Zachman's questions. It is structured and
synthesized in a graphical framework easy to understand and navigate.
The FFLV framework can be utilized to integrate the work you have already
done using another framework; it also adds Views for all stakeholders and
enables, at the same time, the mapping of processes and applications to the
organizational units and people roles.

Review checklist

69. What are the dimensions of the FFLV EA framework?

70. Why is the navigation of EA framework important?
71. What is the Enterprise tree?
72. How can the EA framework be navigated?
73. Describe FFLV mapping to Zachman.
74. Write down the mapping to DODAF.
75. What is the mapping to business process maps like SCOR, VRM,
eTOM?

Chapter 13


The role of IT
It is hard to conceive a business without IT of some sort these days. Overall,
IT supports the customer sales, service, access and call center technology,
business automation, B2B, data storage, document management, archiving,
office automation, complex calculations, communications, collaboration and
security. Here is only a draft list of some of the today's Enterprise IT functions:
• implement core business and support activities: business logic, ERP,
CRM, SCM…
• business automation engines replacing repetitive human activities
through business process and rules
• storage of structured information (customer, product, supplier...)
• content management supporting the information lifecycle: creation,
transformation, storage, archiving, search, publishing and presentation of
documents, media, records...
• authentication and authorization of customers, partners and
employees
• customer presentation and distribution channels: web, email, chat…
• automated B2B interaction to suppliers and partners
• data and applications integration middleware

• powerful calculation tools for complex scientific, forecasting or
simulation algorithms
• DW/BI/Risk Management tools
• office automation, desktop and printing network services
• Software development tools
• Computer Aided Design (CAD) tools for drawing and design
• management of all other IT infrastructure
• collaboration, communications, remote access and mobility
• security (encryption, digital signatures, firewalling...), load balancing
• the infrastructure to support all above: processing servers, disks,
RAID..., archiving tapes ...
The list is open. Often SW/HW systems are not categorized as IT as for
instance: PBXs, SCADA, manufacturing equipment, robots, mobile
technology…
Since IT has such a high innovation rate, IT is also a major source of
innovation.
IT is ultimately a key source of competitive advantage in the enterprise or,
alternatively, when poorly managed, a source of pain and costs. IT has become
a prime object for simplification, alignment to business processes and goals i.e.
for Enterprise Architecture.

Business drivers for IT
Business imperatives like resolving the legacy patched spaghetti Enterprise,
coping with customer churn, the increased amount of complexity, information,
change and the need to care for the world around have all solutions in IT.

The customer data and identity integration demands of a "Single Customer

View" may be solved by a data architecture and implementation of Master Data
Management (MDM)/Customer Data Integration (CDI) solution.
The "Straight Through Processing" may be the target of a business process
improvement effort.

SOA will provide modularity based on services, thus agility. A Data

Warehouse, Business Intelligence and reporting efforts will manage the "Single
Version of Truth". They are all, in fact, part of an integrated Enterprise
Architecture effort.
The table summarizes the five big Business requirements along with their
stakeholders and the IT solutions that contribute to their satisfaction.

Figure 13 - 54 - Business Drivers and IT priorities in summary

Key IT projects
IT technology currently stands many transformations. The mainframe is still
there occasionally. Its replacement requires a multi-million, multi-year effort. In
some cases, the life time should be extended with SOA services.

The legacy of merged companies with multiple products left Enterprises with
inconsistent organizations, many portals, different information architectures and
various platforms for the same purpose.
Business requires a Single (Reduced) Sign On for customers and a Single
Front End i.e. the same "Look and Feel" and process for all products and
services.

Management needs to understand the reality of the business; so reporting

based on a Single Version of Truth is key. Data warehousing and Business
Intelligence well implemented, become competitive advantages since they help
understanding the market and the costs and profits of your own operation.

Figure 13 - 55 – Developments at IT Application layer
Document imaging to translate the customer paper application to electronic
XML documents are unavoidable.
Business Process Automation (Straight Through processing) through
BPM orchestration and choreography with partners are a condition for survival
in this competitive landscape, since they enable an agile Value Chain.
Application and Data integration efforts are a must today. since there are too
many applications, each with its design philosophy.
Outsourced converged networks (data, voice, video) services become the
norm. Virtualized data centers are the latest in fashion: servers, networks and
storage are all virtualized. The Data Center is eventually outsourced. Loss of
Business Continuity is unacceptable nowadays. Disaster recovery is required by
shareholders.
Lately companies like Amazon provide data center on demand, PaaS,
"Platform as a Service" services. Remote work and wireless access gain ground.
The Call Center has been outsourced for some time now. RFID is emerging in
the warehouses and shops. Then EA and SOA would decouple, streamline and
document the Enterprise.

Figure 1356 – Initiatives at IT Infrastructure layer
The success of the evolution to Enterprise Architecture springs from making
financial sense: have an opportunistic strategy, taking advantage of natural
product life cycles and planning the EA around these and the new products and
capability development.

Solution Architecture alignment to EA
Most key projects change your Enterprise structure. The Enterprise
Architecture (EA) itself, reflecting the Enterprise structure, evolves, changes
with each successful project, even if not documented. Every project has a
timeline delivering at various implementation milestones, starting from an As-
Is state of a few systems in the Enterprise towards a Vision state through a few
transition states. Frequently, a project has to take into account all concurrent
changes and outcomes of all other on-going or future implementation projects.

Figure 13 - 57 - Solution Architecture s in the EA context
A Solution Architecture is the target architecture of a new or enhanced
Enterprise capability, but, at the same time it:
• represents a capability architecture View in the Enterprise
Architecture
• contains a transition roadmap and
• is associated to the project delivering it
The current Enterprise Architecture is the result of the overlay of all existing
domain architectures.
A Domain Architecture does not have an associated project or roadmap but
is
• the architecture of a business area, function or capability
• and a view in the Enterprise Architecture

Figure 13 - 58 - The Solution Architecture component views
Any solution Architecture should be documented by a few EA views:
• Context diagram showing stakeholders interactions
• Business Functions Map
• Business Process diagrams
• IT Systems/Applications architecture and Data flows
• IT Technology (servers, storage, networks)
• Organization units/roles (optionally)
• Relevant Information Architecture
all limited to the scope of the solution domain and aligned to the
Functions structure.

Figure 13 - 59 - EA layers as the overlay of all Solution Architecture Views
To align to the EA, a Solution Architecture should update all affected EA
diagrams and the EA repository, be stored and selected in a tool as a View and
have the documentation archived on the EA Intranet site to record the value
proposition, costs, alternatives.
A target Enterprise Architecture is the result of the overlay of all solutions
architectures at the end of the transition period considered.

With an Enterprise Architecture in place, every project should document

changes and update the EA. Hence, EA records all changes in the Enterprise and
becomes the single source of truth, the updated source of information for all
developments. By consulting this single reference source, the EA, all other
projects can take stock of changes in the current architecture as soon as planned
or implemented. All projects should continuously update the current and target
EA architecture views, to inform all other development projects.

Figure 13 - 60 - Alignment of EA to Solution Architecture s projects
The target state of the Enterprise is sketched, dictated by your Strategy. This
target Enterprise state will have to be equally recorded in the EA so that the end
project design would take into account the changes in your end goals.

Applications Inventory
Applications inventory is a must have catalog of IT systems. It should be
structured around the key business functions they serve. The catalog enables the
standardization, reduction of duplications and alignment of systems to business
functions. It is also important to note the license requirements, costs,
depreciation, position in the life cycle, roadmapped changes alternatives and the
recommended technologies and products. A similar inventory table should be
compiled for Infrastructure – servers, storage and networks. The proposed table
is basic, not showing all potential attributes. In many cases this information is set
up in a database. Ultimately the applications, infrastructure and interconnections
table information should be extracted from the EA repository as diagrams and
reports.

Figure 13 - 61 – An Applications Inventory basic table

Integration Architecture
Application architecture is most readily translated into an Application
Integration picture where all applications and their interconnections are depicted.
The application architecture template that maps applications to business
Functions is the background over which interconnections are drawn. External
systems
should be included to terminate exchanges. A table of all applications and
interconnections would be the first step.
Figure 13 - 62 – Applications Integration table

IT Obsolescence and EA roadmap
Obsolescence is the state of a system in its lifecycle when it becomes...
obsolete - that is old, outmoded, falling into disuse - from a both functional and
technological point of view. Given a few years more, it becomes an antique and
were the system sufficiently rare, will pay you off more than new.
In the business world, there already are a few concepts that help with
obsolescence: depreciation of an asset or even amortization in accounting terms.
An EA architecture repository and tool should support the obsolescence
analysis by adding specific attributes to the metadata of the entity. The EA
applications and infrastructure assets may have different obsolescence criteria.

The obsolescence discussion should be had with the business owners of the
application and the IT maintenance and development teams. All IT assets
should have recommended obsolescence periods to enable the planning their
replacement. And here I remind you of the concept of value of replacement in
the insurance industry.
Obsolescence from a business perspective happens when
• the delivered IT service is not making profit any longer
• the service logic needs significant updates: legislation changes,
compliance
• the User Interface has to be significantly upgraded
• competitors grabbed an edge with new technology; you need to offer
similar or better
Technology obsolescence causes are:
• technical skills no longer available or becoming too expensive
• scalability has reached its limits
• the architecture is harder and harder to maintain, too many patches
• asset already depreciated
As a result of an obsolescence analysis a number of measures can be
adopted:
• remove, no replacement
• replace with newer technology
• upgrade
• wrap application, virtualize technology to extend life
The analysis should also document the cost of replacement , cost of not
doing that and time frame of obsolescence.

Obsolescence should be included in your Enterprise transformation roadmap

and projects portfolio.

The EA versus ITIL , BPM , Six Sigma , ERP , ITIL…
Enterprise Architecture, IT and Service Oriented Architecture (SOA), IT
Information Library (ITIL), Enterprise Service Bus (ESB), Enterprise
Application Integration (EAI), Web Services (WS), Software as a Service
(SaaS), Business Process Management (BPM), Lean/Six Sigma, Enterprise
Resource Planning (ERP), how are they all related, or aren't they? They are all
aspects, developments, parts of an Enterprise Architecture. But typically, they
are treated independently.
EA is often associated to SOA or IT Architecture. The scope of EA is wider
than the scope of IT architecture at least because it includes business
information, people and organization, manual and mechanical processes. EA will
always include the Enterprise wide IT architecture in the technology layer. But
EA is more that IT architecture.

There are synergies with ITIL (IT Information Library) and other
frameworks like Microsoft’s Microsoft Operations Framework (MOF). Many of
the ITIL management functions can be represented as FFLV views, as for
instance systems configuration, network administration etc. ITIL only describes
the high level processes and best practices for the operation of the IT as a
department in the Enterprise. ITIL is different from IT architecture (which
describes the Enterprise wide IT implementing business services) and is very
different from the Enterprise Architecture which is much larger than ITIL or IT
architecture, for that matter.
Processes are often embedded in complex application suites as Enterprise
Resource Planning (ERP) or Customer Relationship Management (CRM). ERPs
attempt to cover the application layer in the support domain of the EA. The
processes, embedded in ERP application suites can be discovered with tools by
what is called an ERP modeling process.

The ESB, like the EAI, serves as an integration middleware at applications

level, part of the IT Architecture. ESB often enables SOA services integration.
BPEL business engines offer service orchestration i.e. integration at the process
layer. Integration is a small part of EA though.
Software as a Service, SaaS is becoming more popular as an off-premises,
outsourced, on demand SOA function. The SaaS supplier may provide the same
service to many customers on the same multi tenant platform. The customer
receives an effective service at a lower total cost and better QoS. Common offers
are Sales platform, expenses, travel, helpdesk, enterprise email etc.
Six Sigma or its Lean variant are about business process improvement. Few
consider including them in Enterprise Architecture. But they are part of
BPM and EA. Sigma looks at current processes implemented by people and
machines, describes them and plans to improve often, attempting to reduce
defect variations into a three sigma statistical range.

Review checklist

76. Explain why IT is indispensable to the Enterprise.

77. What are the business imperatives?
78. What are the typical key IT projects?
79. How are Solutions Architectures aligned to EA?
80. Describe Solution Architectures integration to EA.
81. What are the attributes of the Application Integration table?
82. How do you deal with IT obsolescence?
83. Describe in a few words the relationship of EA to BPM.
84. Describe in a few words the relationship of EA to ITIL.
85. Describe in a few words the relationship of EA to Six Sigma.

Chapter 14


For most business people, SOA looks like yet another over hyped
information technology. SOA, which has its roots in a long history of distributed
components architecture, is usually associated to Web Services technologies and
is typically promoted by IT.

But what is SOA? Is it a technology, an architecture, a program or a product?

Is it a business or an IT development? What is the rapport to BPM? And what is
the relationship to Enterprise Architecture (EA)? After all, both SOA and EA are
about the Enterprise and its architecture, with the EA supposed to remedy
similar malfunctions of the Enterprise. It is just that SOA appears to attract an
even more IT oriented audience than EA. The question is, should we implement
SOA and EA, SOA only, EA only?

What is SOA or WOA for that matter
SOA is primarily about business design and only afterwards about the
technology for service integration and discovery. In a wider view, any function
of an Enterprise, not necessarily IT, can be defined as a service. The service
paradigm has been long applied in our day to day life and even in IT. Not long
ago we were attempting to fix the car ourselves or mow the loan. These days, we
just employ one of the many services on offer, at a cost we can afford and at a
quality we cannot supply any longer. In real life, the technology for service
discovery is the Yellow Pages.
From a business angle, SOA is a style of business architecture design and,
ultimately, a way of re-structuring your business. It enables a Business Oriented
Architecture by allowing the business define Enterprise workflows around
reusable business services. The granularity of the service is targeted at the
business cognizant, rather than at the software application developer.

• What is SOA?
• SOA is a business oriented style of architecture enabling best of
breed, technology agnostic business services, delivered by applications,
with a granularity determined by business needs rather than IT
• A SOA Service is an interchangeable building block, providing a
business service that exposes an interface, hiding the internal
implementation technology and published in a service registry for
dynamic discovery
• SOA is also an integration technology (based on WS: SOAP, UDDI,
WSDL and ESB) evolving from distributed component architecture
technologies
• SOA, W3C definition: "a set of components which can be invoked
and whose interface definitions can be published and discovered”
• Web Services (WS) are implementing a SOA paradigm over Web
protocols.
A business service would require definition and enforcement of SLAs to
control the quality of the service delivered and the service consumption within
defined usage limits. An accounting mechanism should measure the service
usage at an SLA for payment purposes. Security is another important aspect of
SOA as it regulates access and enforces privacy and integrity of the information
exchange in a distributed environment.

From an IT point of view, a SOA service is a component providing a service

which exposes an interface hiding the internal implementation technology,
published in a registry, and eventually, dynamically discovered.
Like Object Oriented (OO), SOA provides data and behavior encapsulated in
a service, accessible solely through published interfaces. But, as opposed to OO,
which addresses the SW development community, SOA aims at services
business can understand, and orchestrate to implement end-to-end Enterprise
processes. Objects and components like Java Beans and ActiveX are still
technology dependent i.e. in the context of the language and platforms, Java EE
and .NET, while SOA services are technology transparent executables, in that
any technology would do as long as it complies to the messaging and interfacing
protocols.

A SOA service returns an outcome in response to a request. The service may

use other services, transparently, in a layered manner. What is the definition of a
layered service? By having a look at networks and their protocols, it is apparent
that the concept is not new. In the OSI (Open System Interconnect) networking
standard, a layer uses services provided by the layer immediately below, that in
turn, employs services in the lower layer, and so on. Similarly, SOA business
services use distribution and security services provided by the supporting
middleware, which in turn employs services provided by the platform (JavaEE,
.Net) and OS infrastructure.
As a style of architecture, SOA applies to any system design. At the
Enterprise level, the workflows, delivering value to stakeholders, may be built
out of services which are technology, supplier, location or owner independent.
The Enterprise would ideally consist of a loosely coupled set of business
services.

Web Services have been implementing the SOA paradigm over Web
protocols, for a while now. As a result, SOA is often associated to Web Services
and its technologies (SOAP, XML, UDDI, WSDL...). But SOA is more than IT
although its origins are in software.
SOA + WS gives WOA used for integration of external services, called in
some instances, global SOA. WS is a technology only, SOA is a style of
architecture while WOA joins the two. WOA is an IT development rather than a
business one as SOA: already existing services, accessible on the Web, are
integrated to Enterprise processes. WOA brings SOA in the IT realm again.

SOA benefits
Service Oriented Architecture (SOA) reduces costs through service reuse
and, by promoting modularity at service level, it enables the flexibility and
agility required to respond to the ever greater pace of change.

More often than not, agility and technology reuse are the major benefits
associated to SOA. The reality is that SOA, frequently approached outside an
Enterprise Architecture context, is developed incrementally, without the benefit
of the big picture the Enterprise Architecture delivers. As a consequence, the
promised agility and reuse are not achieved or are achieved late, towards the end
of the SOAization of your Enterprise when technology reuse may require costly
redesign.
Nonetheless, there are a few other major SOA benefits, which should be
more easily achieved, understood, and accepted. Invoking these advantages
would make SOA a joyous sell rather than the often reported stressful
experience.
SOA benefits:
• Agility is the ability to compose your business processes our of
independent services in response to market demands; the services
themselves can be outsourced to different services providers when
necessary and the orchestration can be easily changed by the business
expert.
• Integration: after all SOA enables easy integration of business
systems over standard messaging, standard technology (WS, ESB),
standard discoverable interfaces.
• Documents based communication between various services; an
important distinction to OO is the communication with information rich
XML documents rather than simple information structures; this increases
manifold the communication efficiency and aligns systems integration
better to the business style of transactions.
• Reuse: SOA is about modularity and reuse; a good service will be
called from many applications rather than redesigned or re-implemented
in various versions. A "re-entrant" platform capable to sustain many
threads is in order.
It is worth mentioning though that the Business process reuse is the
advantage rather than the IT reuse, since SOA identifies similar business
activities and groups them in a service. SOA reduces process replication
and, only afterwards, for the same type of process, the application
duplication.
• Business service accountability, improving business governance
Application are usually a bundle of many functions; in practice, a large
group of business and IT people will share the responsibilities for the data
and behavior of application functions. But can you hold accountable a
group of individuals with many other responsibilities, for a specific
function? In such an environment, neither accountability nor authority can
be assumed for specific functions in an application. On the other hand, for
an SOA business service, a single role is being assigned the responsibility:
it does not matter if it is an IT or business issue, there is one single point of
contact for the service and a service SLA to deliver against.
• IT technology virtualization conveyed by SOA services hide the
implementation technology and offer a clear, contractual-like interaction
between business and IT.
IT becomes a service provider, offering business services at a QoS
secured by an SLA, well comprehended, quantified, and eventually
remunerated by the business through a payback mechanism. This is a major
achievement since your applications and technology are hidden behind IT
services supplied to the business. From a business perspective, this is what
really counts. There is no longer a division between business and IT, but
well cut interfaces, SLAs, and contracts. No more blame culture. The
separation of concerns pacifies the parties.
• Untangling the applications to provide a clean architecture, reducing
the side effects of change.
There is no more random access through the back door to applications
or databases, which makes any change a burden and any modification a
major risk because of unforeseeable effects.
• Extended lifetime for legacy applications, reducing the pressure to
replace them. This is achieved through the encapsulation of legacy
behind SOA interfaces. Although there are other increasing costs related
to legacy technology, there is no more pressure to replace it; you can do
it at own convenience when a viable alternative exists. This is an
extension of the technology virtualization benefit.
• Enables outsourcing: Software as a Service (SaaS) which is making
inroads in the software market, is effectively an outsourced SOA service.

SOA and BPM
The relationship between SOA and BPM has been the subject of debate. No
wonder, since there are different professional groups, magazines or activities to
address them. BPM was in vogue in the 90s as BPR, Business Process
Reengineering. As a concept, it is the practice of discovering your processes,
improving and automating them to reduce human error, Business processes are
also a part of the Business layer of the Enterprise Architecture (EA). The
Enterprise processes would be described by current and target process
architecture parts of As-Is and To-Be EA. Processes are still abstract in that they
still have to be performed by humans and/or machines. There are notations and
languages to describe business processes. There are models that help in
evaluating the maturity of processes and frameworks, such as CMM and Six
Sigma, for process improvement.
SOA is a style of business process design for the target architecture with
processes implemented as an orchestration of loosely coupled SOA services.
SOA is an evolution of BPM aiming to hide and encapsulate complexity of
processes in independent business services. In SOA, the business workflows will
consist of orchestrated SOA services that encapsulate both the process and the
technology implementing it.

From a technology viewpoint, BPM is offered at the EA business layer, as

Business Process and rules design, execution and monitoring engines. Now these
are offered as part of an overall SOA proposition, since they provide an
orchestration service.
On the other hand, SOA is an integration technology based on products as
Enterprise Service Buses (ESB), Service Registries, and management tools. But
the definition of SOA services is still in the realm of business; services should be
specified by business people, since they are not an IT concern or in the IT
domain of expertise. This being said, ERPs, embedding and integrating various
Enterprise processes, are the products of IT companies.

Is an ESB part of SOA? It is not, even if inside an Enterprise, it is definitely

helpful, in that it provides a series of services like transparent distribution,
reliable messaging. security, transactions, data transformations… that otherwise
will fall into the attribution of each and every application.
Is orchestration included in SOA? That is orchestration performed in a
business process execution language in a business engine. Not really, but it is a
good practice, adding to the business agility since it is performed by the business
expert graphically and not by IT.

SOA and EA
Many EA programs are partially happening under the cover of
SOA developments. In truth, SOA can be seen solely as the Target EA
implementation solution whereby, business functions are specified as services
and workflows as orchestration or choreography of services. The SOA only
effort ignores though, the initial As-Is discovery phase of an EA development,
the requirement to align IT to business goals and the Enterprise strategic
planning effort.

SOA does cover architecture, but it does not specifically address business
process automation, IT alignment to strategy, even if it helps; it does not
document the As-Is state like EA does; and it does not provide guidance for the
development program as EA methodologies do. SOA requires a large Enterprise
process re-engineering and redesign effort, with significant consequences, at
process, applications, infrastructure, and people Enterprise Architecture layers.
Services will be reused, access will be enforced by SLA contracts, and a new
SOA services governance will be in use affecting the existing organization and
applications suites.
SOA harbors under its umbrella developments that are in the scope of EA
and as such, it hides the recognition and complexity of an EA program. SOA,
given its scope and ambition, should be a joint business and IT effort, a key part
of a full EA development, and not considered in isolation as a light IT Enterprise
Integration effort.

SOA alone is misleading if not taken in the context or scope of the EA

development. After all, it can be applied to any architecture (an application
architecture, for instance) and not necessarily to an Enterprise Architecture (EA).
A note of caution: the Enterprise Wide IT Architecture (EWITA) is often called
Enterprise Architecture.
SOA, in the Enterprise context, is a Service Oriented target EA design and
implementation. It requires re-engineering of the business, data, technology and
people layers around business services and, as such, a new business governance.

SOA + EA = SOEA
A “Service Oriented Enterprise Architecture,” SOEA, defined as an EA with
an SO style of target architecture, would better describe the positioning of
SOA with regard to EA. EA may be implemented without SOA while a stand-
alone SOA development, mainly driven by a Service Orientation Architectural
requirement, will tend to ignore business objectives and strategy.
The EA sets in place a process to achieve technology and organization
alignment to business processes, strategy, and objectives. SOA, as a style of
business architecture, is adding value to the EA by enabling modularity at the
business service level, and, as such, agility, reuse, Quality of Service, facilitating
payback mechanisms and service contracts. This means a more decoupled
business where services are provided and consumed based on contracts. And this
offers enhanced manageability. Moreover, there are benefits from enabling
services provided over the Web using Web Services technologies, and from
making possible service outsourcing on an on-demand basis, such as Software as
a Service (SaaS).

SOEA, the development of an EA with an SOA flavor, must have support

from top management and involve business since it requires process re-
engineering, technology alignment, and firm re-organization, in other words,
SOEA transforms the whole Enterprise, more than EA or SOA taken separately.
As both SOA and EA are usually initiated by IT, the lack of business
stakeholders' engagement and firm's management support or funding may foil
the success of SOEA.

The SOA should be initially implemented as an additional EA service layer –

on top of the EA applications layer – which would exist during the Enterprise
Transformation stages. Some time into the future, the Applications will be,
hopefully, implemented as Business Services, and the SOA services layer will
cease to exist. This requires the applications suppliers to adopt SOA, which
would be an advantage for everybody except, maybe, for them.
Once implemented, SOEA (EA + SOA), becomes a powerful competitive
asset since it is the blueprint of a service-based Enterprise, with best of breed
components easily outsourced, no matter what technology or geography.

SOA , To Do or To Buy
The definition of architecture states that it is the structure of a system and the
description of its components and interconnections. As a structure, the
architecture exists in any system, no matter how convoluted; and it can be
described by an architecture diagram.

For the target state of a system, a blueprint is drawn to describe the desired
logical architecture of the system, that is its components and interconnections.
This architecture blueprint enters then a design phase where technologies and
products are selected for each component and interconnection. The end result,
the design blueprint, consists of detailed drawings of the interconnected
components of the systems.
The design is ready now for implementation and as such, at last, the
architecture is implemented in a physical system out of the interconnected
products.

A style of architecture consists of recognizable and reproducible architecture

patterns. SOA is a style of architecture applied to a target system. SOA, as a
style, can be equally used in an application or in the target architecture of an
Enterprise. SOA architecture, after the design phase, is implemented by the
systems delivering the SOA business services.
SOA is at the same time an integration technology for services rather than
applications. This is what vendors try to sell you: ESB, registries... based on
SOAP/XML, UDDI, WSDL etc. SOA technology integrates and interconnects
rather than implements the services of a system. Vendors also offer, in addition,
business process (and rules) engines, B2B systems, application servers, service
management and other products in their SOA offer.

The SOA business services design and orchestration is what people say you
must do, not buy. You do have to specify your business services first and then
interconnect them with a SOA technology.
Can you say implement SOA services once you specified them? You can.
But you can equally say that you buy SOA technology to integrate the systems
delivering the business services.

SOA Design Best Practices
SOA is often treated as a separate development from EA, BPM…. It is not.
SOA provides modularization, standardization, integration and re-use.

In hardware design you always need a schematics diagram to describe the
components and their interconnections. Catalogues describe the components
functionality, interfaces and protocols. By analogy, in a SOA architecture,
services described by WSDL and discovered by UDDI are interconnected
through orchestration.

The SOA development, part of the EA effort, should be directed by business

and should have support from top management since it is really a business re-
engineering exercise. Exceptions are cases where SOA scope is limited to Portal
developments and Web Services where IT is in charge and already skilled for
the development.
Here are the few steps for designing the target EA, SOA style:
• Discover your current architecture:
o Specify for each Line of Business the As-Is EA Business
Functions Map Use Business Reference Map provided.
o Document the external stakeholders’ flows process steps, events, data,
control and material flows, key business rules and associated roles.
o Specify internal flows; use the business process template suggested in
the book or alternative sources.
o Specify GUI and process interaction to customers and other
stakeholders.
o Document current technology architecture
o Identify bottom-up systems, applications, information topics and
organization units and roles, implementing business functions and
processes.
o Document supporting organization roles and responsibilities
• Specify target business architecture
o Assess impacts of strategy, planning and objectives on functions,
applications and technology
o Evaluate technology specific issues and solutions impacts on architecture
o Employ loose coupling, high internal coherence architecture principles to
specify independent elementary services
o Build complex services out of elementary ones using SOA composition
o Identify functions in applications that can be deployed as services
o Propose a list of services
o Design target Functions as business services: encapsulated functions with
interfaces describing service requests and responses, technology
independent; not all services being implemented by IT. In software
development, function calls or subroutines are reusable segments of code.
SOA orchestration calls services in a similar manner to the main program
calling a function.
o Redesign processes as an orchestration/choreography of services;
o To confer responsiveness, Event Driven Architectures (EDA) are often a
choice in SOA design. This enables asynchronous operation and
parallelism. Since the OO time a debate existed between the sequential
like Central control of the objects of an application and the distributed
event and message based communication between objects with no central
supervision. The reality is as always somewhere in the middle, where the
central orchestration and events at service and orchestration level co-
exist. An event distribution scheme like publish/subscribe could be
implemented. This would be in the realm of the SOA products technology
capabilities.
o Describe services UI to users and customers
o Provide management and maintenance interfaces to services
o Align information architecture to services; provide an MDM service to
hide existing legacy databases
o Identify applications changes required to fit SOA services and request
change projects
o Select technology for SOA integration (ESB, UDDI/WSDL repository…
BPM)
• Begin implementation program
o Sketch technical transformation roadmap with dependencies, taking into
account the technology and applications lifecycle and upgrades to
minimize change for the sake of change and exploit new technology
opportunities
o Decide, roadmap and initiate negotiation for outsourcing of services as
BPO/SaaS/Managed Services/Data Center
o Assign governance and accountabilities for each business service
o Do planning, establish budget, assign resources
o Plan with suppliers the SOA style changes/design of applications
o Iterate and design and deliver services in steps

A SOA Design Case
In this section, a SOA design is illustrated in pictures, specifically the As-Is
and the To-Be EA. The transformation excludes the strategy impacts on the
architecture. The target picture is derived from the Service Orientation demand
of the Enterprise and good architecture principles such as reduction of
duplication, applications integration and technology standardization. Hence, the
current duplication in business systems is eliminated, the many internal
connections dissapear replaced by an ESB, and the platforms are identical (Java
EE, Open Source JBOSS or BEA/Oracle). Circled are the systems that become
Enterprise Services, grouped in a customer front-end layer (Portal and
presentation), utility functions (Authentication, Content…), B2B access (to
suppliers, banks…), Business Logic specific services and Support (financial,
reporting…). Before the SOA technology is deployed, the major effort is to
define reusable services provided by systems and decouple, encapsulate and
standardize their interfaces over SOA ESB and Web Services interfaces. An
ESB technology interconnects all major services of the Enterprise. A business
orchestration engine is implemented and if the architecture is opened to accept
Web Services an UDDI/WSDL discovery platform must be added. SLA
contracts must be established to formalize the service payback, according to
usage, monitored over the ESB. The architecture should be events based.

Figure 14 - 63 – The As-Is Single Page EA of an Enterprise

Figure 14 - 64 – The SOA design solution for the target EA

Evolution to SOA
The MIT Sloan Centre for Information Systems Research (CISR) studies
identified four distinct architectural stages that business units and IT must pass
through before the benefits of SOA can be realized: (1) Silos, (2) standardized
IT, (3) standardized business processes (Optimized Core) and (4) business
modularity.
There is the underlying assumption that SOA is a target EA architecture,
achieved at the end of the Enterprise transformation process, from the As-Is Silo
stage.
Long term, the history truly shows, that the Enterprise maturity evolves from
the silos of the ‘90s, through IT standardization, to arrive now at stage 3 of
business process rationalization and pointing at stage 4, the SOA based
Enterprise. CISR also states that moving upwards, from stage 1 to 4, is
increasingly difficult, since to achieve stage 3, business participation is a must
and to realize stage 4, an overhaul of your Enterprise operation and
organizational change are necessary.
While I agree, I would like to observe that the transition from 1 to 2 would
not remove silos until stage 3, since silos exist because of business rather than
IT.

SOA , lessons learnt
• SOA is primarily a business development, a way to structure your
Enterprise, a style of target business architecture, and only then an
integration technology.
• SOA must have support from top management and involve business
since it requires process re-engineering, technology alignment, and firm
re-organization.
• Since both SOA and EA are usually initiated by IT, the lack of
business stakeholders' engagement and a firm's management support or
funding may foil success
• Pick only the technology you need for integration and orchestration;
vendors have piled all their products in the SOA basket – BPM and rules
engines, user interaction (Portals), application servers, B2B gateways,
messaging middleware, repositories/registries, data management,
business intelligence products, development environment and
management equipment. After all SOA is about best of breed, vendor
independent services.
• SOA does not succeed outside an Enterprise Architecture
development since, in itself, does not cover the development process, the
current situation discovery (process, apps, infra…), information
architecture, the alignment to strategy…
• The target business processes are specified top-down while, the
current processes discovery, is performed bottom-up starting with the re-
modeling of existing applications. Top-Down design and Bottom-
Up discovery EA efforts, performed simultaneously, succeed if
observing the same EA framework decomposition tree. SOA in the
middle approach is recommended. Initially it may add an SOA services
layer on top of the applications, until the vendors come up with SOA
solutions.
• SOA will not succeed without an Information Architecture and
service in place because, after all, SOA services use the same
information vocabulary.

Review checklist

86. Define SOA and WOA

87. What are SOA benefits?
88. Depict the relationship to BPM.
89. What is SOEA?
90. Answer the question SOA "to do or to buy".
91. List SOA design best practice process in conjunction to EA design.
92. What is the SOA evolution path?

Chapter 15

15. Strategic Planning and Enterprise

Transformation

The analysis and strategy specification process is typically executed by the
business strategy team as an Enterprise wide collaborative effort. Nevertheless,
as it significantly impacts the target EA and the Enterprise
Transformation planning and execution, the strategy specification process is
illustrated. At this stage, you may have already concluded that Enterprise
Architecture is a converged business and IT effort, too often left solely in the IT
care.

Once a firm's vision and objectives are sanctioned, a strategy needs to be put
in place to describe How to achieve them. Subsequently, the strategy and targets
are cascaded to all business functions and cross-departamental programs are
initiated to execute the strategies in co-ordination. The transformation program
includes the strategy execution programs, besides projects aimed at pure
architectural transformation, such as SOA.
In the context of an EA development, the term business strategy appears to
be incomplete because it looks like technology and people are excluded. For this
reason, the term Enterprise Strategy is preferred which, in fact, consists of the
Business, Technology and People strategies. Business Strategy defines what the
business needs to achieve, Technology Strategy, what technology aims to change
and replace, and People Strategies are for organization and cultural
transformation. The same result is achieved by cascading the Enterprise
Strategy to the EA framework tree.

Business strategy needs to deliver value to each and every stakeholder

beginning with the Customer, Owner, Employee and Company.

Figure 15 - 65 - The Enterprise strategy specification process
This can be, arguably, aligned to the company Balanced Scorecard analysis
of Robert Kaplan and David Norton which proposed four Enterprise
perspectives: the Customer's, Financial (Owner’s), Process (Company’s) and
Learning & Growth (Employee’s ).
To be properly implemented, the business strategy and its objectives must be
cascaded to all elements of the EA framework: Functions , Flows and the
Technology and People executing them. The strategy will be cascaded down to
the job description level. A sample Enterprise strategy specification process:
The Governance Function plays the leading role in the strategy execution
process. Strategic transformation may require organization redesign, an update
of the value chains and business models, process improvement & automation
and technology replacement.

Do Environment Analysis: PESTEL , Porter 's 5 Forces
Strategy and Enterprise Architecture are about long term thinking.
Strategy has to take into account, long term, the Economical, Political,
Social, Environmental and Regulatory forces in the macro-environment. The
analysis process will reveal Trends, Opportunities and Threats (O/T) which,
once known and acted upon, would permit the company to adapt to this
increasingly competitive world.
Identify your specific industry environment, your competitors, substitutes,
suppliers and customers’ trends and discover your company’s core competencies
and weaknesses… Do PESTEL (Political, Economical, Social, Technology,
Environment, Legal) and Porter’s Five Forces (Customers, Suppliers,
Competitors, New Entrants, Substitutes) analysis, both often used by business to
study the macro-environment. A PESTEL, Porter's Five Forces analysis and the
resulting trends and recommendations are given in the following:
PESTEL
Political and Regulatory/Legal
• increasing taxation trend
• new EU laws
• new economical super-blocks: China…
• growing likelihood of terrorist attacks
• privacy laws strengthening
• new financial compliance regulation

Economical
• expansion in new markets (China, East Europe…, Africa)
• reducing time to market
• industry consolidation
• increasing energy prices
• changes in own Value Chain for outsourcing and M&A
Social/Cultural/Demographics
• increase concern for Corporate Social Responsibility
• aging population
• growing need for remote work
• globalization
• travel to remote world spots
Technology Trends
• new customer satisfaction levels, in terms of service quality, service
discovery, usability, response time, availability and customer care
• growing amount of info (Data Architecture , Data Warehousing,
Business Intelligence, Content Management …)
• growing concern for data privacy, integrity and confidentiality
• increasing technology capabilities (processing power, storage,
network bandwidth…)
• mounting complexity
• accelerating rate of technological change (scenario modeling,
decision making, portfolio management)
• trend for virtualization technologies for Storage, Network &
Processing (On Demand/Utility Computing, Grid Computing, OS
virtualization, Blades…)
• growing requirement for converged networks and terminals (Internet,
telecoms, IP networks, broadcast, telematics …)
• need for continuous availability of business and disaster recovery
Environmental
• growing concern for Corporate and Social Responsibility (CSR)
(waste, packaging, radiation, recycling, re-use…)

Porter 's Five Forces
Customers
• Prepare for increasing proportion of aged customers
• Devise web buying and distribution channels
Suppliers
• Affected by super mergers and acquisitions
• Prices going up with green policies and petrol costs
…
Competitors
• Prepare strategy against new low entry competitors
• Design strategy to compete with high end operators
Substitutes
• Establish strategy to mitigate substitutes, reducing your market share

Do Company Analysis
Analyze the Value Chains and business models of the company, its financial
performance and targets, its organization and evolution, business processes and
current strategies and objectives.
Do a high level Business Process and Value Chain analysis. Do you need to
automate processes or improve the performance of key processes? Is there an
opportunity to specialize on a link in the value chain or else outsource it? Is there
a skills shortage (weakness)? What are the strengths of the firm? Financial
analysis will reveal how effectively business is conducted and will enable you
to establish new targets to stimulate investment. Marketing research will provide
answers with regard to new products or markets (segments) the company may
need to deliver and approach.

Do Stakeholders ' analysis
The company itself is often a neglected stakeholder, it has to be invested in
for its preservation because, without it, none of the other stakeholders can exist.
Legally, a public company has a separate identity from that of its owners.

Figure 15 - 66 - Strategy specified to benefit every Stakeholder
People (employees) are an important stakeholder and company asset, capable
of returning value for years, if properly invested in, or holding down your
company because of a culture of politics. For Each stakeholder, analyze ways to
enhance returns.

Outline Enterprise Vision, Goals and Targets
Outline the vision, goals of the company and in quantifiable terms, the
targets. This is an iterative process since goals must be tested against reality. A
vision must take into account strengths & opportunities, competencies and assets
but is as well, an ambition.

Specify Strategies
The results of the analysis (PESTEL trends, Opportunities and Threats (O/T),
Company Strengths and Weaknesses (S/W), process improvements, new Value
Chain and business models …) enable you to formulate strategies as actions to
be performed in the long term.
At this stage you have a vision and targets for the To-Be Enterprise. Re-
consider current strategies and morph them into new ones.
Develop strategies for:
Customers to
• integrate access channels and provide internet access and self service
• deliver new products and/or new market segments
Owners/Shareholders to
• deliver increased value for their investment (dividends)
• prevent risks and take advantage of opportunities
Company to
• transform the company for agility (flexibility, adaptability,
scalability …)
• prepare for growth (mergers & acquisitions)
• prepare for outsourcing
• reduce costs of operation
• enhance brand image
Community/Environment/Regulatory
• protect the environment, enhance community benefits
• comply with regulations
Employee (People) to
• Improve business and technical skills
• transform culture

Balance benefits between Stakeholders
This diagram should help the strategist establish an equilibrium in
formulating the strategies. None of the stakeholders should be left out in the
consideration of benefits returned by strategies.

Figure 15 - 67 - Balance strategies against stakeholders' needs

Check Strategies for Feasibility, Acceptability, Suitability
Feasibility: can you do it? Asses if the company has the resources and
capabilities (core competencies, assets, strengths) to deliver the strategies
Acceptability: is the potential cost in the realm of possibility? Is the strategy
serving the stakeholders? Decide if the strategy is achievable in terms of
financial returns and delivery timescales. Evaluate again the outcomes in the
light of stakeholders’ expectations (including community, regulatory) and
financial results (business cases).

Suitability: is the strategy delivering the goals? Verify the appropriateness

of a strategy, based on company's strategic goals (check against vision and
goals).

Cascade Strategy planning to the EA Tree

Figure 15 - 68 - Strategy cascade to Function, Process, Technology & People
Strategy, like Enterprise Architecture, can be thought in terms of Business,
People and Technology strategies.

Specify the Strategic Execution Roadmap & Mapping
This will be the Enterprise roadmap (see picture), the basis of the Enterprise
migration plan consisting of an Enterprise project portfolio executing the
strategies.
Analyze Enterprise Strategy and plan implementation in every Function. The
Business strategy and objectives should be cascaded to Functions, Flows,
Technology and People, top-down. Function specific issues are incorporated to
Function Strategies for inclusion in the overall Enterprise Strategy, bottom-up.

The company will most probably be reorganized to be more effective with

regard to the new orientation and goals. To this purpose job descriptions will be
redesigned to reflect the impact of new strategies. The culture may be enhanced,
new company values may be proposed. Technology will be affected by
innovation, simplification and virtualization.To achieve the future state, the
program will transform the EA entities: Functions, Flows and the People and
Technology resourcing the Functions.

Figure 15 - 69 - The Enterprise Transformation Roadmap process
Here is a sample strategic roadmap. The strategies map on the architecture
layers where relevant, as for example on the single page business architecture

Figure 15 - 70 - The Strategy execution roadmap
.

Figure 15 - 71 - A Strategy mapping on an Applications Architecture

Review checklist

93. List the phases of the strategic planning process.

94. What is environment analysis and what does it consists of?
95. Describe company analysis key activities.
96. What are stakeholders' analysis and benefits balancing?
97. Which are the inputs to strategy formulation phase?
98. What are the criteria to specify strategies?
99. How do we verify strategies?
100. Describe the strategy mapping process to the Enterprise tree.

Chapter 16

16. The EA Development Process and Best

Practices

This chapter will Endeavour to identify and summarize Best Practices in an
Enterprise Architecture development. Practices will be outlined at each phase of
a proposed process, which in itself becomes a suggested good practice. The
process, the result of a deliberate reflection act, was constructed from answers to
common sense business questions. Why Enterprise Architecture, what are its
economic drivers and benefits and what is the technology context? What are the
requirements and what shall the Enterprise Architecture deliver to you?

What do you need to set out even before you start? What are the critical
success factors and development strategies capable to guarantee success? And
how can Best Practices become Business As Usual (BAU) practice!
Practices are shown in a rather imperative manner, illustrated by a few
sample practices of my own. As a good practice, embed Best Practices in the EA
delivery process and make it an integral part of the Enterprise Framework next
to principles and technology evolution guidelines. Document the EA process and
enforce it using an Enterprise Architecture tool.

What is the value of Best practices
Best methods to achieve an outcome and guidelines to achieve best results!
• Result of our collective experience, lessons learnt from pioneers
• Afterthoughts and result of a deliberate process of
reflection, retrospective analysis!
• Good practices have to pass the test of time and trial to become

• Best Practices are a first step in building a rigorous process and
methodology to deliver a desired output.

Define EA Mission and Deliveries
The EA Mission Statement will capture unambiguously, for all audiences,
the essence of deliveries and development goals. For example:
“The program will deliver an integrated blueprint of all business domains
showing the boundaries and scope of the Enterprise, functions, use case
scenarios and flows delivering customer products and value to stakeholders. The
EA blueprint should describe the Enterprise in a hierarchical manner, enabling
‘drill down' from logical to technology level architecture and offering each
stakeholder its own views. It shall provide common architectural and design
principles, standards, guidelines and policies”.

Capture stakeholders’ requirements, determine scope
To manage expectations, first determine the scope of your development. Is it
an IT only architecture? Is it a SOA or a business process re-engineering? Do
you include your people organization? Is it a full EA development?

Identify stakeholders and gather requirements.

Common stakeholder requirements (add your requirements to this sample
lot):
• specific views for every stakeholder at each iteration
• link solution architecture to EA as Views at the next level of detail
• EA roadmap must be linked to the Enterprise Project Portfolio
• align technology strategy and roadmapping to Business Objectives
• provide traceability to Requirements and Business Objectives
• allow simulation of change impacts and Business Modeling

• show areas of bottlenecks, potential high cost or little yield
Capture all relevant business information which serves specify and align the
EA to the business model, strategy and objectives.

Build the Business Case for Enterprise Architecture
Organizations must be prepared to perform a thorough analysis to determine
the benefit of the EA investment in the long term.

Consider the EA an asset which, once in place and properly maintained, will
return value for many years since the investment in EA can be leveraged over
and over again to pay back dividends. The EA asset offers your company a
competitive advantage by providing simplicity, alignment, strategic planning and
as a result, cost savings, increased revenue, agility to change and customer
satisfaction. Conservative quotes from different industries vary between 10-30%
reduction in cost and time to market.
Nevertheless, consider the initial investment and migration expenses. The
Business Case will need to talk the language the decisions are made in, the
language of finance.

Get Support from Top Level Management & Business
Use the Business Case to get support from your top level management and
stakeholders.

Quite often, companies operate in silos. To reduce the decision tree, units are
often empowered to make up their mind in isolation, with regard to business,
strategy design and technology selection. To penetrate this silo culture, the
support of top level management and business stakeholders is essential. There is
also the divide between business and IT. EA will help attenuate this divide, in
the long term, by aligning the organization to work towards common goals.

Build the EA Governance team
The Governing Function should include members of the management board,
senior business and sponsor, e.g. its advocate, and the EA lead architect. The
Governance should be able to make cornerstone decisions with regard to
framework, principles, planning and prioritization and facilitate investment and
funding in the Enterprise. The Enterprise Architect’s lack of empowerment is
often the motive for EA failure, since the EA lives only on paper.

Nominate the EA core and virtual team
Assemble an Enterprise Architecture core team with a knowledge of
Business Strategy, Business Processes, BPM, IT, Enterprise Architecture and
Frameworks and not in the least SOA, BPMS and Web Services technologies.
The EA architecture team shall define the EA Framework: layers, views...,
principles and, after the first iteration, police further Enterprise developments for
compliance to the EA.
Nominate architects or domain experts, with a knowledge of your Business
Processes and IT Applications for each main business function or department.
They will constitute the virtual EA architecture team. Negotiate their availability
for the initial design phase.

Specify an Enterprise Architecture Framework
The EA Framework is a structure describing the Enterprise decomposition
tree at all architectural levels and from all perspectives. Select layers you will be
looking at and the architectural and technology principles guiding the
specification of the target EA.

The framework should not define the component architectures, but solely a
frame joining them, showing component placeholders. The framework enforces
the specific system views and principles that apply consistently to all component
architectures. Request the function architects to provide the same system views,
with same conventions and constraints, in order to interconnect them in overall
Enterprise wide pictures observing common architectural principles.
The EA framework is, as well, the backbone of the whole program as it
defines the component Functions and the way they fit into the whole. Once you
know the components and the work breakdown around them, a program plan can
be devised as a portfolio of component projects. This will give you and
everybody else the confidence that it can be done.

Select an EA Tool set to support the framework
An Enterprise Architecture tool should document the whole process and
store all components and artifacts from the beginning. A repository, centralized
or distributed, is essential for documenting and reuse of the EA entities.

The EA tool should enable drawing business processes, data architecture,

organization charts, applications and IT infrastructure diagrams, in various
notations. It should provide navigation between artifacts, at various levels of
detail, web rendering, change control, requirements tracing, collaboration, access
control, regulatory compliance features, link to other existing tools and databases
and be able to store artifacts as business objectives, strategies and organizational
information. It should be able to store both current and target EA.
Various specialized tools exist to support modeling, repository and
collaboration to design organizational structures, business processes, information
flows, applications and technology infrastructure and link them to business
strategy. An aggregated set of tools will probably serve the goal best. To
properly present and interact with such dissimilar information, the various types
of data have to be recognized and the proper tool launched to act upon the data.
This is similar with the file type extensions of your operating system associated
to various applications. Or it is analogous with the microformats operation of the
semantic web world. The EA tool should provide the GUI navigation and serve
launching other tools, depending on the artifact type.

The EA team should embed the framework – graphical interface, object

metamodel, principles…. - into the tool.

Outline a Design Strategy
The recommended practice is to establish a Design Strategy: Bottom-
Up document As-Is, Top-Down design To-Be, and middle-out use
SOA paradigm for integration of Bottom-Up and Top-Down.
Top-Down MDA approach to model the Value Chain
This approach supports the development of the Business Process
Architecture from the Value Chain. Services, in the SOA sense, may be
implemented from any business function, not necessarily IT. A service could be
built by a 3rd party or outsourced from another company. By deploying SOA
you arm your Enterprise with flexibility and prepare it for rapid change.

Bottom-Up discovery of existing technology and model ERP processes
May be executed in parallel with the Top-Down design and would consist of
discovery and documentation of the Current architecture and technology.

Design SOA in the middle to wrap Applications as Business Services
Would support the Top-Down and Bottom-Up approach integration by
orchestrating workflows out of business services obtained by wrapping existing
applications.
SOA may be built on an Enterprise Service Bus (ESB) wrapping legacy
applications, deploying Business Rules and Process Engines for orchestration,
and employing ESB horizontal services as reliable transport, security,
transactions service life cycle management, and Service Level Agreements
(SLAs). SOA offers the flexibility to build your Enterprise from Off-The-Shelf
(OTS), best of breed applications. A service is a Function with a request (service
solicitation) and response (service provision) behavior. You have to:
• Specify Functions as Services
• Design transparent, layered Services
• Adopt a location agnostic, distributed architecture of Services

Apply Architecture and Design Principles
• Adopt a hierarchical, layered, modular, service based architecture
• Functions at level one are partitioned in sub-functions that are still
composed of Process, Technology and People Layers.
• Specify non-functional capabilities as Performance, Scalability &
Availability
• Specify Security controls at design time
• Assess threats, their probability, estimate impacts and specify
security policy; assess intrusion points and design security zones
accordingly and specify for each zone security controls, access rules and
roles and Access Control Lists (ACL).
• Design Services to support testing, lifecycle
• Design for deployment, upgrade, retiring and recycling.
• Specify design and drawing guidelines
• Use a tool or combination of them: a tool for Enterprise Architects
and a standard one such as Visio for business analysts to design process
and technical architects to document infrastructure
• Establish an intranet site for all other EA documents and EA web
tool publishing
• Use same modeling methods/diagram types for all EA artifacts same
symbols and naming conventions, colors, diagram size, diagram
identification box, logo…
• Align levels of granularity (level 1, 2, 3…) between diagrams
• Map input/outputs between diagrams

Specify an EA execution strategy
Some good practices to have in the implementation phase:

Prioritize to deliver the urgent fixes for the Enterprise
This is a good policy to get acceptance, to make the business case for the
Enterprise Architecture by firstly initializing those EA projects seen by the
business as a priority.

Leverage existing applications and infrastructure
Any design that is worth considering, should strive to leverage the large
investment that has already been made in existing applications. Ideally, these
systems can be re-used without significant re-investment in development. The
design should provide an approach for integration of these systems.
EA and SOA should be implemented opportunistically, taking advantage of
the existing technology lifecycle to avoid artificial, architecture only generated
expenses.

Do ERP modeling to discover the embedded business processes.

Work with Suppliers to package applications as SOA services
A SOA approach will be more successful if your applications’ vendors
cooperate to deliver their applications as services accessible through defined
interfaces and standard protocols.

Design, Plan and Implement iteratively
Construct a plan taking into consideration the stakeholders’ short term
priorities. What is characteristic to the EA is the continuous delivery process, in
iterations to keep the team focused on incremental stages in order to deal with
complexity.

Use an Agile Processes (AP) approach
As Enterprise Architecture development is a long term process. Use an agile
methodology with frequent deliveries and stakeholders' consultation.
Nonetheless, a minimal process and plan is necessary to measure, manage
and guarantee progress, quality and timely deliveries.

Establish SMART Deliveries, CSFs , KPIs
Critical Success Factors (CSF) and Critical Achievements must be estimated
upfront. Once delivered, the EA will be closer to realization. CSFs represent
milestones in the delivery process.
• Define SMART, measurable deliveries
• Define KPIs for the EA Development Process
The goals, defined for the To-Be architecture, in line with the organization’s
strategy, must be quantifiable. Once the EA program has defined its goals, it
needs a measure for progress toward these goals. Key Performance Indicators
(KPIs) are quantifiable measurements, agreed beforehand, that reflect the
progress towards targets. KPIs must be tracked against a plan and embedded into
a dashboard to enable you to assess the state of the Enterprise Architecture
development, at a glance.

From a business point of view, it should be proved that the EA program

creates value. The Balanced Scorecard Model aligns the Enterprise objectives
with four Enterprise viewpoints: Customer, Process, Innovation and Learning
(People), and Financial (Owners). The four views define, describe and capture
the goals, KPIs and initiatives for each area. The EA value delivery can be traced
at a high level, with this tool.
The key benefits indicators table, in the business case chapter, should be
used to fill in the perceived benefit % column at each iteration to estimate
returned value. The EA maturity model should support the KPI definition for the
EA progress measurement.

Agree Best Practices
Here are a few:
• Establish the EA Scope at the whole Enterprise, not only IT!
IT is just a part of the Enterprise. There are many other reasons the
Enterprise does not perform, like people and work culture. Lack of recognition
and empowerment can be more damaging than technology.
The EA development includes the strategy specification and mapping effort,
process improvement, company re-organization, roadmapping and planning
towards the To-Be state, the blueprint design and documentation.
• Manage early Cultural and Organizational transformation
Enterprise Architecture removes silos and duplication. For a merger, a main
trigger for a converged Enterprise Architecture effort, there will be human
redundancies and technology platforms to be scrapped even though they have
not reached the end of their life cycle. People will feel threatened, new platforms
will require training.

As such, early in the process, propose changes necessary to align the

organization to the business functions structure. Organizational change is one of
the most difficult aspects of change since it involves people. The best way to
avoid resistance is to ensure that people are prepared and motivated to support
the change. Involve people from the beginning, clearly explaining the reasons
for the change. Having a clear strategy, direction and vision will help. Involve
Change Management expert teams, communicate goals, reasons, solutions, and
provide a transition path for people.
• Sell, Not Tell
Do not tell people what to do: find out what their issues are and demonstrate
how the EA works for them.

Design the Business Functions and Flows Architecture
Specify the business functions tree (Functions ) and business process map
(Flows) and ultimately the Single Page Architecture (logical architecture). This
will enable stakeholders to understand the Enterprise structure and operation
and how their own work fits into the whole. The functional Single Page
architecture is also the frame for As-Is discovery and To-Be Enterprise design.
Use standard industry process frameworks or the Business Reference Map and
current organization chart to derive main business Functions.

Discover As-Is Using the Business Reference Map and framework
layers
Any Enterprise has an existing architecture, whether documented or not.
Before designing a new architecture, the current architecture must be
documented. This will help you measure the gap between As-Is and To-Be.

The Bottom-Up approach is based on documenting the systems already in

place i.e. applications and the legacy technology systems to determine your
existing Business, Processes and Technology layers. Do ERP modeling.
As-Is EA evolves as you work, with all projects modifying your Enterprise.

Cascade Strategy objectives and initiatives to EA tree
Map Strategies and goals targets Top-Down, that is, cascade them to
Functions, Flows, Technology and People. Do the reality check (are they
realizable?) and re-iterate, if necessary, to soften and prioritize targets.

Introduce strategies, Bottom-Up as well, to solve existing issues in

processes, technology and organization. Harmonize with Top-Down vision
strategies in a single view, ensuring that both business objectives and practical
issues are resolved in the execution phase, without additional projects and
resources.

Sketch the target Enterprise state
Specify the To-Be Functions, Flows and Layer Architectures taking into
account the Business Strategy, Mergers & Acquisitions, Architectural principles,
technology transformation guidelines and roadmaps.
Enterprise Architecture is a continuous process of improvement, adaptation
and managing of the gap between As-Is and To-Be. Business Objectives will be
moving, perhaps, faster than your EA development.
Prioritize deliveries and iterate, applying each time the 80/20 rule (80%
functionality with 20% effort). Think of a spiral, iterative process.
An iteration starts from its own requirements and has its own deliveries.
Subsequent iterations would build on prior progress to supply new functionality.

Most iterations shall be planned in advance, although the farther in time, the
lower the detail.

Assess Gap between current and target states, establish roadmap
For each Function, Flow, Layer and View assess differences, gaps, effort
(resources, time, costs). For each serious gap do a business case to assess
feasibility and priorities. Specify the transformation roadmap.

Establish project portfolio and program plan
For each iteration, do the whole cycle from requirements to implementation,
always building on the previous iteration or cycle.
Fully involve the EA program management team and office at this stage.

Establish EA operational governance
After the 1st iteration, nominate an EA operational governance team to
supervise and sanction all new developments, modifications and additions to the
Enterprise for compliance to EA. The team will insert EA checkpoints in all
relevant business processes and will review all new applications and capability
developments for compliance.

Execute Enterprise transformation iteration and evaluate EA maturity
Use agile processes, iterate, deliver often and frequently consult the
stakeholders.

The EA maturity has to be measured now for the EA development,

exploitation and maintenance phases.

Review checklist

101. Depict the process of EA design and implementation.

102. What are the main design strategies?
103. Enumerate key execution strategies.

Chapter 17


This chapter describes a logical sequence of steps and deliveries for the
development of an Enterprise Architecture. Students of EA and practitioners at
any level, may use this exercise to build their own baseline EA, following the
conceptual case study illustrated in this chapter.

The Design process steps
The EA design process for a minimal architecture can be roughly illustrated
in the picture in a few numbered steps, around the metamodel artifacts,
beginning with the documentation of the firm's mission and vision followed by
the design of
A. Enterprise context and key stakeholders' interactions or Use Cases
B. Enterprise Lines of Business (LoB /Products) and Value Chains
C. Business Functions Map
D. stakeholders' interaction scenarios as Business Flow s over
Functions
E. business information map with information items from Business
Flow s
F. organization chart resources (roles/units) alignment to Business
Functions
G. the architecture of applications executing the Business Flow s
H. data architecture, implementing the business information
architecture, showing data flowing in applications exchanges
I. IT technology (desktops, platforms , servers, and
storage/DBMSs/SANs)
J. networks (LAN/WANs, data and voice) providing interconnectivity
K. application inventory database (configuration database)
L. preferred technology standards for applications, technology,
networks

Figure 17 72 - The EA metamodel diagrams, layers. entity relationships

An EA development exercise or virtual case study

Specify Enterprise Mission & Products, Vision, Strategy and Objectives
and other business artifacts as business vision, planning, business and
operating models... This is the right time to get the business involved and
document all their requirements.

Document Stakeholders ' Interactions and internal requirements
Main stakeholders and Use Cases for an Insurance company are shown in
the figure. As the EA progresses, extend the process to all concerned parties.
Include suppliers and partners, product development, marketing, IT solutions
and services, strategy, supply chain, sales and services, operations…

Figure 17 - 73 - Context Diagram, Stakeholders ' Interactions
Identify internal requirements. Consult your main internal stakeholders (see
picture) first. Collect requirements and trace them along the whole process.

Figure 17 - 74 - Stakeholders ' requirements from Architecture

Design the Business Functions Map
Define your Enterprise main Functions (level 0) and sub-functions as (level
1, 2…). Map functions on the Business Reference Map. This template is used to
map other EA Layers and Views, as well. An EA tool will ease the mapping
process by providing hyperlinks and a repository for Functions, their attributes
and in general for all the artifacts of the EA. In this design example, only the
Operations function is further analyzed. The key functions are: the Portal,
Product Catalog, Orchestration, Authentication and Authorization, Sourcing,
Warehouse, Billing and Payment…

Figure 17 - 75 - Specify the Business Functions Map

Design stakeholders' scenarios as Flows over Functions
Identify, build and document your Enterprise main Use Case Flows over
Functions. The diagram can typically be a sequence or swimlane diagram, with
business functions as participants in lanes. Here is a sample flow: a customer’s
book ordering process:
• Customer Accesses web site
• Extracts book information
• Logs in
• Is authenticated, authorized
• The business orchestration routes request
• Check stocks (book is available)
• Payment is requested
• Customer approves payment details
• The warehouse sends book to the mailing department
• The mailing department delivers book

Figure 17 - 76 - Specify the Product delivery Flow over Functions
Initially, the process architecture should be described at a high level for
enabling understanding. and as the EA work progresses the processes should be
documented in detail for improvement implementation. The Flow can be
implemented as orchestration executed in Business Process Engines
interconnecting the processes in applications over an EAI or ESB middleware.
An external Business Rules engine may customize the business processes
execution.

Draft the Single Page Architecture

Figure 17 - 77 - The Single Page Architecture , key Functions and
connections
Document in a single page the key business functions, interconnections and
interactions to customers and other stakeholders. The connections describe
information, control transfer and material moves.

Specify the Applications executing processes in Functions
For each Function fill in the IT Applications executing processes.

Figure 17 - 78 - Map IT Applications
At this stage, in an iterative manner, the real processes embedded in
applications can be documented. A tool will ease navigation between the
processes, applications and the information in the same Function. In this
example, a direct mapping approach was chosen where processes and
information representations are overlayed on the parent Functions diagram. As
you can see, Portal, Content Management, SCM suite, Warehouse applications, a
BPM engine, Payment application and an MDM hub are involved.

Draw the Infrastructure aligned to Applications

Figure 17 - 79 - The EA Infrastructure View , servers and storage
The Infrastructure View (servers, storage, data and voice networks) should
be mapped to processes and applications. In fact, an workplace based grouping
is also recommended since infrastructure is specific for Data Centers, Call
Centers etc.
Applications and Infrastructure are composite Views since they can be
further decomposed. The framework is open as it allows for the introduction of
new entities when the stakeholders request it.

Map Information entities to Functions

Figure 17 - 80 - Information View , structured around Operations
Functions
Information Architecture: there is information in and about every Enterprise
Function, e.g. about employees, customers, partners (people), technology and
processes. There is information in every Layer, View or Product. The
information is transported by Flows over Lines/interconnections. Every piece of
information should be managed by an Enterprise Flow, and as such it should
appear in the Business Flows diagrams. Even the Enterprise Architecture
documents are information about the Enterprise, ultimately the Enterprise
knowledge base. The Information Architecture consists of different
Views according to the Information type: customer, product, financial… In most
data architecture approaches, by default, master data (in Master Data (MDM) or
customer data (CDI)), refers to structured customer and product data rather than
"content". Information is owned by a Function and consumed by Functions in
various (CRUD like) relationships. In the target architecture, the information,
once discovered, has to be rationalized.

Map Organization units to Functions
People execute processes or interact with them in order to deliver the
outcomes.

Figure 17 - 81 - The EA Organizational View mapped to business Functions
Processes require resources executing them such as people roles and units.

Then the roles with their job descriptions would be filled in with real people
in the Organization Chart. The Functions and the roles belonging to them can be
grouped in different modes to specify the desired target organization depending
on the organizational style of choice. For instance a customer oriented
organization will stress the sales, marketing, customer relationship, analytics
side of the organization rather than the operational side.
Functions are decomposable in component sub - functions. At some level,
the decomposition reaches the atomic (indivisible) level. Organizations should
not have atomic Functions divided between two or more departments. This is
one of the principles of aligning the target organization to your Enterprise
Architecture. For the As-Is architecture, people teams should be assigned to
Functions which will be subsequently grouped in organizational units. A
complex mapping between the organization chart and the Business Functions
Map usually results.

The Organization chart and template is described in the Organization design
section.

Link all Views in the EA framework
This would be the resulting picture if the Business, People, Technology
Views are overlayed. The Functional Architecture will consist of all Flows over
the business Functions . The Single Page EA is an essential view of the
Functional Architecture.

Figure 17 - 82 - All Business, People & Technology Views
The Applications Architecture consists of Applications and their
interconnections; it is, in fact, an integration architecture. The Infrastructure
Architecture is structured more conveniently on the workplace: office, Call
Center, Data Center, Warehouse etc. A good organization would support the
optimal mapping of the business, applications and technology architectures to
the organizational chart.
Additional matrices of interconnections can be drawn if necessary. These
architecture layers should be designed in As-Is and To-Be views. The EA
Layers and Views are linked inside the Functions stacks. Navigation between
Functions, Flows, Lines, Layers (and Views) will be enabled by an EA tool
which inherently will provide this overlay.

Specify Target Objectives and Vision for the Enterprise
Establish the business, technology and organization vision and objectives to
determine the To-Be state of the Enterprise. The Enterprise Strategy, including,
business, technology and people strategies consist of directions, describing How
the business achieves its vision and objectives.

Cascade the To-Be Enterprise objectives and performance KPIs down to

each Function, Flow and Layer (People and Technology) of the Enterprise tree.

Design the target EA, employ SOA paradigm
Sketch the target EA. At this stage, SOA, as a style of architecture, is key in
deciding the target EA configuration. Specify SOA services by packaging
existing functions and corresponding applications.
Specify an integration technology. Initially a business orchestration
technology and ESB will enable the Flows to use these services. SOA services
become a new layer on top of the existing applications. In time though, as
suppliers provide applications as SOA services, this transitional layer should
disappear.

For each Function, establish the local strategy and targets to be incorporated
to the Enterprise wide strategy and objectives.

Assess gaps and devise the Transformation roadmap and program
For each EA framework entity (Function, Flow, People roles/units…) assess
impacts and perform gap analysis to discover, bottom-up, existing processes,
technology and people issues and requirements. Determine departamental
targets, consisting of a number of belonging Function targets.
Establish an Enterprise Transformation roadmap, a program (with time
schedule and resources) and a Program Management Office (PMO) to supervise
implementation.

Instead of Case Studies
For some time now I vowed to illustrate this work with Case Studies. But
the cases I studied were only partially covering an EA development, i.e. were
incomplete. More, they seldom used one of the accredited methods (for good
reason,) if any and it was hard to extract any valuable lessons.

My experience comes from working both inside an Enterprise, and within

consultancies in order to build an EA. The Case Studies provided by the
experience accumulated in the knowledge base of consultancies were hardly
relevant for further work since they had no method in common. Nobody
synthesized the information in a methodology. There was never time for that.
Zachman never brought us too far. TOGAF is a process and advisory
document that can help if you know what you are doing, but not otherwise.
Fortunately, in the telecom environment we had eTOM but it did not help with
the IT architecture.

In the Enterprise, there were frequently a few improvement efforts taking

place at the same time. I suspect this happens in most Enterprises. Here they are:
• a Business Strategy development and alignment of the Organization;
typically conducted by reputed consultancies; the resulting strategies
were cascaded to organizational units and job descriptions and stayed
there. The results were never synchronized with technology or processes.
• The Six/Lean Sigma process improvement initiatives, under internal
or external leadership of business consultancies, were working hard
mainly to improve human processes, not providing IT applications
integration or standardization.
• The EA development, relegated to IT only, seldom produced more
than a few diagrams with applications, looking very dissimilar from
group to group, Enterprise to Enterprise. The EA was never aligned with
the Process Improvements efforts and not at all with the Strategy
alignment process.
• There were many uncoordinated efforts at Lines of Business level
proving that the Silo organization makes its impact.
• The sponsorship of the EA project was never high enough to include
business and align all these efforts. The Strategy design and cascade
process, typically happening at the CEO level and below, has had no
technology perspective.
Hence, it is hard to present a definitive Case Study. Many EA efforts are
never finished; the results are poor and unused; the teams are often (self)
disbanded; the EA architect moves into a technology standardization role and
expert IT advisor. Consultancies have not provided much relief for lack of
method.

Review checklist

104. List the key steps of the EA design process.

105. At what stage in the process, is it proper to design the Single Page EA?

Chapter 18

18. Framework use cases for M&A,

Outsourcing. ITIL ...

The Single Page logical Architecture describes the operation of the
Enterprise in terms of business Functions and interconnections. It offers a logical
view, useful for comprehension, value chain analysis, business model
establishment, current EA discovery and target EA design. The Business
Functions and Flows maps are aligned with the Single Page EA..

A user should be able to select a business Function part of a an organization

department, at a specified level of detail, to investigate process issues. Then
navigate to the affiliated applications and technology, to discover the activity
they perform.
Alternatively, a user can select only the narrow View, a Function to analyze
for instance, how re-insurance works. By navigating along the Function stack,
the user finds out who is responsible, what technology is employed and what is
the roadmap for change for the next year.
Since Views can be built in response to any stakeholder's concerns, the four
layer architecture, designed in the first path, is rapidly augmented to cover all the
aspects of an Enterprise. An EA tool is essential for complex selections,
subsequent navigation and access control.

EA Framework use for Investment
Once elaborated, the Enterprise Transformation plan would establish the
priorities and timetable of the investment to implement the business objectives
and strategy. The transformation plan already takes into account the technology
replacement budget, innovation program costs… Any new investment proposals
should be evaluated in the context of this existing and approved Enterprise
roadmap and transformation project portfolio so that all implications on other
projects or final objectives can be assessed. The investment would be assessed
at the people and technology layers delivering a capability or a new product.

EA Framework for IT services management (ITIL ) architecture
EA is sometimes associated to ITIL , that is, IT service management
architecture. To start with, the IT architecture only describes the IT department
structure and operation, and as such is not an Enterprise wide IT Architecture ,
but the illustration of the IT department organization and processes. First of all,
the customers of the IT are the business units rather than the external Enterprise
stakeholders. But the EA framework may be applied successfully to any
department of an Enterprise. The GODS structuring method:
• GODS IT Operations (O) is Service Delivery in ITIL , consisting of
o Infrastructure operation, maintenance, upgrades and optimization
o Applications maintenance and upgrades, back-up, log cleaning; (note:
business people operate applications not IT people)
o Availability & Capacity Management
o Service Level Management
o IT Service Continuity Management
o Release & Configuration Management
o Change Management
o IT Architecture documentation
• GODS IT Development (D), project activities, would be SDLC in
ITIL
o Applications: software design (SDLC), new solution integration and EAI
deployment
o Infrastructure : new capability Design and Planning, Deployment
o Project management

• GODS IT Support (S) is ITIL Service Support
o Incident, & Problem Management
o Helpdesk
• IT Governance consists of boards as :
o IT Management committee
o IT Architecture , Strategy and Roadmap
o IT Investment committee
IT Flows over IT Functions constitute the IT business architecture. The
Enterprise applications, while serving the business purpose, are not serving the
IT key functionality and thus they are not part of the ITIL department
Application views, as opposed to Helpdesk, monitoring, upgrading applications
etc.

EA Framework for Security Architecture
Enterprise security architecture is, in actual fact, about controlling and
protecting access to the Enterprise assets. For that, a strong concept is the
"perimeter". We surround an asset, or a group of assets, with a perimeter at
which we install protective measures.

The logical security architecture begins at the business level by discovering

the information, processes, and other artifacts like business strategy and
planning, to which access needs to be managed.
The next step is to devise the type of access (Read, Write, Update…) for
each role, and an Access Control List (ACL) for the asset. People and systems
would be assigned roles.

The access type: it can be physical or remote, over networks particularly

with regard to IT.
At the Business Layer, an Actor would be assigned a role and specific rights
with regard to business artifacts and process execution.

At the Applications Layer , these rights would materialize in Access rights to

content, structured data and application (right to reverse an EFTPOS
transaction, for instance).
At the infrastructure layer, the rights to manage platforms, OSs, servers,
storage and networks would also have to be controlled by similar mechanisms.
Actors are assigned roles with standard rights to infrastructure assets.

The Enterprise assets, become components of the Security Architecture ;

they should become objects in the EA repository, having a description of access
rights for various roles. Assets belong to business Functions .
At the technology layer, access rights to non-IT assets (paper documents,
equipment…) must be established. Security must be also enforced for real estate
and facilities with access controlled at the perimeter around workplaces,
especially at gates, doors and cabinets inside buildings.

Nevertheless, before costly security systems are put in place (such as video
cameras, 128bit encryption etc.), a threat and risk analysis would be performed
to learn how often and how damaging could a threat be. Once the potential loss
analyzed, an estimate of the worth of the security method and system could be
produced.
At the people layer, security access cards and remote access authentication
tokens could be provided besides passwords.

For remote access, VPNs or SSL with encryption for information integrity
and confidentiality should be utilized. Measures should be put in place to detect
Denial of Service attacks and Man in the Middles message modification.
In summary, every component of every EA layer should be analyzed from a
security standpoint and accordingly protected, given the level of threat and
potential damage to the Enterprise.

How to design your Enterprise around the customer
• The Business (Functions) Reference Map allows a good modeling of
the customer interaction.

Figure 1883 - A sample customer's interaction navigation scenario
Some of the following business activities have to be strengthened to
transform your organization into a customer centric one.
• Market research (customer needs, trends, competitors' products)
resulting in customer segmentation, new product concepts.
• Market campaigns based on research to attract prospects
• Customer interaction at the Portal, Shops, Call Centers…
• The Booking/Reservation/Subscription/Application for Product
• Customer Service and Relationship Management for customer
interaction history, personalization, product changes, incentives, loyalty
• Service Authorization and Access
• Service usage (downloading, therapy, access to show, transport…)

EA Framework use for Mergers and Acquisitions
The starting point is the existence of two different As-Is Enterprise
Architectures, even if not properly documented. The aim is the development and
evolution towards a single Enterprise and EA. This is a long term process,
finished after the formal merger. To control this process a formal common
program has to be established, before the merger, with activities described in this
section. By looking at the EA framework it becomes apparent that you have to
align
• the Business layers of the two Enterprises:
o establish the new common Governance of the merged Enterprise
o evolve towards a single mission, set of products, market segments,,
brands
o design a single vision, strategy, objectives
o establish high level logical architecture (business functions and flows);
specify common Functions such as operations, shared support and
development services; analyze outsourcing at this early stage
o rationalize external stakeholders (banks, suppliers …)
• the Technology layer: after discovering the existing two EAs,
rationalize and standardize the Applications and Infrastructure platforms
to serve the functional architecture (Functions and Flows). Decide on,
merge and rationalize:
o ERP, CRM, SCM…
o customer services and sales channels
o main product applications
o Data Warehouse, Business Intelligence, reporting
o B2B platforms
o Knowledge and Content management
o Voice and IP networks, email and printing architectures
o Office technology (PCs, mobiles, Helpdesk, IT support)
o Non IT technology and facilities: rationalize real estate, parking…
• the People layer:
o manage change (expectations, redundancies…)
o align organizations to the same EA business functions;
o begin cultural transformation: choose common values, ethics…
o design common communications channels and technology
o align payroll levels, recruitment standards…
• design common EA Views, such as
o Financial/Accounting functions, flows people and technology
o data architecture (vocabulary)
o security
o planning

EA Framework use for Outsourcing

Outsourcing, a fast growing trend, offers the flexibility to choose the best of
breed service and cost effective supplier. It could be justified by a few factors:
• reduced costs of service compared to the in house TCO
• enhanced reliability and quality of service as a result of clients' usage
by and feedback
• improved response times and productivity through supplier's
specialist expertise
• faster time to market due to the new service deployment time
• elimination of longer internal feature development cycles
• minimization of the HW/SW infrastructure maintenance costs
• reduction in real estate for people and machinery.
Moreover, it allows you to focus on managing the key business functions
only and deploy an "on demand" model of usage rather than build, operate and
maintain, in-house, a service you seldom consume (recruitment for instance).

Drawbacks: the formal, contractual way to address a new requirement,

especially when you missed the opportunity to formulate the feature at
acquisition. Not all functions can be easily outsourced. The more connections
are necessary, at human and technology levels, the more difficult is to outsource.
Another impediment is the fact that there is typically little understanding of the
existent service boundaries, requirements, costs and profitability. As such
decisions are the result of "intuition".
Outsourcing exists at business process level (BPO), IT application level
(SaaS), infrastructure (data centre), function or department level (helpdesk, call
centre), or combined under a managed services agreement. In general, it is
employed when specialized skills are required and it is not your core function.

You already outsource development to contractors, maintenance of the
mainframe to suppliers, business strategy development to management
consultancies, IT support to specialized IT firms, call centers to India, payroll to
China, HR to specialized agencies and so on.
Enterprise Architecture and SOA would prepare the ground for outsourcing
by showing all parameters of a Function starting with the process, technology
and people belonging to it, the costs and KPIs associated to it etc. The Lines
would describe the interface to other business functions. The EA framework
would support a rapid transition to outsourcing at all layers: Process,
Application, Infrastructure and People.

The Operations, Support and Development functions may all be outsourced

depending on your business model. That is, the way you decided to make money
would stress specific links of your Value Chain, leaving out others which can be
outsourced.

EA Framework use for a Start-Up Business
How would a Small or Medium Business (SMB) adopt EA? A simplified
framework can be used as a guideline for entrepreneurs to plan and build the
new company. The EA framework already contains the main aspects an
entrepreneur needs to consider:
• The business architecture layer is to be determined first:
o the product, the business mission
o the vision, business strategy and plan (how to get there), forecasts
o Value Chain and business model (what markets, customer segments,
pricing, costing, core capabilities etc) to serve the mission
o typical stakeholders: partners, suppliers, financial institutions
• define Governance, type of ownership such as Sole Trader,
Partnership … and decision making: the managing team roles and
responsibilities
• Specify GODS functions in terms of activities and required resources
such as people and technology and estimate costs for each and every
function
o Operations: sales and services, inbound/outbound logistics, customer
distribution channels, manufacturing
o Development (R&D, product and capability development) functions
o Support functions ; decide their business model (how do they produce
value to the company) and outsource if necessary
• Select basic technology for each function, deploy an ERP, use
managed services or a plan to do this
• Sketch key aspects: locations, data, security, planning, required
performance (from benchmarking data)
Produce the business plan including all the above.

Review checklist

106. Describe Security Architecture.

107. Explain the process of application of EA framework to ITIL
108. Describe the interaction of the customer with the Enterprise.
109. How do we use the framework for M&A?
110. How could be FFLV used for outsourcing?

Chapter 19

19. The EA Governance , Program and the

Architect role

EA Governance
The EA should be used across the entire company in various ways, to
support learning, making decisions and investments, designing new products and
capabilities and do strategic planning.
EA compliance checkpoints and templates should be incorporated into all
relevant business and IT processes:
• The Product/Capability development process will observe
enforcement checks at each milestone
• Projects will have milestones checked against the architecture
deliveries templates.
• Roadmapping process aligned to EA
• the Investment process to consider the Enterprise Project Portfolio
and technology selection to EA technical standards
An EA compliance team should observe and police all solution architecture
development for compatibility with the EA .

Departments shall:
• design their own architectures using the same tools and conventions
• provide architectural Views to the overall Enterprise Architecture
• interconnect their architectures at reference points agreed with the
EA
• observe common architectural principles and technology standards in
design
Suppliers should be distributed a version of the EA architecture so that they
may include the required functionality, interfaces, protocols, roadmap and EA
technical standards in products. The Business improvement activity should be
devised to take into consideration: process, technology and people performance
at the same time.

Figure 19 - 84 - EA governance
EA should provide mixed business-IT governance, compliance, program
management, administration teams and Enterprise Architects to lead the EA
workstreams and supervise the key EA domains of activity.
The business and IT governance should be adapted to the new SOA
structure, to enable ownership and operation of the business Services by
common business and IT teams. This deserves a discussion: the business
Function as such contains business processes, information and the Technology
and/or People executing the processes. But there are different teams and
managers for business Functions and IT. An explanation is the existence of the
separate IT organization delivering shared services. While technology is key in
supporting business processes and in delivering business objectives, the IT team
supporting this specific technology may have other priorities coming from the IT
line management. A straightforward remedy would be that the people operating
the technology would report directly to the business Function and in dotted line
to IT, to enable coordination with the rest of IT for technology standardization.
A solution is to partition the IT department into units, reporting into broader
LoBs, except for the few truly shared IT and EA central functions. The ultimate
goal is to unify the business and IT teams and their objectives, inside the
business Function.

The EA project organization and funding
Is EA a project or Business As Usual (BAU) activity? EA, ultimately
delivers an asset, a capability. A project has to be initiated to create the
capability in the first place. Afterwards, a BAU function and team must be
established to manage and upgrade it. The EA is no different. A project will
deliver the EA in an 80/20 manner (functionality/effort). The project should
transit and deliver into a BAU team.
The EA project should be organized in phases and staffed accordingly:
• Planning phase: determine scope, iterations, resourcing and
governance
• Overall EA set-up phase – Architecture + program support group
o Specify rather than choose the EA framework
o Design the key EA layers and views
o Specify the vision state of the Enterprise
• Design and Implementation of iteration N – multiple
teams/workstreams
o Discover As-Is views
o Design End and transition States
o Plan, resource and Implement state for each workstream
• GO BACK TO Design (after reviewing first two points)
• Form and handover to BAU team
The BAU EA team should follow the same design process with Solution
projects. The main tasks of the team would be to coordinate the work done by
Solution Architecture teams to assure fitness for the EA purpose.

Figure 1985 - The EA program organization
Initially, the development should be funded as a project with Operational
Expenditure (OPEX) for development. Both OPEX and Capital investment
(CAPEX) are necessary for implementation but the CAPEX should be
synchronized opportunistically with the lifecycle of existing technologies.

SOA requires that funding be distributed between the internal customers of a

service. After the design phase, outsourcing of a service should be considered.

An EA site taxonomy
As the EA becomes the knowledge DB of the Enterprise, the content has to
be organized early according to an EA taxonomy and exposed on the Intranet to
enable content. management. The EA architect leads this effort.

Figure 19 - 86 - EA site organization

The role of the Enterprise Architect
The EA architect role requires putting together an EA business case to justify
the EA development once and for all, then sell the EA to business and
management to get sponsorship and resources.

Afterwards, the job demands the EA framework selection, customization and

creative design since most frameworks stop at general architectural patterns like
matrices, layered structures, triangles, pyramids, cubes, circular processes etc.
This is a critical success factor for the rest of the EA development!

The architect establishes the design principles, the process, breaks down the
EA work into workstreams, and organizes the teams to discover and document
the current Enterprise state and blueprint.

Then he validates other Enterprise developments from an EA point of view:

all solutions architecture designs have to comply to EA principles, standards and
conventions, reuse the same components and link them to each other and the rest
of EA artifacts.
Also, the ERP, SCM, CRM, MDM, Portal and business specific applications,
suites and activities have to be properly documented at the process and
technology layers, to be integrated in the overall EA.

Then the architect looks at the Business and IT Strategies - to align them to
the Enterprise map and analyze their impacts - and determines the future state of
the EA and its roadmap.
The EA architects also establish the technology standards and guidelines,
specify and verify the EA compliance criteria and process check points, evaluate
the EA maturity and not least, coordinate the entire EA development work.

Enterprise Architect kinds
A good number of Enterprise Architects (EAs) appear to come through the
IT professional promotion ladder process which ends up at the top of this value
chain: the Enterprise Architect. They are veterans, they know people and people
know them, they give advice and are knowledgeable about the company history,
culture and motivation behind every technology in existence. They are often
consulted by management and occupy a position of respect since some are
legends for services rendered. Do they really do Enterprise Architecture? They
mostly don't. They do check consistency of designs between projects and against
their own experience, but they do not have a reference Enterprise Architecture to
validate results against.
Another type of Enterprise Architect is the Integration architect; it is an
important role since most applications are hard to interconnect even today. They
are chosen from the SOA ranks, as the middle name for SOA is integration for
most adopters. They use middleware, mostly based on ESBs, JAVA/JMS, MQ
Series… and Web Services. Do they do Enterprise Architecture? They do the
EA integration bit.

Then, the well known Enterprise JAVA Architects so called because of the
“Enterprise” in the Java EE naming. The technology is said to be Enterprise
wide, in that it may support all Enterprise applications.
There are also Enterprise Solution Architects because they work in capability
delivery projects. They do patching and interconnection work to keep the
applications running. This is not really EA work., but Solution Architecture.

The Enterprise IT strategist role, is the Enterprise Architect working on the

IT roadmap which is aligned to the Enterprise Architecture. If not based on EA,
this role will deliver best effort silo-ed outcomes. leaving gaps which, later on,
would demand resources competing with the strategy activities.
The Enterprise Architects are often classified in Applications and
Infrastructure architects to enable work division and specialization. Often they
end up doing inventories of technologies and applications, working on these EA
layers in isolation.
Sometimes, the Enterprise Data Architect and Warehouse roles are also
created when the Enterprise has trouble with managing its customer data or
extracting reliable intelligence from available sources, which is quite often,
simply because information is duplicated in many applications.
It is significant to note that Business Architect roles are seldom if ever
advertised even though Applications, Information and Infrastructure roles, one
for each framework layer, are. Business Architects, when they exist, usually
occupy business analyst roles, mostly belonging to the "business" community,
not the IT; they have the task to look into requirements and model the business
processes but typically out of the Enterprise Architecture context.

Hence, while there are "Enterprise Architects" in place doing IT solutions,

integration, inventories... more often than not, there is no one to do the business
architecture (business functional decomposition, process , business services).
More, EA architects do not really do EA framework design and customization,
metamodel specification, EA compliance or maturity evaluation work.
The EA positions are occupied nevertheless because the thrills of the EA job
attract lots of candidates. Since the current "Enterprise Architects" are more
likely to be senior and experienced people, there is no way one can substitute
them. They do a great job. While existing EA architects are experienced IT
people there is no guarantee that they understand the business methods and
theory.

One still needs to bring in "true" EA architects to develop and manage the
EA. An EA architect must be able to develop the EA framework, understand the
business theory and practice and manage the EA development.
The problem with the EA is that Enterprise Architects do not cover business
architecture and business analysts do not cover technology, information or even
architecture as a discipline. The division between business and IT does the rest
of the damage.

In reality, one may not employ another team of Enterprise Architects. How
would one avoid the conflict of naming and interests? Who is supposed to draw
and drive the Enterprise Architecture? Does one have to reassign roles and
responsibilities or change titles? The risk is the loss of these valuable people.
A solution would be to introduce the Business Architect role whose
responsibilities are not covered by either current Enterprise Architects or
business analysts.
The business architect is not a mere business analyst. The role, once created
and properly filled, could take charge of the EA development since the business
architecture drives the technology, describes the operation and goals of the
company and conveys understanding to everyone in business and technology
alike. This role should be a senior one, unlike the Enterprise Architect today; it
should have authority to suggest organization alignment, perform project and
team management, resource, delegate... To inspire trust to the top management,
the role should be knowledgeable in business operation, value chain analysis,
supply chain, business models, Six/Lean Sigma, strategy and BPM and have an
understanding of IT and architecture. The Business Architect would lead the
design of the Business Functions Map, Single Page Architecture, Business
Flow Map, Business and Operating model assessment, strategy alignment and
so on.
The existing EA IT architects would continue to do the IT work, play the
same important role in IT, in alignment with the Business Architecture this time.
They should have a dotted line reporting relationship to the Business Architect
lead.

All in all, there are just a few true Enterprise Architects; the few who have
both the business and IT theoretical and practical background and have
overcome, with passion and dedication, the limitations of existing EA
frameworks.

How does one select an Enterprise Architect
Since there are few distinctive qualifications or selection criteria for an
Enterprise Architect, how do you recognize an Enterprise Architect?
Most EAs have studied TOGAF, Zachman, FEA and quickly gave up on
DoDAF. These appear to be the universal requirements for an Enterprise
Architect. Nothing earth shattering though, almost marketing like material.
Zachman is quite straightforward to read and understand. It is common
sense. All candidates have browsed TOGAF, hard to go through due to its
richness.

FEA is a bit of a read, in fact there are quite a number of documents, but
what remains in one's mind is the simple framework (consisting of
performance,... business, services, technology reference layers) which is not
quite rocket science. But if you read specific agency frameworks you discover
they differ in many ways.
DODAF formalizes descriptions in diagrams types with relationships
described by a metamodel. It has its own vocabulary that departs a bit too much
from the EA accepted modeling. Hence it is hardly usable, except in defense.

As such, it is not too hard for a candidate to tick the methodology boxes for
an Enterprise Architecture job: Zachman, TOGAF, FEA and other (IAF, EAP,
E2AF...). But unfortunately this is not too distinctive, in fact it provides no
differentiation since most IT architects can claim this.
The EA (SOA too) certification courses will surely help, won't they?

EA certification attempts to fill the gap to an experienced IT professional

but, typically, it does rely on the existing frameworks to guide the development
work.
The IT layers (applications, information, technology) are more often than
not, presented extensively in training and certification courses. You will see long
chapters about network, DB, servers technologies, type of applications etc. But
do they arm the Enterprise Architect with a practical framework to design or
lead the implementation of an Enterprise Architecture? An Enterprise Architect
needs to understand the framework connecting the layers and its navigation,
rather than all layers in detail.

Since it is not too hard to tick the boxes for an Enterprise Architecture ad, the
Enterprise Architect's curriculum must be usually backed by a long IT
experience, references and social skills. There are also technology requirements:
such as experience with Java, DBs, ERP... And there is also the experience in the
specific business domain such as "Insurance" industry.
Counting these criteria, is it possible to narrow down the candidates to a
short list? Not by much. How do you really make sure you get what you need?
Since there are no clear qualifications or selection criteria for an Enterprise
Architect, how is it done today?
The professional history, Zachman and TOGAF tick boxes, soft skills,
technology skills like Java decimate the number of candidates. Ultimately a
reference and the experience in the domain of business do the trick for most
jobs. You just selected an Enterprise Architect. But will you get an Enterprise
Architecture?
These criteria help but unfortunately they may eliminate the "real" Enterprise
Architects. But what is that? Someone who had a structured mind and takes the
time and the pain to understand how things fit together. Might also have done
hardware design since this is a more structured domain based on functionality
encapsulated in chips.

Consultancies, do they have EA frameworks? They have variations of the
existing ones. Consultancies count on the collective consultant experience to
resolve issues.
For a consultancy, a typical framework - which changes quite often - is based
on the known layers (business, information, applications, technology etc)
conveniently surrounded by a few great Zachman style questions, such as Why,
Who, When, Where.... Orthogonally one will always find a security slice.

The job description for an Enterprise Architect
A job description for an Enterprise Architect,:
Architecture wise
• architecture know how: definition, principles
• IT architecture styles (centralized, layered, multi-tiered client server,
web)
• IT architecture patterns and typical components: Content
Management, Presentation, Business Orchestration, ID Mng, B2B…
• SW and HW development experience at flowchart level
• concepts as MDA (Model Driven Architecture), MVC (Model
View Controller)
• OO concepts, design and Distributed Components history (RPC,
CORBA, COM)
• UML modeling: context diagrams, Use Cases, activity, sequence,
state diagrams, data modeling, ERD (Entity relationships Diagrams),
Class diagrams, BPEL
• a disposition to draw diagrams and flowcharts before coding and
soldering
• Integration experience
Business wise:
• Business acumen: operation of an Enterprise, Porter's Value Chain,
Business Models, Operating Models, Governance,
Financial Management, Performance and Cost Management, SWOT
analysis, SCOR and VRM reference models
• Business Strategy, Roadmapping
• Business Process modeling (BPM, IDEF representations,
swimlanes), Business Process Management, Business Orchestration and
Rules, Balanced Score Card, Six Sigma, CMM, Change Management
• A working knowledge of the specific business: products and
stakeholders
Technology wise:
• EA Frameworks: Zachman, TOGAF, DoDAF, FEAF, TEAF…,
PERA, eTOM /NGOSS
• EA and other modeling tools
• SOA, ITIL, COBIT IT process and governance frameworks
• Systems and Software Architecture and Principles
• Service Oriented Architecture concepts and Web Services protocols
• Mainframe, client server technologies, databases, Content
Management, Data Warehouse, Business Intelligence, reporting, B2B,
Portal, Internet and IP technology, virtualization technologies, trends
• Infrastructure: servers, storage, networks, telecommunications, OSI
• Agile Processes, project management
• ERP, CRM, SCM… applications suites
• SDLC: Software Development Life Cycle
• EAI/ESB distributed component architectures
• Web Services, Java and .Net aware
Social wise:
• Able to communicate, influence, negotiate, motivate, facilitate and
inspire, in other words, get the human interaction right.
• Able to guide the EA development process and get support from all
levels.
• The Enterprise Architect should be politically savvy, able to present
and argue at all levels of management.

The Tasks and authority of the Enterprise Architect
• Prepares business case, exposes benefits and drivers
• Specifies framework, best practices and tools
• Establishes architecture, design and technology principles and
guidelines
• Supervises EA design and development
• Coordinates works done by domain architects
• Controls artifacts consistency and compliancy
• Owns the EA repository and decides access rights
• Presents, justifies communicates to all stakeholders in business and
IT
• Recommends transformation roadmap and works with PM
• Controls EA iterations and operation
• Establishes compliance checkpoints in major development processes
• Assesses EA maturity
• Measures returned value
Authority:
• makes decisions with regard to artifacts design and implementation
• drives the virtual team of function architects
• resolves architecture disputes

Enterprise Architect as a leader
There is an argument that the Enterprise Architect is a leader in the
transformation of the Enterprise and a participant in the business decision
making process. Right now, this is not the case but the trend points in that
direction.

But what is a leader or leadership for that matter? And what is it compared to
management? Management is about organization, control, planning and
budgeting. Leadership is about motivation, mobilization, creating the vision and
establishing the culture and relationships. To succeed, an Enterprise Architect
has to act as a leader to motivate people, mobilize resources and create the EA
vision while as a manager has to manage the complexity of the Enterprise
Architecture development, documentation and day to day running.
Latest thinking points out that leaders must have theatrical qualities. I would
say that actors becoming leaders are not rare these days, especially in politics.
But is it what leadership needs? What is called theater is in fact another term for
excellent communication skills, the ability to hold an inspiring speech in front of
people at a conference.

But it is possible to have a leading position without having leadership

capabilities or the other way around. A leader is an individual who leads a
group's activity to a specific purpose. But these individuals could be selected,
nominated, self-nominated or inherit a leading position, a position of authority.
In this latter case, a group may not even respect or agree with these individuals
since the authority of this leader comes from the power of the position.
Discussed here is the case of leaders capable of leadership.
What is leadership then? Leadership or charisma is the quality of an
individual to attract followers for a specific purpose. For that, a leader must
inspire trust and respect, coming from natural personal qualities, experience or
education. Leadership requires self confidence and emotional control to reassure
and inspire the followers.

What are the qualities of leadership? Inspiring trust and respect is vital, even
if the leader has a position of power, but how is it done? In the first place, the
individual has to be credible and lead by example. This requires top competence
in that field of activity, a basic sine qua non condition for the leader. Self
confidence has to be rooted in knowledge and experience rather than mandated
by culture (you must be confident at all costs!), or two days training courses. The
leader would find solutions where few can, strengthening the others' confidence.
He is Not someone who is looking the part, confident, decided, sure of success
but without with the depth to deliver. The problem is that without the underlying
professional ability, the confidence is wrong footed and the results average. The
surrogate leader fails without knowing why, since he is playing the role well and
moreover believes unconditionally in himself. Acting the role alone, will not
deliver professional results. Acting the role of a leader, can only benefit, in the
long term, the actor, the "leader" and not the group. There is a difference
between the role and the reality, the personage and the person. An actor is at his
best when plays naturally since he is authentic i.e. a leader. Otherwise there is
mismatch between substance and form, easily noticed unconsciously, decoded
by primitive but efficient detectors within ourselves: the eyes which do not smile
or avoid looking into your eyes, the gesture that does not confirm the words, the
intonation gone the other way.

The leader should have a vision, an ideal that inspires people and determines
them to follow in the long term. He does the "right things", and does "things
right" as a good manager/administrator does.

He should be emotionally stable, having a degree of Emotional Intelligence

(EQ as opposed to IQ), so that he could understand, interpret and control
emotion in others. But the leader is in control of himself first. A leader,
alternatively, could be passionate to inspire his followers with his energy and
enthusiasm.
Leadership needs authenticity to succeed, that is the image shown should fit
the substance and competence. Authenticity means "you do what you say" and
"you say what you think".

There are archetypes, or worse, stereotypes of leadership. The hero leader in

films is a typical example. People are molding themselves on heroes since early
childhood. We struggle to imitate the best, their behavior, we learn from them.
There is also the stereotype of the business manager played by many,
unfortunately.
In a culture driven by acting leaders, the real work would not be prized any
longer; meritocracy would be applied in terms of acting skills. An acting leader
can empower, delegate, but the immediate ranks feel the competence void. This
leadership will be maintained not by respect inspired by competence but through
power, minute control and politics.

The style of leadership depends on field: a warrior leader would be bold and
ready to fight, a president would be a decision maker, and a conductor would
orchestrate the individuals in the orchestra. This would require different
qualities.
Leadership also depends on situation such as a company in difficult times for
instance. In normal times leadership is welcome but not in demand. It does not
necessarily mean doing moral "good". There are evil leaders. Why people follow
them? Because trust, belief and the lack of doubt is said to make people content,
if not happy. It was discovered that following is easier than leading, that too
many choices or decisions make people unhappy.

Finally, leadership comes from will or desire to lead, since it is not solely a
blessing but a very consuming activity, requiring sacrifice and dedication to the
cause.
EA is a difficult task. Many people in management, business and IT would
have to trust the Enterprise Architect and take action. But without the right
authority the task is made impossible for the Enterprise Architect.

The growth of EA jobs
The good news is that there is an increasing demand for EA jobs. Here is a
[xxvii]
survey from UK in this respect.

Figure 19 - 87 - The growth in jobs of EA architect

Review checklist

111. Describe governance for EA design.

112. Illustrate governance for EA execution.
113. How is the project organized? Specify phases.
114. Discuss project funding.

115. List a few components of the EA silo taxonomy.
116. Write the job description of an Enterprise Architect.

Chapter 20


Measure your Enterprise Architecture Maturity

A few attempts have been made to define EA maturity evaluation models.
The Capability Maturity Model of Carnegie Mellon Software Engineering
Institute (SEI) is a main source of inspiration. A simplified maturity model is
shown here. The development maturity model assesses the phase of EA
development. The exploitation model determines the degree of adoption. An
important factor is overlooked deliberately at this stage. the quality of EA. This
depends very much on EA definition, scope, framework (and artifacts) and
practical purpose of development.

EA development maturity
The following phases are distinguished:
• Phase 0: Pre-EA
From value of EA not assessed or understood until the Business Case is
approved. There is no commitment or capability to plan, design or execute.
• Phase 1: EA Program Initiation
From approved business case until
o the EA organization is set up
o planning and resources are committed
o Chief EA architect, Steering Committee/governance are agreed.
Capabilities for the EA design and execution are committed now.
• Phase 2: EA Definition
EA design and transformation planning phase, until
o the EA framework and tool are established
o the As-Is Architecture is discovered
o intermediate stages and To-Be EA are sketched,
o transformation plan approved
o KPIs, CSFs, quick win are determined.
• Phase 3: Transformation Execution
Enterprise transformation execution in iterations until 80/20%
(functionality/ effort) is achieved and value delivered is confirmed.
• Phase 4: EA exploitation
EA enters the exploitation stage, while incremental design/plan/
implementation stages are still executed.
The components assessed in the transformation implementation process
would typically be business processes, technology architecture and organization.
The degree of EA development progress inside a phase would be also evaluated
as a percentage.

To measure the earned value, the table of indicators in the Business

Case chapter can be employed to fill in the % column. Alternatively, a subjective
way to measure benefits, would be to estimate the ultimate benefits: the degree
of simplification, alignment, agility, strategy alignment and blueprint
documentation achieved.
Once the EA is implemented to a significant degree (80/20) the CMM for the
EA exploitation process should be employed.

EA exploitation maturity
This may overlap with the EA development capability assessment. It may be
practical to keep them separate.
• Level 0: EA ignored
o Although EA artifacts exist, they are ignored or not easily available.
o No EA central authority or clear distribution of ownership of iterations
exists.
• Level 1: Empirical EA exploitation
by a few stakeholders:
o the process is repeatable but depends on people;
o There is some ownership but
o The EA utilization process is not clearly documented.
• Level 2: Documented EA utilization process
o The exploitation process is well defined
o Design and ownership of artifacts is in place
o The exploitation process embeds controls, checkpoints and audit points
in all relevant Enterprise processes.
• Level 3: Managed EA
It is used by management, business and technology teams to design,
deploy, control investment, make decisions and manage change.
• Level 4: Optimizing EA
There is on-going EA improvement and maintenance. EA is used in
product design, organization evolution and strategic planning.

Measure the Value of EA
EA, like any architecture, represents the structure of an Enterprise and its
documentation describing how the Enterprise operates. The better the
architecture, the better the outcome, i.e. the returned value.
A good architecture structure reduces duplications and overlays in processes,
platforms, projects and sometimes people and it consolidates the many
interconnections.

A good EA framework describes the structure, standardizes best practices

and technologies, maps strategies on architecture components and architecture
layers such as processes to people and technology. It makes understanding the
operation and training people easy.
The Enterprise Architecture delivers value, as soon as it is designed and
implemented. In fact, it does that, gradually, while it is implemented by
increasing the effectiveness and efficiency of your Enterprise. EA soon becomes
an asset in its own, returning value to your Enterprise.
A project justification is done at Business Case time, before the start of the
development,
by enumerating and estimating a number of key benefits. Ideally, all these
initial benefits should be tracked and measured at implementation time to prove
the delivery of promises. Same applies to EA. The EA scope is key though, since
more scope should return more value. EA iterations may add scope and as such,
new value.

But EA definitions vary and their scope is wildly different for each
development. What is EA? Is it an IT only architecture? Then you are looking
only at the benefits of standardizing technology and integrating applications.
With business and people architecture the picture changes significantly. The
Business, Organization and IT alignment with ensuing benefits can only be
achieved if you include in scope a Business Architecture.
Once the scope and deliverables are established, the benefits and business
case of the development can be estimated. The EA success should be measured
against the listed benefits and deliverables in scope rather than against an
abstract EA that does not have an agreed definition, but promises a lot, in vague
terms.
A table of key business improvement benefits, the way to measure them, and
their stakeholders should be defined from the beginning and measured at the end
of an EA iteration. The key benefit indicators may be grouped in a few
categories:
• Operational (those enhancing the operation such as single customer
view - master data management -, Development (improving your
innovation and the new product development process, reflected in time
to market) and Support (enabling single version of truth for reporting…)
• Governance (enabling understanding, communication and decision
making in the organization)
• Strategic, enabling effective execution of strategy
• Communications and Collaboration
The EA development success is measured at implementation time with
project progress indicators.

An EA maturity framework will help you measure progress in the

development and compliance in exploitation phases; It will do that by measuring
success from a process maturity and extent of business participation points of
view rather than from a business value view.
Value, sometimes comes down to how do I justify my job as an EA
architect! Firstly, many "EA architects" are not really doing an EA design work.
They are Enterprise level technology and applications integration experts and IT
veterans. But if you are really doing EA work, one can evaluate your job
performance by assessing, after each iteration, the benefits stated in the business
case and measured by key improvement indicators in the benefits table. This
could be correlated with a maturity framework evaluating the EA development
progress, participation and compliance to EA.

A Balanced Scorecard approach for performance measurement and

management of your Enterprise is supported by the FFLV framework in that it is
addressing the four scorecard views: market (customers), processes (company),
learning and growth (people) and financials (owners).

Sell the EA
This seems to be one of the issues continually confronting us in the EA
arena. To sell it, start by identifying the interested and affected parties for each
iteration, the stakeholders. Ask the old question "what's in it for them?" and
"what is the impact on them" since they would be asked to support, pay or even
contribute to it!
The potential audience depends entirely on the scope of your EA
development which can vary a lot. Is your EA an IT only architecture? If you
define your architecture in terms of applications, information and technology
architecture you address an audience in IT, for the most part. For IT, do you
intend to include content management, knowledge management, BI, DW,
integration architectures? That will considerably enlarge your IT audience.

Top management, what is in it for them? The representation of the

Enterprise governance, the roles and responsibilities, governance bodies and
principles of decision making, the business models - how the business makes a
profit -, strategy alignment to the Enterprise organization, regulatory compliance
and not least a business blueprint. There is quite a lot to sell.
For Enterprise shared services organization: support functions as HR,
Payroll, have to be described in terms of services, processes, costs and
effectiveness.

For business people you should be providing information on IT or other

technologies they use - like SCADA and GIS for utility companies - process
automation and improvement, business rules and orchestration and not in the
least reporting and Business Intelligence blueprints. If you provide this
information the business organization would become your supporter.
To satisfy the interests of most potential stakeholders, the concept of
architectural view is crucial: a view satisfies the concerns or needs of a
stakeholder group. There are as many views as stakeholder types.

To sell the EA, put together, upfront, an EA drivers and benefits pack and a
business case based on financial terms. Business management thinks in terms of
Payback, ROI, NPV which are measures of profit vs costs, typically applied to
projects. A table of benefits, such as time to market, agility, and the estimated
EA contribution to them at each EA iteration will do a lot of good to the sales
process of EA. Calculate RoEA at each iteration.
The EA has to be opportunistic, planned to deliver first what the business
needs such as a Single Customer View or a Single Version of Truth architecture.
A natural progression to EA with obsolete systems and technologies replaced
when their time has come and not before would reinforce the EA sell effort.

Business does not see technology in isolation as IT does, except as a source

of problems.

Review checklist

117. Describe the EA maturity exploitation model.
118. Explain the stages in measuring the EA maturity at design phases
119. How do you measure the value of EA?
120. How do you sell the EA?

Chapter 21

21. EA Roadblocks , Culture and Politics

EA Development Triggers
Enterprise Architecture, as shown, provides many benefits. Once a business
case is built it is easier to argue for the EA investment. The typical issue is that
tactical concerns are always winning in competition with long term, strategic
programs as EA. A reason is that strategic issues are coming today, at tactical
speeds. If not strategic thinking, then which factors may trigger the development
of an EA?
• An imminent Merger and Acquisition requiring the amalgamation of
two companies with different organizations, processes and technology
• A decision to outsource business functions where productivity and
costs are becoming an issue
• Technology infrastructure needs urgent alignment to business
Strategy
• Imminent regulatory issues demanding documented business
processes and document management with compliance controls
• The company suffers from inefficient processes
• A re-organization to adopt a new business model and strategy is on
the agenda
• Master Data Management or Customer Data Integration introduction
• There is an acute need to upgrade from an obsolete technology as
Mainframe
To be successful, the EA has to offer first relief for the trigger problem.

EA Roadblocks
Enterprise Architecture (EA) has promised a thorough transformation of the
business world by streamlining enterprise operations, aligning IT to business,
enabling strategic planning and documenting the company blueprint to improve
understanding, measurement and management of its operation.

Although EA has been around for some time now its take off has been rather
modest or inconsequential. The value it promised to offer has not quite
materialized. But what are the factors inhibiting adoption or its success?
What I found is that EA is seen as an IT architecture only. All technologies
besides IT seem to be ignored.

EA is overly simplified to four architectural layers with few other "views" to

respond to non-IT stakeholders' concerns.
The logical architecture, a good practice in systems design, is not really
adopted and Use Cases, coming from the world of software design, are not really
used.
There is seldom a link to the enterprise Value Chain or business model.
EA tools are not used, true EA architects are hard to find (as opposed to
Java/.NET architects), and there are few successful EA cases to encourage
adoption.

ERPs are already covering the Application side of EA and are very costly to
change, SOA is in fact a disguised EA development but incomplete.
Presentations on large paper format (A0), covering a wall, scare off stakeholders.
This being the case, no wonder that people are reluctant about an EA
development then: it is costly, takes time and resources, its business case is not
proved and the outcome may not live up to expectations.

The Enterprise Inertia, silo organization and the Business - IT divide
Your Enterprise may be in a state of cultural inertia. EA challenges the
status quo of the Enterprise by altering its course.
Most companies have a predominant tactical thinking. EA is about strategic
planning. This collides with the short term thinking. Strategy demands good
long term planning and execution that needs discipline. Tactical action demands
ad hoc allocation of resources which works against long term planning.
The Silo organization plagues many Enterprises where there is no big picture
(EA). Silo management focuses on own business segment ignoring the big
picture activities. Silos generate wasteful duplication in projects, platforms and
resources.

The divide between Business and IT, yet another silo, exists simply because
they have different management, planning and goals. Besides, It is not easy to
cross the boundaries between domains of such different skills and interests.

The lack of reference Business Architecture s
Historically, there is no business architecture designed by the academia, a
global forum or business people. You have to design the business architecture
without a template, a reference map or even help from business.

The diversity and non-coordinated approaches to fix the Enterprise evils
In practice, there are a few categories of activities or approaches for mending
the evils of today’s Enterprise:
• Business Process Management (BPM), improving processes -
belonging to the business domain and specialized consultancies
• Six/Lean Sigma to eliminate defects in processes, mostly people
related and typically in the manufacturing environment
• Enterprise Applications Integration (EAI), about IT architecture and
integration;
• EA, that usually and unjustly belongs to IT only
• Human Performance and organization evolution, about people
performance and organization design, factors frequently dealt with by
HR and top management or external Human Performance agencies
• SOA, about transforming the Enterprise based on Services
• Strategy alignment, executed top down affecting mostly the
organization and job descriptions
Not surprisingly, each activity
• is performed in isolation, at different times, and by different groups,
without a mutual exchange of knowledge
• engages a different set of skills
• develops artifacts with different conventions, tools and stores them in
different places
but they are all associated to a layer of the Enterprise Architecture.

Management consultancies typically operate on the business side in business

process improvement, organization design, business strategy and objectives
cascade to people and roles.
IT consultancies, more often than not, sit in the driver’s seat for the EA,
SOA and Enterprise Applications Integration developments. The same divide
between business and IT can be observed at external expert advice from
consultancies.

Six/Lean Sigma is typically an internal business development to improve

processes requiring extensive resources and training.

EA vague definition, is it a blueprint, process, program, strategic
planning…?
In fact, EA is all that: a blueprint for As-Is and To-Be Enterprise, a plan and
roadmap for transformation and a process of delivery, reinforced by best
practices.
The strategy and target Enterprise Architecture specification constitute the
"strategic planning" of the Enterprise. The EA design and Enterprise
transformation are part of an Enterprise wide program organized as an Enterprise
project portfolio..

But no matter what the definition is, you have to clarify what the
expectations are for your case, right from the beginning.

EA scope, no non-IT technology, no people or other stakeholders' views
A. EA is more than an Enterprise wide IT only architecture
This is a noteworthy scope issue: Enterprise Architecture is composed
of the Business, Technology and People Architecture, not only IT. The end
result is that it prevents the business people and firm's management
involvement, funding and support. The EA is not visible to the business
side and what is more relevant is that it does not cover business aspects.
Such an EA fails to raise interest or ultimately extend usage outside the IT.
The assumption may come from Java Enterprise Edition (Java EE) or
EAI, ESB where the term "Enterprise" is used liberally! There is nothing
wrong with an IT architecture. The issue is that the expectations promised
by the Enterprise Architecture advertisement will not be fulfilled.
IT architecture is only a part of an EA architecture. To succeed, an EA
architecture needs to address business concerns, to be sanctioned, supported
and have visibility at the business and management board. EA needs the
wider scope to include and provide motivation to business teams and enable
adoption and usage.

You need to design the EA top-down starting from business processes

and strategy and not bottom-up from the supporting IT technology.
B. Not many IT Views
Often there are no email, printing, PBX, SOE, Helpdesk… architecture
views; no Knowledge or Content Management, Data Warehouse, Business
Intelligence…, typically approached in isolation.
EA frequently covers only the key products architecture. It needs a
wider scope to include other architecture views to provide motivation to all
IT teams. Enterprise Architecture is more than two views of Applications
& Infrastructure.
C. Technology is more than IT!
Often, no other kind of technology such as mechanical, optical etc is
considered. What about manufacturing technologies?
50 years ago there was no IT. Banks and factories still existed though. It
is hardly an Enterprise wide Architecture, a development which does not
describe the manufacturing equipment when your products are cars or
shoes.
The IT only view is restricting the sphere of interest to just a few types
of IT intensive enterprises and, inside a company, to a few stakeholders. It
is again a matter of scope, not only in design but in business users'
involvement, support and usage. As a result it's difficult to get traction from
firm's management, business or manufacturing people or, for that matter,
from other stakeholders outside IT.
For wider adoption, EA has to cover all Technology, not only IT.
Enterprise Architecture is more than IT Architecture and Technology is
more than IT.
D. Lack of stakeholders' views
reduces the interest and usage of EA to just a few stakeholders, leaving
out other aspects or "views" of the Enterprise such as real estate,
accounting, parking or, in IT, email or printing, file server architectures
although they probably exist, are documented elsewhere in some form and
are of real interest to you and quite a few enterprise stakeholders. Due to
this simplification, EA architect positions are sometimes advertised directly
for Information, Infrastructure or Applications roles in the IT space, already
confining the activities to this narrow scope before the development has
even started.
E. Often people/organization are left outside the scope of EA
Typically business processes or parts of them are still performed by
people rather than applications. These processes, in fact, more accurately
workflows, are still relying on human interventions for data input,
validation, phase approval... In other words they are not automated.
Processes lag because people taking decisions are away or technology fails
at the hands of poorly trained personnel. More often than not, the human
intervention is not described in business workflows for the simple reason
that people are not part of the framework.
If human performance is not accounted for, the overall workflow will
perform as its weakest link, the people. But EA looks like an unfinished
business without people manning processes and technology.
Organization (people) design is often the object of an entirely separate
and non-correlated initiative. In a company, the process and best practices
optimization effort, the organization re-design and alignment to strategy
and the Enterprise Architecture program activities are often performed by
three different groups, in parallel. That is, the process, people and the EA
activities, constrained to IT, are executed in isolation, without correlation.
The organization chart should be aligned to your Enterprise Architecture so
that people take ownership of business function's process and technology.
Culture and people communication also affect your Enterprise performance,
but this is quite a topic in itself.
After all, "the Company is the People" who govern, plan and operate the
Enterprise.

The EA program developed solely by IT
In terms of EA implementation, the EA program initiated by IT has little
authority to drive the business architecture, influence corporate strategy or
recommend the people architecture/organizational changes.
Usually the EA team has little control of the business process documentation
effort, for instance, even if it successfully initiates it.

Lack of an agreed EA framework
or the diversity of approach and limited scope of the existing frameworks
inhibits EA adoption. Some of the existing EA frameworks are, by and large,
cognitive aids, enabling discovery by asking key questions such as why, what
and how. Some are merely reference models describing outcomes and
implementation guidelines to serve as reference for other EA developments.
Some are specialized on domains as government, defense, manufacturing or
telecoms. Some have been applied for a while with less than convincing results,
and some are obsolete or used no longer. Some other only touch aspects of the
EA implementation program management. Some approaches talk about BPM,
Enterprise Applications Integration or SOA only. Most leave out the people
layer, and some are only process architectures ignoring the technology and
people resources. Most are mapped on Zachman's for scope validation. Mapping
matrixes are used, sometimes, to link elements in layers but they hardly support
the navigation or consistency of artifacts.
How do we choose a framework? None of them appears to cover all aspects.
Are there any recommendations for the framework selection? Do we need to
create our own framework where so many others have not quite succeeded? All
legitimate questions.

Overly simplified EA framework
A. EA, overly simplified to the four layers architecture
EA frameworks typically consist of four architectural layers: business,
information, applications and technology. The EA development is often
considered finished, soon after an inventory of technology is compiled, the
application architecture is drawn, the process documentation is initiated by
business analysts and data architecture class diagrams are sketched.
An EA framework that covers business functions and flows
architecture, people and organization and many views on top of the four
layers framework, is necessary to deliver to the many stakeholders.
B. Frequently there are neither business reference or logical
architectures
The lack of an industry reference architecture inhibits understanding of
the Enterprise operation and of the EA itself. A logical Single Page
architecture outlines key Flows operating over the Functions of the firm to
deliver value to stakeholders. eTOM/NGOSS provide such a reference
process architecture framework around which a Telecommunications
company can be modeled .
For a technical system design, the logical architecture specification is
one of the first steps an architect has to perform to describe the system
operation and its components. The organization has to be mapped to the
logical architecture.
A Single Page EA (key Functions + key interconnections), added to the
business, information, application and technology layers, will dramatically
improve comprehension. It will also make possible SOA with services built
around functions. A Single Page Applications Architecture, derived from
SPEA, serves the IT audience.
The logical architecture is one of Zachman's framework perspectives,
the designer's.
C. The EA design is not initiated by Stakeholders’ Use Cases
By default the only stakeholder considered is the customer, leaving out
owners, partners, employees and other views, thus limiting the EA scope
yet again. This leaves out B2B and employees views. A good practice
would be to listen to stakeholders and capture their interactions as part of
the EA architectural layers.

The Enterprise discovery should be initiated by Stakeholders'
interaction Use Cases.

Lack of Business Case at initiation
Frequently, the EA development is rather the result of the hype that animates
IT but annoys the business . A Business case would resolve once for all, the
argument about To Do or not To Do Enterprise Architecture. Further more the
business case establishes the indicators that have to be measured to prove that
EA delivered value.

The business case, drivers and benefits need be produced for each EA
iteration.

EA deliverables not fit for purpose
Deliverables are not fit for implementation. Take the typical “tome”
delivery, a stack of paper reflecting in fact the politics of “passing the buck” to
the next team and phase.

EA governance and implementation failures
The EA, initiated solely by IT, has little chance to enroll business
stakeholders or attract management support.
At implementation time, an EA development that trails for too long, not
solving the immediate business pains and displaying a lack of transparency
revives the tactical project threat to resources and discussions about the utility of
the EA. There is little tolerance for long programs with uncertain results.

At exploitation time, the governance makes sure EA is not ignored, forgotten

or considered a dead weight because you have not implemented architecture
controls and check points in the relevant business processes.
The governance team has to be properly chosen to reflect all interests and
has to have enough authority to make it happen.

Enterprise Architect not invested with authority
The lack of authority, budget of the Enterprise Architect and in general of the
Enterprise Architecture program proves that management and business people
still see EA as an IT clean up exercise, at best. Until this perception is changed
EA remains a futile exercise usually terminated after a few months when the
applications diagram and inventory are produced.
One of the common mistakes is to invest no authority in the Enterprise
Architect. Even minor objectives cannot be achieved without the proper
approvals, contributions and budget.

Politics slowing EA development
There are execution mistakes: ignoring important stakeholders, not
communicating properly or enough, in simple clear definitions and messages,
not consulting relevant people, not referencing and recognizing contributions, to
name a few.
Not consulting the relevant groups, breeds the “not invented here” syndrome,
i.e. “you have not consulted us, where did this come from"?

The Enterprise knowledge is locked in people's minds. The ability to extract

information requires negotiation skills in the absence of authority. To release this
collective wisdom you need negotiation skills, “selling not telling”. Otherwise,
the information you may get for the EA may be of little value.

Independent SOA programs competing for resources
SOA is a partial EA development in disguise. While not an inhibitor as such,
SOA harbors under its umbrella developments which should be covered by EA.
SOA does cover architecture but not technology alignment to strategy or
organization design for example. SOA is not IT specific; it tends to fail as much
as EA because it is initiated by IT, without business stakeholders' and the board
of directors' support.
SOA should be a business development first, part of a larger EA
development. It is taking off as the Enterprise integration paradigm of
preference as it provides agility and utilization of best of breed solutions from
various vendors

ERP development competing with EA
but not offering an Enterprise blueprint, comprehension alignment to
strategy... ERP (Enterprise Resource Planning) covers many Enterprise functions
(payroll, procurement, accounting, finance, inventory, order fulfillment etc.). It
provides, in a rather monolithic approach, the business process and application
layer of an EA for support functions. Historically, they were introduced to
integrate the Enterprise applications in software suites delivered by one single
vendor. Nowadays, ERPs are probably too integrated, too vendor dependent to
open the Enterprise to Best of Breed (BoB) applications and offer agility through
easy integration. It's not in the ERP suppliers' interest to open up their products
to SOA which promotes best of breed services and as such open the gate to other
vendors.
ERPs do not promote the understanding of the Enterprise an EA does,
through its blueprint and there are main culprits in inhibiting the alignment of IT
to business requirements for lack of agility and laborious integration to other
applications. ERPs are notoriously hard to change as they are inflexible,
expensive and hard to learn!

ERP modeling is the solution for documenting the ERP processes and as
such, re-use the existing suites in the EA development.

Not using EA tools
There are many repositories, inconsistent diagram input/outputs, various
notations and a proliferation of PowerPoint and Visio drawings with the
consequence of creating the issues which, in the first place, EA had to eliminate.
As a consequence the EA artifacts are hard to reuse or evolve in harmony. A
change has to be propagated to many diagrams in many stores. Each stakeholder
would produce in isolation artifacts which represent own concerns. They are
usually poorly linked, if at all, to diagrams of the Enterprise from other
stakeholders. The consequence is the lack of navigation..
A tool or tool-set would enable a repository, a common vocabulary,
consistency in representation and data integrity.

Often the sheer size of the diagrams discourages EA consultation, take for
instance, A0 paper formats. Not everyone has equipment to print them (in fact
very few), space to display them or is patient enough to discover in the maze
solely the aspect of concern. The diagrams are too big, they look and are too
complex for everybody. In the end they are forgotten and forgiven.

The vast knowledge required and paucity of Enterprise Architects
Only a few EA architects are able to deliver. To develop an EA the
knowledge stretches across the business and technology domains in fields such
as Value Chains, Business Models, Strategy, Operations, Business Processes and
BPM, Technology, EA frameworks, architecture design, IT, ITIL, IT
Applications and Infrastructure, ERPs, CRMs, SOA, outsourcing, BPO, SaaS,
Web Services, modeling and tools, performance and change management
(Human Performance) organization design, and maturity models. These are
some of the challenges Enterprise architects face. In the corporate transformation
phase many other resources have to be involved. The EA governance and the
quality of the Enterprise Architects are key to the process and a major risk as a
result.

Roadblocks recap and recommendations
To succeed, an EA architecture needs to address business concerns, to be
sanctioned, supported and have visibility at the business and management board.
EA needs the wider scope to include and provide motivation to business to
defeat the Enterprise inertia, cross the silos, the business-IT divide and commit
resources.
EA needs to be clearly defined and scoped to consider all stakeholders
views such as owners, partners, employees, community, not only customer's
products.
Avoid returning discussions by providing a business case in financial terms.
Employ an EA team having a vast knowledge of the Enterprise. Consider EA
governance from start.

The Enterprise discovery should be initiated from stakeholders' interaction,

Value Chain and business model.
EA should include people and organization, in alignment to business
processes and technology and aim to cover the whole Enterprise operation rather
than solely IT architecture and all technologies rather than only IT.
It should cover many views besides the over simplified four layers, a logical
architecture, content & knowledge management, MDM, DW/BI, Governance,
decision making, Financial/Accounting, HR, fleet views…
The EA effort should be jointly governed by business and IT, since IT alone
has little authority to get traction from firm's management and business, drive
the business architecture, influence corporate strategy, facilitate decision
making, planning and investment or recommend organizational changes.
Be unambiguous with regard to other Enterprise related technologies :
BPM is part of the business architecture, SOA is an architecture style and
integration technology for the target EA, ITIL is only the EA of the IT
department, and ERPs provide the applications and process layer of the EA
support functions.
Employ EA tools that support consistency in definitions, inputs/outputs and
look and feel of all EA artifacts by employing a single vocabulary, metadata,
repository and set of architectural patterns, principles and conventions; they also
enable process simulation for business process improvement, dependency
reports, navigation, "zoom in/out", configuration, change management,
collaboration, access control and web presentation.

Enterprise Culture and EA
The Enterprise Architecture development has to be supported by the
organization and its culture. People are the company; they can make or break the
EA. To succeed one has to adapt the organization and subtly sniff and influence
the culture. SOA for instance, requires a new governance based on services.
People are accountable for the service they deliver, its roadmap, business, IT
technology, usage, defects, service continuity and for acquiring internal or even
external customers. Here are a few definitions for culture, from the web:

- "The set of learned beliefs, attitudes, values and behavior that are
characteristic of a particular social group or organization."
- "A set of shared norms and values which establish a sense of identity for
those who share them".

- "The sum total of the ways of life of a people; includes norms, learned
behavior patterns, attitudes, and artifacts; also involves traditions, habits or
customs; how people behave, feel and interact; the means by which they order
and interpret the world; ways of perceiving, relating ..."
And an own attempt at definition: company culture is a set of principles and
values that drive the behavior of a group and shape the way people respond to
events and get things done beyond established procedures. It consists of, and is
transmitted by rites (ceremonials), traditions (established ways of doing things),
legends (heroes and deeds people treasure) and education (training). It is
reflected in the way people solve issues, communicate, celebrate, approach
management (direct call/email, kick the door open…).

It is the unwritten code of behavior in a firm; it determines the attitude

towards colleagues and work; it lives in people's minds and hearts; it is
determined by the successes and history of the company; it makes people proud,
ready to identify with the company and set its interests first. Culture becomes
tradition.
The culture is the collective soul of the organization. It is influenced by: type
of governance, internal regulation, empowerment (liberty to act in some
established limits) and recognition policies, height of the organization tree
(bureaucracy), clarity of accountabilities and roles, freedom of communication,
right of opinion… Recognition makes employees happy which in turn make the
company successful.

Company values are the principles or rules of behavior which determine

culture; they have to be meaningful, realistic, even measurable - unlike the
values of most companies, today -. It is important what happens if people ignore
or even act against values.
An Ethics code, based on values, represents the code of law preserving the
culture; it has to be communicated and policed, because otherwise it becomes a
"lip service" of, and for the powerful and the manipulator: insider trading,
networking, nepotism begin to manifest until, like societies, the company begins
to disintegrate.

God had created people in his own image, it is said. In a similar manner, a
top Executive determines the culture in the organization through personal
example, choice of direct reports - in his own image - of governance, business
strategy and ethics code. Empty words won't do! People, intuitively, have an 6th
sense, the ability to feel the truth from gestures, expression, phrasing and
intonation.
A few known organization cultures:
- "Meritocracy" is the culture of reward and recognition associated with rapid

progress and pride in the organization.
- The "can do" culture characterized by achievement, as opposed to the "can
talk" culture.
- "Innovative" culture where invention is rewarded and praised
- "Agile" where formalism is replaced by people’s empowerment to
immediately act
- "Blame culture" where if anything goes wrong a scapegoat is found; the
consequence is that people rarely assume accountability
- "silo " where the departments don't care about the greater, collective good.
Some of these types can co-exist.

The best culture is meritocracy that worked so well for societies. Everyone
achieves the position deserved in an organization with optimum results for the
individual and the company. It is the ideal win-win balance of benefits between
the company and employees. There is mutual respect (we respect achievers), and
everyone knows their own place (promoting the right individuals rather than self
promotion). Collaboration is the norm and people care for each other.
A good culture polarizes individual behaviors towards the company goals
first (rather than personal gains) from which all other individual rewards come,
proportionally. The secret of good culture, in short:
• a history of success, conserved and taught
• a code of ethics and values that are enforced
• freedom of speech
• transparency of decision making
• clear governance, thin organization
• fair participation and repartition of benefits (unlike the
CEO/employee salary ratio today >> 50:1!)
• empowerment, recognition and fair promotions
The wrong culture can ignore or make fruitless the EA efforts and for what it
matters, can wreck the company. In a difficult culture the personal interest
comes first against the Enterprise. The company sinks under the weight of the
many individual benefits working against each other and the common company
goals. Not only a firm, but a society falls apart under the weight of an
incompetent or corrupt administration fighting solely for power and personal
benefits. The disease spreads quickly downwards, by example rather than
discourse.

If formal mechanisms are not set in place, culture tends to deteriorate with
people tending to take advantage of the honest, the trustful, the weak or the
unaware. Action is necessary to enforce ethics, transparency, empowerment and
recognition in support of a positive culture.
How can you change culture? That is, change it in a positive sense since it
may often happen otherwise. The cultural change starts at the top. It requires
honesty (as opposed to political spin), justification, communication, openness
(information available to anyone concerned) that is, all in all, transparency
(information available to anyone) enforced by a Freedom of Information like act.
Accountability (the ability to associate people’s performance to task
accomplishment) and recognition of merit are essential to enforce a successful
culture.

Practices like "networking" are clearly working against meritocracy since the
best available are not selected. Positions are not advertised, only a few are in the
know, and only a few can occupy the position in an exchange of favors. These
people team to maintain power and the phenomenon grows with a viral behavior
until the company suffers the worst, the end. This works against the freedom of
information principle and employs "spin" to project the appearance of "
politically correctness". The spin culture uses media to distort messages, the
truth and hide the sources of information.
Management at all levels has to pay attention to atmosphere and open
communication channels so truth can be told with immunity. Freedom of speech
is key to evaluation of culture. Personal performance evaluations have to be
performed by customers and colleagues rather than managers alone who can spin
the outcome from fear for their positions.
In times of hardship, un autocratic culture with a cult for a leader, may
succeed though, like in time of war. So cultural changes may be beneficial
depending on existing conditions and the place of the Enterprise in its
lifecycle.
Often governance issues generate an unhealthy culture. For instance, silos or
the division between business and IT. It exists because there are two different
organizations with different objectives, plans and roadmaps. So they do not
concur to deliver together. They have different missions and products, it is that
simple. The EA governance and organization have to be set up so that the
concerned business and IT groups have same leadership and goals.

EA Politics
The culture can be a fertile ground for politics. Nothing is achieved without
playing the game.

Rumors abound about IT fearing the business reaction to the

EA/SOA program, unfortunately, too often initiated without a business case.
IT, avoiding confrontation is probably substituting the EA and SOA terms with
a discourse on benefits. Politicians, as well, in avoiding sensitive topics, come
back with convoluted answers to respond to simple, closed questions.
Too many prophets have jumped in the EA/SOA bandwagon adding to the
IT pressure on business. “Do EA/SOA or …!” Over-hype has already placed EA
and SOA at the top of the hype curve where the credibility is not sustained yet
by realizations. The IT history lessons would not concur to support the EA far-
reaching claims; the result is that the business doubts it!
Although business is reacting to the technology push, they do not contest the
benefits but they are painfully aware of the potential cost of disruption, which
might break rather than make the company. Business requires solid justification
and careful planning before moving from the “status quo” to such a
revolutionary course, as SOA.
Without critical business input, the resulting IT only Enterprise Architecture
would mainly provide the Applications, Infrastructure and may be the Data
architecture, which is frequently the case, but not sufficient for releasing the
goods of the EA: process improvement, agility, strategic planning etc. The
business people will have little reason to consult it, the word spreads, and,
progressively, the EA loses its momentum. The loop is closed now. The business
was right to doubt it, after all.

Business, as well, got tired of the exotic IT acronyms like WS, SOAP,
REST, UDDI, WSDL, mashups, AJAX, ESB, BPM, BPEL, XML, UML,
TOGAF… some badged 2.0 now (and technology is changing at an exponential
rate these days - Ray Kurzweil’s law-, i.e. the situation is getting worse).
Furthermore, IT is not talking about Value Chain, business models, process
improvement, Six Sigma, regulation, customer satisfaction, Balanced Scorecard,
SWOT, KPIs, NPV, payback, the terms the business can understand.
On the other hand, is the business providing the Business Architecture
(process architecture, business information and vocabulary) necessary for IT to
comprehend and align the technology? No.

The net result of all this is the great Business and IT divide and an
increasingly highly charged atmosphere progressing towards a blame culture.
And the solution is the EA, which ought to mend all the evils of the
Enterprise, to cure the silo culture and patch the divide between Business and
IT. In a nutshell, EA becomes the ground of the already existing political battle
but, at the same time, the tool to mediate the political divide.
While the EA encompasses alignment of business, strategy, technology and
people, the IT takes the driving role without business and top management
support. How is this supposed to happen? After all, more than half of the EA is
not IT, i.e. business processes (how), strategy (why), information (what),
organization (who)… In fact, without a strong business leadership and
participation, EA would lack political support and fail to deliver on its promise
since IT alone cannot specify SOA services, improve processes, determine
usefulness of information.

In this phase, the best you can do is be convincing i.e. gain support for the
EA business case which you should express in financial terms. Spend energy to
rally critical stakeholders’ support in business and top management. Involve
them by planning adequate EA artifacts, in response to specific requests,
explaining what is in it for them.
Thinking in many Enterprises is tactical, at best. Firefighting would better
express the facts. The EA is strategic and accepted because of its strategy
promise but it may become a lip service only, with its execution ever postponed
in order to cope with tactical crisis. In truth, EA will compete for resources with
many other activities which have not been included in the EA scope, in the first
place.

Supposing the EA development moves slowly; it will be generating lots of

tactical-strategic conflicts: people need solutions yesterday, the market cannot
wait and the EA will provide the feature who knows when! Tactical projects are
approved then and co-exist and compete for resources with the EA program.
There is no easy solution to this except delivery on time and fit for purpose.
To reassure everybody have a clear, simple plan in place that you are confident
you can deliver to. You probably have one single try. Deliver often, iteratively,
emphasize value returned. Prioritize business needs, deal with the EA trigger
causes first, and deliver what the stakeholders requested. This is a program, so
business process discovery projects will probably have to be executed in parallel
to Applications, Infrastructure, Data architectures and other streams. Then add
views as DW/BI, Content Management, procurement processes, network
architecture etc. With a delivery plan in front, people can wait, if they trust you.
Otherwise, tactical projects win.

There are execution mistakes: ignoring important stakeholders, not

communicating properly or enough, not consulting relevant people, not
referencing and recognizing contributions, to name a few, provoking the
syndrome of "not invented here” i.e. you have not consulted us, where did this
come from"?
Enterprise knowledge is locked in people’s minds. To release this collective
wisdom you need negotiation skills, “selling not telling”. Otherwise the
information you may get for the EA may be of little value.

Define an EA vocabulary and Frequently Asked Questions (FAQ) to avoid

confusion and display the progress dashboard on the Web for transparency.
From your side, lack of EA development experience and poor definition of
scope, deliveries, not fit for purpose, i.e. (typically large documents with poor
focus) can increasingly deteriorate credibility as the development process is
stalled by unusable outputs and by disputes about how the artifacts are to be
used.

Agile processes with frequent deliveries and wide consultations will help
make the process transparent and accountable. EA roles and responsibilities have
to be well designed to avoid overlaps generating confusion and conflicts and, in
the end, politics. Work as a team is crucial as the domain and span of activities is
much too large.
Bottlenecks have to be quickly discovered and eliminated. Observe EA
inhibitors since they could stop your EA development early, and find ways to
conquer them from the beginning.
Accountability and empowerment, recognition and award as company values
will pave the way to progressive success in eliminating a culture of politics.
After the first few deliveries, it is important to police all other development
work, install EA compliance controls (checkpoints) in all relevant business
processes, provide training and easy access. Otherwise your EA may be ignored,
forgotten.

EA Risks and Change Management
EA is perceived as a threat as, in reducing duplication in process, platforms
and projects, it creates people redundancies, it brings change.

Change Management (CM) becomes essential in the Enterprise

transformation execution process since people can and will resist, will do
partisan fighting since, after all, their job is at stake for no grander purpose. CM
has to work along to provide a path forward for all affected by the migration
process to expose the greater good, to motivate. Early preparation is essential to
avoid problems.
The EA team must have a vast knowledge spanning business, IT and people
issues and be socially and politically astute. Selection of the proper EA team
constitutes the major risk in this development. This team will not only have to
develop the EA properly, but will have to explain it in simple terms everybody
can understand, and then gracefully deploy EA compliance controls in all major
business processes defeating the inherent resistance.

The Enterprise Architect has to be politically literate to justify EA/SOA,

argue the business case, rally support from stakeholders, keep management
informed and optimistic, do the work and survive the process!

Review checklist

121. List EA triggers.

122. Enumerate and explain EA roadblocks and give recommendations.
123. Talk about culture and politics.
124. How do you select an Enterprise Architect?
125. What do you need to sell the EA?
126. What are the political factors which have to be considered in EA
development?
127. Culture, what are the key elements?

Chapter 22

22. EA State, future Outlook and the Virtual

Enterprise

EA current state
It has to be said that the EA "body of knowledge" does not support the EA
effort much, since it is scarce, fragmented and contributed by practitioners rather
than academia. There is a reason for that. EA crosses the boundaries between the
theory and practice of business (existing since the dawn of time) and IT (still
young and playful, celebrating about half a century of existence), disciplines that
until now have been treated in utter separation. The Business side concocts a
system specification, the business analyst translates it and the IT implements it.
But business and IT have different vocabularies and set of skills, objectives,
plans and line management.
In current practice, the most adopted approach for structuring an Enterprise
Architecture is the four layer architecture: business, applications, information
and infrastructure. This, more often than not, leaves out:
• the people, the processes they execute and the organization alignment
• other stakeholders' interests (other than customer's) i.e. the
owner/shareholders/ investors, employees, community and as such,
ignores supporting business functions, processes and technology
• all other internal views, except for the main product view, omitting
for instance, the Support and Development functions
• all other IT stakeholders' views such as helpdesk, email, printing etc.
• all operating technologies other than IT (assembly line, cooking
equipment, bottling bands etc); as a consequence, EA may not serve
large segments of industry well
• The business architecture, key to the whole EA, and the logical
architecture.
The problem with Enterprise Architecture and existing frameworks is that
they are IT oriented, designed by IT for IT, ignoring the business views and
architecture.
One cannot understand what applications do without a picture of what
business needs to do and how it does it. In fact, without a business architecture,
the EA, or SOA for that matter, mean little: loose diagrams of a patchy
collection of systems without the unifying picture of the business structure and
delivery flows. The lack of a business architecture may be the grounds for failure
of Enterprise Architecture developments and SOA to deliver the touted benefits,
a motive for subsequent management skepticism.
Unfortunately, there are not many business reference architectures. In fact,
business talks about Value and Supply Chains. VRM (Value Reference Model),
SCOR (Supply Chain Organization Model). NGOSS (eTOM ) framework for
telecommunications is an exception. But the business frameworks are all
slightly different, a situation not dissimilar to that of EA frameworks.
Too often, from a design viewpoint, the context diagram and stakeholders'
Use Cases are omitted; the process design is delegated to business people with
no further control.
Data architecture consists solely of a To-Be Customer Data Integration (CDI
) exercise; the As-Is data architecture is seldom discovered for other types of
data except customer’s. Content Management and Data Warehouse/Business
Intelligence are usually the object of separate activities, not integrated to the EA.
There is frequently no security view, no navigation and often enough, no EA
tool and repository.
SOA, as well, is initiated for integration of a few isolated services, usually
in the web arena, ignoring the big EA picture; as such it does not re-use or
enable agility.
On the technology side, EA does alignment, standardization and integration.

EA usually represents the architecture i.e. the structure and operation
blueprint of IT the applications and technology delivering the main product, in
an attempt to simplify and standardize technology. End to end performance is
not managed simply because the human contribution is not accounted for in the
EA framework..
At best, it can be called an Enterprise IT architecture and most probably,
would raise little interest from potential stakeholders.
The truth is that the EA development can easily end up anywhere in the
absence of an agreed definition or framework, since there is too much variability
in terms of scope and deliveries.

The Virtual Enterprise
Porter conceptualized, in the 80s, the Value Chain (VC) of an Enterprise. A
VC categorizes the business functions of a company in primary (operations) and
secondary (support) functions. Porter also introduced Value Networks or
Systems consisting of a string of Value Chains contributing to the delivery of the
end product or value, where each VC is implemented by a separate Enterprise.

A business model specifies, amongst other, the specific way a firm

approaches and segments the market, delivers value to its customers, manages
relationships with customers and partners, and customizes its value chain and
core capabilities to return revenue. Ultimately, the business model characterizes
"the architecture of the firm and its network of partners".
A Business Architecture should be structured on the Value Chain, the
Business and the Operating Models of the Enterprise, since this is how the
business perceives architecture. The Operating Model is the necessary level of
business process integration and standardization for delivering goods and
services to customers as quoted earlier. Business units should be integrated and
standardized to various degrees according to business needs, There is no point in
standardizing the implementation of a SOA or SaaS service since the
implementation is hidden behind interfaces.

To succeed in today's business world, competition is not enough.

Collaboration, strategic alliances and partnerships are key. With the greater than
ever pace of competition today, outsourcing becomes an important strategy. And
through outsourcing, the supplier company will become part of your Value
Chain.
From a technology viewpoint, IT virtualization makes inroads in the
Enterprise by decoupling the concerns between business and IT, and between
applications and technology. while enabling outsourcing. Technology
virtualization allows the creation of abstract services, hiding their physical
implementation, and enables their exploitation over generic interfaces.

Many business functions of your organization (ultimately all) can be

outsourced. What traditionally was considered to be core functions is no more a
sacred territory for outsourcing. The difference in cost and efficiency between an
"on demand" or pay per usage outsourced service and an on-premises and self
manned typical function could be significant and hard to ignore.
This raises speculation on an Enterprise that outsources most or all its
business functions but retains governance for planning, coordinating operations,
budgeting and making all key decisions. In a Wikipedia definition "a virtual
organization is a firm that outsources the majority of its functions".
And another definition from Abbe Mowshowitz (1994): "the virtual
organization is a temporary network of autonomous organizations that cooperate
based on complementary competencies and connect their information systems to
those of their partners via networks aiming at developing, making, and
distributing products in cooperation".
A source of information is the www.virtual-organization.net. A similar
concept is the Networked Enterprise found in some literature.
The Virtual Enterprise (VE) can be successful, assuming it employs best of
breed outsourced services in a "virtual" Value Chain implementation consisting
of company and partner links.

Figure 22 - 88 - The Virtual SOA Enterprise
A VE operates over a virtual Value Chain i.e. a chain whose links are owned
by company and partners, blurring the borders between the Value Chain of the
firm, and the Value Network it is part of.
The Governance is the business function that defines and identifies the
Virtual Enterprise since most or all other functions of the Enterprise (primary
and secondary in Porter's definition) could be outsourced.

The VE is defined by a new operating model promoting collaboration and

B2B to take advantage of best of breed applications on the market. This VE
business model is increasingly enabled by the adoption of business process
outsourcing (BPO), application outsourcing - Software as a Service (SaaS) - and
in general by the fast adoption of infrastructure virtualization technologies, Web
Services, SOA and collaborative technologies of the Web2.0.
The "Virtual" Enterprise could be the darling of the entrepreneurial world,
specializing in management and governance skills while outsourcing most of the
Functions of the Enterprise today. The competitive advantage lies in the agility
of the value chain configuration and business model implementation based on
outsourced, best of breed services with on demand utilization and costs,
management focus and the small size/small costs of the company. The quality of
management is all that counts for the virtual SOA Enterprise.

The Virtualization of the Enterprise IT
Today, for historical reasons, the interface between business and IT is quite
convoluted and low level, leading to business having to understand and take
decisions about IT and IT having to understand the business workings. That's
why, when simple business meetings to discuss IT capabilities become debates
on the merits of WS SOAP relative to REST, the communication between
business and IT breaks down.
Technology choice should be in the IT domain rather than on the business
agenda and business should be able to change processes, rules and content
directly without IT intervention.
In this fast moving world, the business in an Enterprise, its logic, should not
depend on IT technology, that is, its type or implementation. Business activities
would be performed careless to technology and fearless to tomorrow's new IT
hype. Why bother with what type of infrastructure or platform - COBOL,
JavaEE or .NET, Smalltalk, 4GL or AS400 RPG -! At the same
cost/performance, this should be an IT choice which surely would change in the
future.

Business should be willing to adopt technology virtualization to be able to

interact with IT technology at a service level, where the negotiation between
business and IT is performed in a contractual communication language,
structured in terms of capabilities, relative feature merits and their cost. IT
functional and non-functional capabilities will be delivered under SLAs at an
agreed price.
IT virtualization is adding an welcome interface layer, hiding the IT
implementation complexity and technology. It represents a significant step
forward in patching the divide between business and IT, often materialized in the
blame culture we all know, since business people can then make abstraction of
the IT infrastructure, issues, terminology... No amount of good will solve this
divide until a good insulation (interface) virtualization layer is inserted between
the two. Business and IT will talk the language of business: services, QoS,
SLAs, capacity, security, a vocabulary they all understand. The business does
not have to talk or understand IT any longer, and vice versa, and could for the
first time, be in charge of business processes.

IT, in turn, becomes a true business service provider negotiating SLAs and
licenses, very much like an ASP (Application Server Provider). An IT
application suite would be offered as a set of business services now. In this
respect, new types of outsourcing services such as, Software, Platform or
Integration as a Service have recently appeared.

The Virtualization of the Enterprise Architecture (EA) Layers
An Enterprise may be described at a few typical Enterprise Architecture
(EA) layers: business, information, applications and infrastructure. To these, you
might add people/ organization and non-IT technology which are sometimes
neglected. Layers though, can be virtualized. This is the way it is done in the
network OSI (Open Standard Interconnect) standard where each of the layers
provides services over an interface to the layer above.
In the Enterprise space, the virtualization appears to seep upwards across EA
layers, from infrastructure to applications and business processes.
A. The virtualization of the IT infrastructure
a hot topic now in the Enterprise, is, quintessentially, about providing
an abstraction to the IT technology: servers, storage and networks. It is
about an interface layer hiding the infrastructure implementation and its
platform types. The benefits appear to be compelling: server utilization
grows inverse proportionally to the number of servers, the cost of the
occupied real estate and cooling.
What does infrastructure virtualization promise? Independence from the
HW infrastructure. Multiple applications and OSs run on one or multiple
physical servers. Virtualization is supported by blade systems as well,
where processing power is modularly scaled.
Processing power can be consumed "on demand" (IBM parlance); MIPS
can be purchased in an "utility" like model (HP talk). Storage will be
retailed as a commodity from a pool and I/O is ultimately virtualized.
An analogy can be made to the networks world where the leased
physical lines evolved into virtual circuits, VPNs with QoS characterizing
a virtual channel.
Virtualization evolves to “Real Time Infrastructure” that enables
configuration, scaling of applications and dynamic allocation of computing
resources as dictated by business calendar or load.
Virtualization provides light and less costly business continuity and
easier management. Ultimately the infrastructure can be outsourced to a 3rd
party and paid per usage. There is no longer need for getting expensive
skills, training employees, buying hardware, upgrading HW/SW every so
often, deprecating or disposing the hardware. No more headaches.
B. The virtualization of Applications layer through SOA
At the EA application layer, virtualization is provided by SOA through
standard interfaces and encapsulation, hiding the implementation
technology. In addition, SOA provides the standard integration technology
with communications implemented over standard protocols and interfaces
accessed in a standard manner.
SOA provides an abstraction layer above applications hiding the
communications and applications implementation technology. It should not
matter any longer how the applications and network are realized or what the
platforms are. Applications are in effect virtualized and offered as services.
Inside the application layer, Java and .NET have already introduced a
virtual machine abstraction layer between the applications and OS, and
Application Servers are providing even more abstracted functionality by
adding distributed transactions, persistence, security and other horizontal
capabilities.
C. The virtualization of the EA business layer
At the EA business layer, workflows would be implemented by process
and rules engines as orchestration of SOA and Web Services listed and
described in a catalogue (UDDI, WSDL).
This abstracts away the complexity of IT and its applications under a
layer which business people can understand, and now, model business
processes themselves. They would be able to design and change processes
using BPEL (Business Process Execution Language), as a composition of
SOA and SaaS business services, using graphical interfaces.
D. The virtualization of Information layer
For the EA information layer, MDM (Master Data Management) adds a
similar virtualization layer since most application will now utilize
information provided by this layer/hub rather than supplied by all other
applications. The MDM implementation may be integrated to SOA since
the MDM hub could become a SOA service for information access.
This will constitute a data abstraction layer for services and people
using the information.
E. The virtualization of the User Interface
From a User Interface point of view, the fine grained Web2.0
interactivity further abstracts IT technology from business logic by
providing a universal, ubiquitous web client, independent of application and
its implementation with the performance of client server applications. An
abstraction layer is introduced which consists of web servers understanding
AJAX, Adobe Flash and MS Silverlight-like technologies.

The Enterprise Value Chain modeling and Virtualization
A Virtual Enterprise (VE), as defined here, is a company consisting of a
majority of business functions outsourced in a BPO (Business Process
Outsourcing) manner. The BPO outsources the business processes, the
technology and people executing them, and as such all layers of an Enterprise
Architecture. Nonetheless, a governance corporate function should still exist to
coordinate all other function activities and legally identify the Enterprise.

IT virtualization appears at the interface between EA layers, at the same

time. At the EA business layer, the business process orchestration and rules
engines provide business people with the tool to rapidly change the Enterprise
workflows and rules without support from IT.
At the EA application layer, virtualization is provided by SOA through
standard interfaces and encapsulation of application, hiding the implementation
technology. What is more, SOA provides the standard service integration
technology.

At the EA information layer, MDM (Master Data Management) adds a

similar virtualization interface since most application would utilize the
information provided by this layer rather than supplied by all other applications.

Figure 22 - 89 - The IT Virtualisation, Outsourcing and EA layers
IT infrastructure virtualization adds an interface layer, hiding the technology
implementation complexity and enabling efficient management of the
processing capacity, storage and networks bandwidth. The IT infrastructure
progressively more becomes a “real time”, on demand service.

Overall, the virtualization of IT provides technology services to business

through defined interfaces which eliminate the nowadays tangled business-IT
interaction, and provide abstraction interfaces between the EA layers of the
Enterprise. There are multiple vertical and horizontal dimensions to the
Enterprise virtualization about to happen or already happening.
Companies could deploy IT virtualization technologies in combination with
outsourcing strategies as for instance (see picture):
A. entirely outsourced business processes (including the people
operating them) through Business Process Outsourcing
B. applications outsourced to Software as a Service, SaaS providers (or
ASPs) with own people operating
C. application managed services where only the managing of your
Applications and Infrastructure is outsourced
D. the whole IT infrastructure outsourced to dedicated data centers.
The IT virtualization will be pursued at all layers (BP orchestration and
rules, MDM information, SOA services and integration, IT infrastructure).

Soon, Enterprises will be consciously designed out of SOA and

SaaS services.
The business would take charge of its business processes through direct
orchestration of SOA and SaaS services and direct access to the business rules
technology.

Liberated from supporting most Value Chain functions, a company may

focus on its business planning, investing and creative management activities.
The company will be lean, composed of a mix of best of breed outsourced
services.
Other companies in the virtual Value Chain will similarly focus on fewer
value chain links where they specifically have a competitive advantage like
cheap or qualified labor, for instance: manufacturing in China, IT in India,
consumer products in Japan, design in Europe, R&D in the US…
The new Enterprise business model is based on collaboration, virtualization
technologies and the outsourcing of links in the Value Chain.
Porter's Value System concept links the Value Chains of all firms
participating in the product delivery process. Assuming, by extension, that each
and every link of a Value System and Chain is represented by a different
company, who manages the overall product delivery process, who plans and
governs, which single entity represents the legal identity of the combined
Enterprise?
Ultimately, the company consists of the Governance function which only
orchestrates the whole process flowing through all companies in the Value
System and assumes the legal identity of the Enterprise, for incorporation. This
virtual SOA Enterprise results from a new business model promoting
collaboration between outsourced best of breed processes and applications. It is
proved by the increasing success of application (SaaS), data centre and business
process outsourcing (BPO) and in general by the fast adoption of the
collaborative tools of web technology and services.
This demands good relationships and a reliance on collaboration. The web
services technology enables automated workflows over B2B interactions and
communications. SOA provides the structured architecture based on services
enabling this distributed Enterprise. The www is then the ESB of your virtual
SOA Enterprise.

The Future Outlook for EA
This looks like a legitimate question. Is Enterprise Architecture going
anywhere? It is, albeit slowly in the absence of an agreed practical framework
and clear proof of its business case. The reason is straightforward: EA is a
necessary "evil". Any system needs a blueprint enabling proper operation,
maintenance, planning...
To fulfill the expectations, EA needs to satisfy its many stakeholders in top
management, business, technology/IT and organization. Here are a few
directions, I can see the Enterprise Architecture progressing, in no particular
order:
A. EA will finally be recognized as a business discipline, having
incorporated Value Chains, Business Models, Strategic Planning ...
B. The EA evolves to increasingly cover business architecture rather
than IT alone; the Enterprise Architecture will be the result of the fusion
of IT, Business and Organization/People architectures; what is the value
of an applications architecture, without the process it implements or the
people operating it?
C. The governance for EA will be more & more business and top
management heavy; this is because it would be used in mapping the
strategy to components, to derive the enterprise transformation portfolio,
make investments and take strategic and tactical decisions.
D. The EA development will be increasingly triggered by Mergers &
Acquisitions and outsourcing activities; IT BPO , SaaS (ASP) are riding
a strong current right now.
E. The Enterprise Architect would be more and more called in the
business decision making process; because the EA architect deals with
the business logic, technology operation and strategy, is able to
understand both worlds and use both business and IT vocabularies.
F. A combined EA framework emerges to take advantage of the
strengths of various frameworks, such as Zachman , TOGAF, FEA and
others.
G. SOA is recognized as part of the EA program as the target EA style
of architecture and technology, rather than executed in isolation as it
often happens
H. EA would be increasingly required by shareholders/owners/investors
to provide the blueprint of the business operation to describe assets,
provide proof of regulatory compliance, map costs and profits on various
operations and align strategy. The US government mandates EA to the
public sector. EA would become a regulatory feature for public listed
companies.

Review checklist

128. Describe the current situation in the EA field.

129. What is usually not in scope of EA and how does it affect adoption?
130. Why is the Enterprise more and more virtualized?
131. Explain the EA layers virtualization.
132. What is the role of SOA in virtualization.
133. Describe the link between virtualization and outsourcing.
134. What are the suggested trends for EA evolution?

Chapter 23


The book proposed a model for building your Business Case for an
Enterprise Architecture, the solution to the Enterprise current issues, in terms
senior management can understand. It later suggests an EA framework,
metamodel, Enterprise Reference Map s – templates for building layers
architecture -, an Enterprise strategy development flow and a number of best
practices along the EA development process.

The EA Framework recap
The EA FFLV (Function-Flow -Layer -View ) describes a novel Framework
which can be used for any Enterprise complex enough to require a formal
description. It is similar to the skeleton of the human body, in that it is a
backbone for all other parts, EA artifacts.
The framework is composed of three layers: Business, Technology and
People. The Business Process layer, apart from important business information
and strategies, consists of a Business Functions Map and a Business Flow s
(Process) Map. The functional architecture is expressed as the Business Flows
over Functions .
FFLV links all architectural entities and artifacts in a navigable frame. It
unifies the process (BPM ) with the technology and organizational views. It is
anchored in the future offering planning and roadmapping views in the "when"
dimension.

The business functional decomposition starts from the basic Value Chain of
an Enterprise and a typical GODS Enterprise Structure: Governance ,
Operations , Development and Support (GODS) level 0 Functions .
The Technology layer means more than IT, and the People layer is more than
organization (+ culture, training…).

Specific aspects of an Enterprise are provided by Views , filters reflecting

various stakeholders' concerns as diverse as parking and car fleet.
An Enterprise Architecture tool will significantly add to the whole EA
development and management process, by offering an Enterprise component
repository and navigability. The EA tool metamodel should describe the EA
object repository with attributes pointing to the elements of framework:
Function/Flow /Layer /Views ,
Process/Technology/People and Governance , Operations , Development
and Support.. Interconnections between objects are expressed as outcomes
transmitted over lines.
Navigation is part of the framework, facilitated by a tool although, in this
book, a mapping technique was applied. The FFLV Framework cube represents
the Graphical User Interface of the EA, the entry point for navigation in search
of information.

By clicking on stakeholders, Flows, Functions Layers and Views , all

elements of the cube representation can be seen at different levels of detail. By
selecting a connection, the output and the link details should be seen (for
instance an electronic transfer of an Order over an IP connection or a part
moving over a production band). Navigation can be done vertically, through
Layers and Views inside a Function stack, or horizontally along interconnections
to inspect the deliveries, performance or costs of a Flow .
The FFLV is Open. First, it describes the basic elements of the framework.
From then on, you may define other views of interest to you and your
stakeholders. Take for instance the cost and profits of various Enterprise
Functions mapped to departments; a newly introduced financial View can
describe it.

The EA framework is in fact a Model Driven Architecture (MDA ) with

design starting at the Value Chain Model, continuing with the business
Functions Map and then the applications and infrastructure executing the
Functions.

The Key Steps of an EA Development
The process is initiated by describing the Enterprise context, mission and
products, stakeholders' interaction Use Cases and requirements; Next, devise the
business case, get it approved and create the EA design team and governance.
Then, identify the business architecture from the Business Reference Map ;
describe the EA buildings blocks, the business Functions , the business Flows
working over Functions, and the logical organization of the Enterprise, the
Single Page Architecture .

Specify the main stakeholders’ Use Cases using swimlane/sequence chart

diagrams. For each Function/sub-function identify processes and the required
resources, people and technologies to execute them. Diagram the
interconnections between functions, the Lines of communication and transport of
information and outputs/products.
Then add Applications, IT infrastructure and technology Views . Follow with
the Information, Location, Security and other Views.

The EA, as described in this book, may be realized in a few steps:

1. Assess EA business case (for each iteration) and get commitment.
2. Capture business information as Enterprise vision, mission, strategy,
objectives, risks, planning
3. Define the EA framework, Layers and Views
4. Determine Value Chains, Business/Operating Model s using the
Business Reference Map

5. Specify the business Functions and Flow architecture starting from
the Business Reference Map ; illustrate Stakeholders ' Use Cases as
Flows delivering documents and goods.
6. Design the Single Page Architecture .
7. Discover As-Is Enterprise Architecture
a. Specify each Function as Processes, Technology and/or People
executing the Processes; Technology consists of IT (Applications and
Infrastructure ) and non-IT technology.
b. Do application suite (e.g. ERP ) modeling that is, reverse engineer of
the existent software packages.
c. Map customers' SLAs to performance KPIs associated to Flows and
Functions .
d. Design selected Views (filters for various aspects of interest);
include Security and Master Data views.
e. Describe current Enterprise organization as departments mapped on
business Functions .
8. Specify To-Be Enterprise Architecture
a. Map strategy to Enterprise Functions and Flows to derive objectives
and performance KPIs.
b. Compile the applications and technology obsolescence roadmap
c. Design target Functions , Flows, Products, applications,
infrastructure, views and organization.
d. Design SOA by specifying Functions as Services
9. Assess the gaps between To-Be & As-Is and provide the
transformation roadmap.
10. Plan Enterprise Transformation
a. Establish EA governance and teams, create Transformation Project
Portfolio, specify schedule, budget and project resources.
b. Define implementation strategies (Top-Down, Bottom-Up , SOA
middle-out), deliveries and Critical Achievements.
c. Assess changes and specify change management measures.
11. Execute Enterprise Transformation Implementation iteration,
estimate Value and re-iterate
a. Re-engineer existing processes and technology.
b. Implement new governance and organization of the Enterprise.
c. Document EA as you go using an EA tool.
d. Add new stakeholders and Flows, SLAs, levels of decomposition of
Functions and Views as you iterate.

The EA Deliveries Checklist
What an EA should deliver for the first few iterations. Most artifacts shall be
diagrams to avoid long leafy documents. Here is a list:
1. EA Mission and statement of scope
2. EA development rough plan
3. EA governance composition
4. Business Case
5. The EA framework design, components/layers
6. This deliveries check list
7. The Business (Functions ) Map, Business Process Map, architecture
principles and technology guidelines
8. Context /stakeholders diagrams and Use Cases
9. As-Is and To-Be (with new Functions ) Business Functions Map
10. The Single Page logical Architecture
11. Documented current and target business flows for key stakeholders
starting with the customer and products; ERP modeling
12. Information Architecture
13. Applications inventory and interconnectivity diagrams and tables
14. Current and target application diagrams, mapped to processes in
Functions , with interconnections (Outcomes/Lines)
15. Data Architecture
16. SOA business services design for target EA
17. Infrastructure inventory: servers, storage and networks
18. Existing and target technology infrastructure Views
19. Existing and target non-IT technology Views
20. Existing and target people Views with departments/roles mapped
against functions and implicitly processes and technology
21. Business Strategy mapping to EA Functions (processes and
technology) and organizational units
22. Gap analysis and Enterprise Transformation roadmap
23. Planning of next few iterations

Implicitly available, through navigation, if using FFLV, should be the

matrixes of business Functions versus strategy, applications, infrastructure and
non-IT technology, data, people roles and organization.
Each layer should be described by increasingly more Views , as the EA
work progresses through iterations. The totality of views in a layer, if overlayed,
forms the layer architecture.

Critical achievements on the EA delivery path:

A. Clear mission & scope
B. Business case and commitment from stakeholders
C. EA framework definition including architecture principles
D. EA tool with embedded framework
E. Selection of EA governance, core team, design/implementation
strategies
F. Business Functions Map
G. Single Page Architecture
H. As-Is EA Applications Architecture
I. Strategy mapping on Business Functions Map and Target
Architecture s
J. Transformation roadmap

Why use the FFLV framework
The proposed FFLV model integrates most aspects covered by other
frameworks. At its base, sits the four layer architecture model - business,
information, applications and infrastructure - to which it adds:
A. the reference organization, business, applications and infrastructure
architecture maps to help structure your firm architecture
B. the Single Page Architecture as a key artifact to establish a common
vocabulary and single view for all stakeholders
C. the functional architecture, consisting of Flows over Functions
describing the operation of the Enterprise
D. people and organization, to align business activities and technology
to people roles and organizational departments
E. non-IT technology, in particular for including in scope many
Enterprises using other technologies besides it
F. Views , to describe in a single diagram, solely the aspects of interest
to a specific stakeholder; they look like CT scan views of a body
G. data, security, location, performance, financial and planning
architecture views
H. widely accepted UML and MDA for IT modeling, beginning with
the context diagram and stakeholders' Use Cases
I. Value Chains, Business and Operating Model s, well known
business concepts, harmonizing as such business theory and IT modeling
J. SOA as the architecture and implementation style of target EA
K. EA navigation, initiated from menus or, more conveniently, from
the graphical cube representation of the EA framework
L. vertically, up and down the function stack across layers and their
views, at various degrees of detail of the Enterprise Tree
M. horizontally, from function to function along the products/lines
N. an EA tool metamodel, by describing each EA entity in terms of the
layers Views and Function attributes it is part of
O. integrated view of Enterprise entities, rendering unnecessary
mapping matrixes by
a. structuring the Enterprise in a decomposition tree, browseable by
business Function, Flow or Layer /View
b. naturally aligning strategy, processes, applications, information,
infrastructure, people, and organizational units to business functions
under the Value Chain
P. Strategic planning, by cascading strategy objectives and execution
projects to the EA tree Functions , Flows, Organization and Technology.

EA stakeholders' benefits review
Overall, the EA is the bridge between the business and technology domains,
a tool used by both sides to cooperate in achieving the Enterprise objectives.
Enterprise Architecture appears to be, to most people, a long, expensive and
potentially unrewarding development. It has though beneficial impacts on
communication and culture by eliminating potential politics, created by lack of
governance and direction in a company. The EA
• serves as an Enterprise blueprint used for design, modeling and
enhancing comprehension of all stakeholders
• allows a company to treat all of its assets and projects as portfolios
• enables deployment of quality standards as SEI’s Capability Maturity
Model and Six Sigma and compliance frameworks as SOX
• allows for long term investment planning
• serves (especially the Single Page Architecture ) internal and external
communications and understanding
• allows alignment of business activities, organization and technology
to processes and objectives

Revisiting the audience’s needs and benefits, EA enables

CEOs
o to align governance (always forgotten) to the EA and improve the
decision making process based on a holistic Enterprise picture
Line -Of-Business executives
o to align technology investment to business objectives based on EA
roadmaps and Transformation Project Portfolio
o measure performance against SLAs with operational KPIs for each
Function and Flow
o manage assets and inventories in the EA tool
CTO, CIO and Chief IT Architects
o transform business strategy into technology, applications and
infrastructure replacement, simplification and optimization roadmaps and
programs
Business and Technology Strategists
o build a strategy (according to the given process), and trace it to the
Enterprise functions, processes, IT and organization
Architects and Quality Engineers
o set IT architecture guidelines and technology standards in conformity
with the EA Framework
o approve common data vocabulary and methodology for the Enterprise
Program Managers
o to adopt a holistic Enterprise Application /Program Portfolio approach
that makes possible the understanding of dependencies and realization of
synergies
Business people, owners, shareholders
o to understand how and if the Enterprise returns value to them by
checking specific views ROI, ROA (Return on Assets)…, financial
views
Regulatory bodies
o position compliance (SOX , Basel II , …) controls in the EA framework
Views such as Business Functions and Flows

The Enterprise Transformation Strategic process
EA, like Strategy, is about long term thinking. It is the way an Enterprise can
survive the furious rate of change and competition, the increasing acquisitions
and outsourcing trends and the exponential increase in complexity and amount
of information.

The Enterprise evolves from the current state and mission towards a vision
with stated goals and quantifiable objectives. The problem statement clarifies
what the problems are and why are you doing it. The Strategic directions
(strategies) determine the key programs of transformation by stating in
sufficiently general terms what needs to be done to achieve the goals, how the
transformation takes place. By implementing the transformation program the
Enterprise moves from one state to another towards the visionary state.

Figure 23 - 90 - Strategy Execution & the Enterprise Transformation plan

Final Say
Imagine you chose Not to develop an Enterprise Architecture, while your
Competitors do it. As our analysis shows, your products will reach the market
later, will be less reliable and your investors will lack confidence because your
Enterprise has no operating blueprint and the strategy is poorly executed since it
is not mapped to technology. Where does this leave you?
Finally, the answer to the question

”To Be or Not To Be” Enterprise Architecture"

is… “To Be”!

since the collective knowledge about the Enterprise, currently locked in
many heads, will be at last released, documented and published; the Enterprise
will be blueprinted, the projects executed as an Enterprise portfolio with a
combined ROI manifold increased. The divide between business and IT and the
silo organization will be issues of the past.

Care should be taken though, as the costs of developing an Enterprise

Architecture can render the Business Case negative as shown in our model.
Focus, best people for the task, a proper EA framework, and tight control are
essential.

Ultimately, EA is promising you a Competitive Advantage by streamlining

your Enterprise, enabling faster product delivery at lower costs, handling the
exploding amount of information and providing greater Enterprise agility to cope
with change. EA is an essential Asset, the knowledge DB of your Enterprise.
The hypothesis and conclusion of this book is that the EA will offer the
Enterprise the edge needed in the survival race.

Review checklist

135. Describe the FFLV framework in components.

136. Why would one use the FFLV framework?
137. Write down the main steps of the EA design process.
138. Illustrate in words the Enterprise Strategic Transformation process
139. List the minimum check list of EA development deliveries.
140. What is the hypothesis and the conclusion of this book?

References

I. described by M. E. Porter in his book, “Competitive Advantage”
II. http://www.value-chain.org/en/cms/?1960
III. http://www.supply-chain.org/cs/root/home
IV. Kurzweil’s Law – Ray Kurzweil: KurzweilAI.net March 7, 2001
V. Concepts of Framework for Enterprise Architecture – John
Zachman, 1996
VI. ANSI/IEEE Std 1471-2000
VII. GAO6-831, August 2006,
http://www.gao.gov/new.items/d06831.pdf
VIII. SearchCIO.com - CIO Definitions, June 8, 2005. October 13, 2006
IX. TOGAF FAQ 8.1
X. Jeanne W. Ross, Peter Weill, David C. Robertson, Enterprise
Architecture As Strategy, Harvard Business School Press, 2006
XI. Enterprise Architecture-Achieving Business Value with IT - MS
Solutions , 1999
XII. You Can’t Cost-Justify Architecture - John Zachman, 2003
XIII. described by M. E. Porter in his book, “Competitive Advantage”
XIV. 1993, Robert S. Kaplan and David P. Norton published the
Balanced Scorecard. In 1996
XV. "Concepts of Framework for Enterprise Architecture" 1993-
Zachman International
XVI. TOGAF v 8.1.1 Enterprise Edition,
http://www.opengroup.org/togaf. a summary
XVII. https://www.tmforum.org/browse.aspx
XVIII. more information available at http://www.enterprise-
architecture.info/
XIX. http://www.pera.net/
XX. Zachman on architecture frameworks, 1996
XXI. From www.ashlandschool.org
XXII. http://www.doi.gov/ocio/architecture/documents/core/rpt-
FEA_TRM.html
XXIII. http://www.opengroup.org/sib.htm
XXIV. Ostenwalder , Y. Pigneur, and C.L. Tucci
http://www.businessmodeldesign.com/
publications/Preprint%20Clarifying%20Business%20Models%20Origins,%20Present,
XXV. Jeanne W. Ross, Peter Weill, David C. Robertson, "Enterprise
Architecture As Strategy" book, Harvard Business School Press,
2006. Posted October 3, 2006
XXVI. http://www.value-chain.org/
XXVII. http://ww.itjobswatch.co.uk/charts/permanent-demand-trend.aspx?
s=enterprise+ architecture&l=uk

Acronyms

TERM DESCRIPTION
Authentication Authorization and Accounting – a
AAA
framework for controlling access to computer resources
ABC Activity Based Costing

API Application Programming Interface - A language and
message format used by an application program to
communicate with the operating system or other control
programs

B2B
Business to Business - E-commerce models that help
companies work together via the Internet

B2C Business to Consumer - E-Commerce models for selling
to consumers over the Internet
A framework with recommendations by bank
Basel II supervisors and central bankers from the 13 countries
making up the Basel Committee on Banking Supervision to
revise the international standards for measuring the
adequacy of a bank's capital
BC/DR Business Continuity/Disaster Recovery

BFM Business Functions Map/Model

BI Business Intelligence
BRM Business Reference Map

BOA Business Oriented Architecture
BoB Best of Breed

BPEL Business Process Execution Language - standard
XML based language
BPEL4People BPEL for Human Interactions
BPM Business Process Map/Model

Business Process Management - Monitoring and altering
BPM business processes that span multiple applications and
systems within and across the Enterprise

Business Process Modeling Language - a platform
BPML independent XML based language for modeling business
processes
BPO Business Process Outsourcing

BRM Business Reference Map; the generic Enterprise
Business Functions Map
CAPEX
Capital Expenditure - Money spent to acquire or
upgrade physical assets such as buildings and machinery

CDI Customer Data Integration
CEO Chief Executive Officer - The executive responsible for
a company's operations
Chief Information Officer – The executive responsible
CIO for management information systems or data processing in a
company
Clinger-Cohen The Clinger-Cohen Act (or Information Technology
Act Management Reform Act legislation) was created to
improve the way the US Federal Government acquires and
manages information technology

CMDB Configuration Management Database

Capability Maturity Model: organizational model
CMM describing 5 levels in which an organization manages its
processes (usually used in IT)
Customer Relationship Management - An integrated
CRM software system used to plan, schedule and control the pre-
sales and post-sales activities in a company
CRUD Create, Read, Update, Delete

Critical Success Factors - Key areas of activity in a
CSFs company in which favorable results must be achieved to
successfully meet objectives
CTO Chief Technology Officer - The executive responsible
CTO Chief Technology Officer - The executive responsible
for a company's technical part

DoDAF Department of Defense Architecture Framework (US)

DPMO Defects Per Million Opportunities (Six Sigma)

DW Data Warehouse

Extended Enterprise Architecture Framework from
E2AF
IFEAD

EA Enterprise Architecture
Enterprise Application Integration - connecting multiple
EAI applications within the Enterprise for the purpose of
interchanging data and coordinating business processes
EAP Enterprise Architecture Planning, Spewak

Enterprise Portfolio Management - how the organization
EPM is managing investment portfolios and makes investment
decisions
Enterprise Resource Planning - a multi-module software
ERP application used by companies to manage inventory,
resources, and business processes across departments
Enterprise Services Bus - open standards-based
distributed messaging middleware that provides secure
ESB
interoperability between Enterprise applications via Web

Services interfaces

enhanced Telecommunication Operations Map - a
business process model or framework that describes all the
eTOM/NGOSS Enterprise processes for a service provider in the
Telecommunication Industry
Next Generation Operations Systems Support
FEA PMO Federal Enterprise Architecture Program Management
Office, Reference Model
FEAF US Federal Enterprise Architecture - an EA framework
used by US government
FFLV Function-Flow-Layer-View - author’s proposed EA
framework
Porter’s Five Forces Analysis – a formal industry
Five Forces
analysis used in marketing strategies
Five Forces
analysis used in marketing strategies
GODS Governance Operations Development Support

– author’s Main Functions classification in an Enterprise

GUI Graphical User Interface
HR Human Resources

HTTP Hyper Text Transfer Protocol - a communications
protocol that enables Web browsing
IEEE Institute of Electrical and Electronics Engineers

Internal Rate of Return - A present-value based measure
IRR used for determining the compounded annual rate of return
on investments held for a time period of one year or more
ISO International Organization for Standardization

IT Information Technology

ITIL IT Infrastructure Library - Developed for the UK
Government, is a set of best practices in IT services
ITSM IT service management, based on ITIL

Java 2 Platform, Enterprise Edition - developed by SUN
J2EE Microsystems is a platform for the development and
operation of web-based applications
Java Database Connectivity - An IT standard for
JDBC database-independent connectivity between a computer
platform or device operating in the JavaTM environment
and a wide range of databases
Key Performance Indicators - Indicators used by an
KPIs organization to define and measure its progress toward the
goals and objectives
LoB Line of Business, Business Area

MDM Master Data Management

MOF Microsoft Operations Framework

NPV Net Present Value - The future stream of benefits and
costs converted into equivalent values today
Organization for the Advancement of Structured
OASIS Information Standards – an organization that drives the
development and adoption of e-business standards.
development and adoption of e-business standards.

ODBC Object Data Base Connectivity

Operating Expenses - Expenses incurred in conducting
OPEX normal business operations like wages, salaries,
administrative, research and development costs
Open System Interconnect - a reference model for
OSI
communications and computer network protocol design
Political, Economical, Social, Technological,
PESTEL Environmental, Legal – a strategic analysis framework used
by a company to identify the key influences of its
environment and industry
Payback Period - The amount of time taken to break
Payback
even on an investment
PMO Program Management Office

Return on Enterprise Architecture – author’s proposed
RoEA financial indicator to measure Enterprise Architecture
benefits
Return on Investments - a financial ratio used as a
ROI
measure of company’s performance
Software as a Service, outsourced, off premises
SaaS application a successor of the Application Service Provider,
ASP

Supply Chain Management - An integrated software
SCM system used to plan, schedule and control the supply chain
of an Enterprise

SEI Software Engineering Institute
Service Level Agreements – agreement between an
SLAs
Application Service Provider and an end-user
SMB Small to Medium Business

Service Oriented Architecture - Provides a blueprint for
SOA
services-based, Enterprise business solutions
Simple Object Access Protocol - a XML based protocol
for exchanging information in a distributed environment
SOAP

SOAP

SOEA Service Oriented Enterprise Architecture
SOX Sarbanes-Oxley Compliance - U.S. Public Company
Accounting Reform and Investor Protection Act
SPEA Single Page Enterprise Architecture
SQL Structured Query Language

SSL Secure Socket Layer

Single Sign-On – An authentication process that permits
SSO a user to identify himself once in order to get access to
multiple applications

SWOT Analysis - a strategic planning tool used to
SWOT evaluate the Strengths, Weaknesses, Opportunities, and
Threats of a company
TCO Total Cost of Ownership

Universal Description Discovery and Integration - a
UDDI
directory model for Web Services
UML Unified Modeling Language - an object-oriented
analysis and design language
VPN Virtual Private Network

eXtended Mark-up Language - language used to design
XML a markup language for easy interchange of documents on
the World Wide Web
WOA Web Oriented Architecture
W3C World Wide Web Consortium

Web Services - self-contained, modularized functions
WS using open standards that can be accessed across a network
independent of technical architecture.

WSDL Web Services Description Language - an
XML formatted language used for describing Web services
WS-Human Web Services process specifications for Human Tasks
Task interaction
About the Author

For many years now, Adrian has been working in Enterprise Strategy and
Architecture as a practicing architect and consultant. He managed both the
conceptual aspects of the framework and the practicalities and politics of the
Enterprise Architecture development.

Adrian teaches an own Enterprise Architecture and Strategic

Planning course. He has often presented and chaired EA conferences in the UK
and Australia and published on EA and SOA with BPTrends, ebizQ, Microsft
Architecture Journal. IASA, ITToolBox, the Ark-Group and Via Nova
Architectura.
He accumulated extensive experience in business and IT, working in
computers technology, telecommunications, airlines, health insurance,
government, utilities and banking industries as a Senior Manager and Pricipal
Architect in Accenture, LogicaCMG, Vodafone, Lucent Bell Labs and Nokia.

His challenge is to build the Enterprise Architecture framework everybody

can understand and use. But this is a long winding road.
His framework and novel single page generic business architecture concept
are available online at http://www.enterprise-architecture-matters.co.uk/home

agrigoriu
[i]
described by M. E. Porter in his book, “Competitive Advantage”
[ii]
http://www.value-chain.org/en/cms/?1960
[iii]
http://www.supply-chain.org/cs/root/home
[iv]
Kurzweil’s Law – Ray Kurzweil: KurzweilAI.net March 7, 2001
[v]
Concepts of Framework for Enterprise Architecture – John Zachman,
1996
[vi]
ANSI/IEEE Std 1471-2000
[vii]
GAO-06-831, August 2006,
http://www.gao.gov/new.items/d06831.pdf
[viii]
SearchCIO.com - CIO Definitions, June 8, 2005. October 13, 2006
[ix]
TOGAF FAQ 8.1
[x]
Jeanne W. Ross, Peter Weill, David C. Robertson, Enterprise
Architecture As Strategy, Harvard Business School Press, 2006
[xi]
Enterprise Architecture-Achieving Business Value with IT - MS
Solutions , 1999
[xii]
You Can’t Cost-Justify Architecture - John Zachman, 2003
[xiii]
described by M. E. Porter in his book, “Competitive Advantage”
[xiv]
1993, Robert S. Kaplan and David P. Norton published the Balanced
Scorecard. In 1996, they published the book The Balanced Scorecard
[xv]
"Concepts of Framework for Enterprise Architecture" © Copyright
1993-Zachman International
[xvi]
TOGAF v 8.1.1 Enterprise Edition,
http://www.opengroup.org/togaf. a summary
[xvii]
https://www.tmforum.org/browse.aspx
[xviii]
more information available at http://www.enterprise-
architecture.info/
[xix]
http://www.pera.net/
[xx]
Zachman on architecture frameworks, 1996
[xxi]
From www.ashlandschool.org
[xxii]
http://www.doi.gov/ocio/architecture/documents/core/rpt-
FEA_TRM.html
[xxiii]
http://www.opengroup.org/sib.htm
[xxiv]
A. Ostenwalder, Y. Pigneur, and C.L. Tucci
http://www.businessmodeldesign.com/publications/Preprint%20Clarifying%20Business%20M
[xxv]
Jeanne W. Ross, Peter Weill, David C. Robertson, "Enterprise
Architecture As Strategy" book, Harvard Business School Press, 2006. Posted
October 3, 2006
[xxvi]
http://www.value-chain.org/
[xxvii]
http://ww.itjobswatch.co.uk/charts/permanent-demand-
trend.aspx?s=enterprise+architecture&l=uk

An Enterprise Architecture Development Framework

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Enterprise Architecture Development Framework

Uploaded by

Copyright:

Available Formats

An

The Problem: today's unresponding “legacy” Enterprise in a world of

The book describes:

Paul Harmon, the Executive Editor of Business Process Trends

1. About the book

1. About the book

Why this book

The EA is commended because of the state of high entropy of the Enterprise,

From an EA viewpoint, the Enterprise is seen here as a blackbox, a cube,

Nevertheless, the modeling of an Enterprise, unlike that of other systems, is

The BRM is in reality a business design template. It is structured in four

An Enterprise may be then logically decomposed in a tree called a Business

A business process belonging to a function is executed by people and/or

The EA Framework proposed employs a Model Driven Architecture (MDA)

Overall the EA development process consists of:

The book is meant to be a practical guide for such a challenging

By defining the EA, the book enables:

2. EA provides a competitive edge to the

An EA will integrate in a single effort many fragmented or loose coupled

Conservative quotes from different industries vary between 10-30%

10. What is the hypothesis of the book? What do we want to prove?

3. The Problem and Drivers for Change

The current state of the Enterprise as seen by Zachman : “Enterprises have a

Every Enterprise has a structure, an architecture, and it works, more or less.

The Problem: the silo organization, the point solutions duplicating

The problem lies with the today's unresponding and undocumented

4. Enterprise Architecture, The Solution

But how can you control your Enterprise without a plan?

“The fundamental organization of a system, embodied in its components,

Architecture identifies the main components of an organization and the ways

A note: Enterprise Architecture is much too often associated to solely an

EA is the structure and blueprint of the Enterprise showing how it operates

18. Explain why the Enterprise looks like a puzzle?

5. Enterprise Architecture Benefits

24. What are the main type of benefits?

6. The Business Case and Return on EA (RoEA

How do you ‘cost-justify’ Architecture

Once implemented, EA simplifies the structure and confers modularity and

RoEA = Revenuearch / Costsarch = (1+p1)/( 1 –

RoEA = (1+p1)/( 1 – p) = 2, if assuming p = p1 = 33%

A % column is included for quantifying the impact on the financial indicator.

Figure 66 - EA Benefits Indicators mapped to Time to Market

7. Technologies referred to, supporting the EA

ESB is a standards based Enterprise Architecture Integration (EAI)

IT Service Management Forum (itSMF) coordinates the evolution of ITIL .

IT is segmented in four domains and 34 control objectives:

A business process is a sequence of tasks, performed by technology and/or

Business process orchestration is executed by a Business Engine working

Measurable: deliverables quantify targets and benefits.

Realistic: can be achieved the objectives with existing resources.

32. How would you use Value Chains in the EA development?

8. EA Framework s and Classification

FEA apart from the four architecture layers, business, Information,

The government's EA development is quite complex, given the size and

BPTrends EA pyramid has the advantage of clarity and the inclusion of

Some add a deliveries checklist, known as reference models (e.g. FEA ) to

9. The Function - Flow - Layer - View (FFLV)

A framework, in general, is a supporting system, similar to the skeleton of a

Using a framework, different parties deliver repeatedly the same outcomes.

A novel EA framework is proposed in this book. It merges various aspects of

A doctor, a surgeon cannot diagnose or operate without being familiar with

The flows and architecture delivering value to other stakeholders may be

From an EA framework point of view, it describes the operation of the

Information Architecture as such, while not a layer, can be abstracted as a