Introducción - A - La - Arquitectura - Empresarial (By William El Kaim)

Introduction to Enterprise Architecture
William El Kaim
Oct. 2016 - V 2.1
This Presentation is part of the
Enterprise Architecture Digital Codex
Copyright © William El Kaim 2016 http://www.eacodex.com/ 2

Plan
What is Enterprise Architecture?

• Enterprise Architecture vs. Application Architecture
• Why Enterprise Architecture?
• How to do Enterprise Architecture?
• Enterprise Architecture Layers Deep Dive
• What is an Enterprise Architecture Framework?
• Why Do I Need an Enterprise Architecture tool?
• Could I build my own Enterprise Architecture Framework?
• What is EA Governance?
• Conclusion: Resilient and Agile EA
Copyright © William El Kaim 2016 3

Enterprise Architecture (EA) Definitions
• 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 current and future objectives.
• Forrester, Gene Leganza, 2001
• “Enterprise architecture consists of the vision, principles and standards that guide the
purchase and deployment of technology within an enterprise”
• Gartner Group
• “Enterprise architecture (EA) is the process of translating business vision and strategy
into effective enterprise change by creating, communicating, and improving the key
principles and models that describe the enterprise’s future state and enable its
evolution.”

Plan
• What is Enterprise Architecture?

Enterprise Architecture vs. Application Architecture

Architecture Scope is twofold!
AA vs. EA
• What is Application Architecture (AA)?
• Application Architecture is the set of policies, practices, processes and tools to ensure
an optimal and secured design and construction of an information system that best
works for its business owner and users.
•Local Scope Project based decisions (Local) and delivery
•Low Granularity optimized within that context (Optimal)
• What is Enterprise Architecture (EA)?

• Enterprise Architecture is the Governance and overall Plan to effectively structure,
manage, integrate, secure and evolve the information system landscape of the company,
aligning to business and IT strategy
•Global Scope Globally based solution, ensuring company

•High Granularity Global architecture to be Coherent!

Architecture Scope is twofold!
AA vs. EA
Specific BU organization Specific BU organization
EWITA = Enterprise Wide IT Architecture

Plan

Why Enterprise Architecture?

Copyright © William El Kaim 2016

https://www.youtube.com/watch?v=qDI2oF1bASk 9
• The purpose of Enterprise Architecture (and city planning" for information

systems) is to define the main principles in the implementation and
construction of computer applications, to ensure consistency throughout
while decreasing the costs of building and integrating new applications.
• This should improve the company’s ability to respond to a constantly
changing environment.
• The city planning for the information system explains what the applications
do, documenting redundancies so they can be reduced.
• The application architecture defines or documents (maps) the structure of applications
and their services, showing the cooperation between them.

Manage IS complexity
• The introduction of new non-standard technology
• imposes a voluntary tax of 5 to 12% on the development budget, and an increase of 21
to 33% on project duration.
• Studies have shown that, over time, Enterprise Architectural efforts can
result in a reduction of annual IT spending by as much as 20%.
• More projects can be completed within a given project budget when Enterprise
Architecture Methods/Tools are followed than when they are not.
• Repair Cost are greatly reduced through EA by reducing errors in IT solution designs
early.

Manage IS complexity
• Alignment
• Ensuring the reality of the implemented enterprise is aligned with management's intent
• Change
• Facilitating and managing change to any aspect of the enterprise
• Resilience
• Reducing systems development, applications modernization
• Convergence
• Striving toward a standard IT product portfolio (service and asset reuse)
• Integration
• Realizing that the business rules are consistent across the organization, that the data
and its use are immutable, interfaces and information flow are standardized or controlled
and the connectivity and interoperability are managed across the enterprise

Providing Holistic Views
Enterprise Application
Architecture Architecture

Providing Holistic Views
Strategy Business
Business
Process
Process Plan
Function and
Services Service and
Functional
Plan
Security,
Integration,
Governance, Application
Etc.
Application
Plan
Holistic
Views
Infrastructure
Infrastructure
Operation and Plan
service delivery
Technology

• Enterprise Architecture is justified for businesses:

• which have significant application assets.
• which have a long history in information technology.
• where information technology is strategic.
• It may also be justified in:
• Mergers/Acquisitions
• Enterprises dependent on software packages
• Apart from these cases, city planning projects are rarely flagship projects.
• They must be low key, with no negative impact on other projects.

Plan

How to do Enterprise Architecture?

How To do Enterprise Architecture?
EA processes
• Understand
• My Information System (patrimonial)
• Its organization, its structure
Also referred to
• its components et its interactions City Planning or Urbanization
• Manage
• Analysis et KPI
• Projects Specifications
• Govern
• Bring under control Cost Risk, and IS risks
• Bring under control IS Performance
• Bring under control IS evolution

From As-Is to To-Be
• EA planning entails the definition of a current state (called AS-IS) or as-is

architecture in four categories:
• business processes
• application programs
• information/data
• and infrastructure technology.
• Then the business plans are reviewed and an appropriate future state (called
TO-BE) is created for each category.
• The future state is compared to the current state in a gap analysis, and a
sequencing plan is developed to progress from the current state to the future
state.

From As-Is to To-Be in Top-Down Approach
Business process Technical City Planning

Function / Service Constraints Design
Business
Strategy
Strategy
Existing Target
Business Business Business
Architecture Architecture
Target
Functional Functional
Architecture
Existing
Target
Application Application
Application
Architecture
Architecture

How to Do Enterprise Architecture?
From “AS-IS” to “TO BE”
Copyright © William El Kaim 2016 Source: Forrester 20

EA processes
The IS Urbanization process
Management
Drive the IS Urbanization process
Participate in the projects arbitration committees
Drive the implementation

and the evolution of the
Link IS urbanization with master data repositories
business strategy and IS Participate in the upstream
governance phases of the projects
Standardize and simplify
the exchanges between
applications
Elaborate and improve Monitor the architecture of
the IS urbanization the IS projects
framework (rules,
principles, EA targets) Build the link with
technical infrastructures
Maintain and deploy the map repository for the existing and target IS (processes,
Communication
applications, data, etc…)

Support &
Communicate and train on IS Urbanization
Relationships
IS Urbanization plans Infrastructure basics
with projects
Copyright © William El Kaim 2016 Source: Club Urba-EA 21

Assess Complexity: Club URBA-EA Index
6. Urbanization 1. Knowledge of
4
management and IS « as is »
communication 3
5. Flows complexity 1 2. Master data

management repositories management
0
4. IS building
3. Knowledge of
management IS « to be »
6 axis to understand IS urbanization maturity TO BE
(with 2 to 4 criteria per axis) AS IS
Copyright © William El Kaim 2016 Source: Club Urba-EA 22

Example: Carlson
Develop Define “Current” Develop “Target”

Develop
Core Business Architecture Core Business Core Business
roadmap
model Architecture Architecture
Pre–HAL
HAL Transition
Post-HAL
Before Q3 ’07 and
Q1 ‘05 Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q2 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07
31/12/04 beyond
Operational Data
– Scope, Operation Data – Build Phase
Analysis, Design
OD
HAL MI/PM Corporate Corporate Information
Information System Implementation
System Scoping,
CIS
Business Case,
Analysis
Press Control Systems Implementation
GPMS
Group Planning
Process and
System Group Planning Implementation
Requirements
Capture
Customer
Management
Benefits
Assessment
CM
Customer Management Implementation
Before Q3 ’07 and

Q1 ‘05 Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q2 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07
31/12/04 beyond
Build a foundation model that provides Define the “Current” Core business Develop the “Target” Core Business Create a high-level plan that defines
a functional representation of the Core and strategy, defined in terms of Architecture defined in terms of how the Technical and Informational
business at a Conceptual/Contextual process, systems and organizations process, systems and organizations architectures will change over time
level. This model will remain as a by creating current architecture views by creating target architecture views through a set of prioritized initiatives.
“High-Level” static reference point to through interviews and workshops. through interviews and workshops. The implementation of these initiatives
understand the key aspects of the Then validate with Business Owners Then validate with Business Owners. will be marshalled through the
business. Included in the model will overarching Core Enterprise
be examples (and relational diagrams) Target: Architecture.
of: Current State: •Core Business Plans
•Core Business Plans •Core Business Component Business • Define Roadmap initiatives
•Business Plans •Core Business Component Business Model (CBM) • Define initiative prioritization
•Business Component Business Model (CBM) •Core Business Locations Maps and dependencies
Model •Core Business Locations Maps •Core Business Org Charts • Create roadmap
•Business Locations Maps •Core Business Org Charts •Core Business Events Schedules
•Business Organizational Charts •Core Business Events Schedules • Map (CBM) to Application/Tech/Info
•Business Events Schedules • Map (CBM) to Application/Tech/Info Architectures)
Architectures) •Gap Analysis

Example: Business Connexion

Top-Down vs. Bottom-up
• Two major approaches to

enterprise architecture (EA)
have evolved
• a top-down approach that
assumes comprehensive scope
and strictly follows a formal
process
• a bottom-up approach that starts
with infrastructure technology
standardization and then moves
up the food chain to target high-
priority problem areas and
eventually influence business
architecture

Top-Down vs. Bottom-up
• Each approach has its benefits and drawbacks, but it is far from arbitrary
which is an appropriate model to choose — it is imperative that the approach
fit the culture of the organization.
• Organizations that need to address significant inefficiencies and redundancies in their
business process or application portfolios and can wait at least a year for measurable
benefits should start with the top-down approach.
• Organizations that need results that affect the bottom line quickly or those where
rampant technology diversity has degraded service delivery quality should start with the
bottom-up approach (Brownfield).
• The best approach is often a combination of both

The private sector and start-up favored the bottom-
up approach.
Positive aspects Negative aspects
• The program can have significant impact • The typical infrastructure origin hampers efforts to
immediately (six to 12 months). expand scope. Once the infrastructure-based EA
• Early successes build credibility rapidly. group has cleaned up technology standards and
Early wins start the EA effort off on the right attempts to broaden its scope, it is often blocked from
foot and build much-needed credibility for the influencing application development staff for political
more politically complex efforts that follow. and cultural reasons — and the effort can stall.
• It attacks problems in priority sequence. The • A standards-based approach introduces governance
potentially overwhelming scope of an EA as a police action. The most typical introduction of
effort is simplified in a bottom-up approach: governance is via an architecture review board that
the biggest problem is attacked first reviews projects designs and rejects nonstandard
• Scope and complexity build gradually. approaches. This makes architects the bad guys and
Bottom-up allows technologists and can hamper IT community buy-in and future attempts
managers to learn as they go. at expanded scope.
• It does not need a large central EA team at • The initial technology focus appears insensitive to
the outset. Involves a central project business issues. Governance processes introduced
manager and the borrowed expertise of to prevent the introduction of nonstandard technology
internal SMEs. There is no need for please neither application developers nor business
additional staff. project sponsors. It smacks of a “technology for
technology’s sake” attitude that is far from business-
enabling.
The public sector and regulated business favored
the top-down approach.
Positive aspects Negative aspects
• It begins by establishing a clear view of the • Top-down programs can be overly abstract
existing environment. and have little impact in the short term.
• The initial data collection activity enables • The data collection process delays the
a consensus regarding the current state introduction of governance.
environment, which is a critical element • The formal methodology requires training to
for effective planning. get started.
• Business issues are emphasized at the • The methodology implies business process
outset. re-engineering skills.
• The top-down approach is explicitly about • The EA organization will have to draw
improving the business. important conclusions from the analysis
• Technology plays a subservient role as of the as-is architecture data.
the enabler of the business. • But these skills are typically the realm of
• It establishes broad scope at the outset. senior business consultants; it remains to
• With the appropriate management be seen if many organizations that have
support, all areas in need of improvement followed this approach will find value in
become subject to the EA program’s having assembled their business process
scrutiny. portfolios.

Top-Down vs. Bottom-Up
Example: Aventis
Top down Bottom up
Process re-designed Product / Service re-designed
New application developed to Core modules developed to support

support standardised process standardised process
Data migrated Core module progressively added

"seamlessly" to existing landscape
"Big bang" launch Existing landscape adapted as necessary
All existing applications retired Applications retired on a case by case basis
Top down approach is effective when : Bottom up approach is effective when :

• Existing landscape is simple • Country/site specifics are significant
• System can be implemented and supported centrally • Different functions are involved and moving at a
• Strong business direction has been given different pace (priorities, budget, resources)
Examples : HR Examples : SAP

Key Deliverables
Business Architecture Organigrams, actors
Operational processes
Business Business Glossary,
Process Architecture description, activities, business
Business Objects,
objects
Cartography & functional

Information Model zoning, mapping
Features master & reference Functional Architecture function/application, functional
data architecture schema,
repositories.
Information
and Data Application functional coverage
Architecture Interfaces: messages analysis, inter-application
Application Landscape
and data exchange dependencies and interfaces,
application logical architecture
Information
System Technical architecture (layers),
Conceptual data
Application Architecture Software components, non
schema
functional requirements
Code and infrastructure

Technical data
Infrastructure Architecture architecture. Deployment
schema
architecture and configuration

Plan

Enterprise Architecture Layers Deep Dive

Enterprise Architecture Layers Deep Dive
TOP
The Business Vision, goals

Business Process Plan and processes
Business objects, capabilities,

services, functions, etc.
Service and Functional Plan
The Application and Data

Technical Design
Application Plan
The description of the

Technical Infrastructure
Technical & Infrastructure Plan
DOWN

Business Architecture
• Defines the:
• Business Strategies, Processes, And Functional Requirements.
• Purpose, goals, structure and plans of the enterprise (like organizational structures,
major locations, and relationships with partners and customers) from a business
perspective
• Major process domains for the enterprise (E.G., Product development, sales,
distribution, etc.), specific processes within those domains and operational parameters
for the processes (E.G., Transaction volumes, roles, centralized vs. Mobile operation,
etc.).
• An Enterprise Architecture approach to Business Architecture
• Provides the tools the business needs to ensure the quality and consistency of business
design and reengineering efforts.
• Guides the development of the it/is architecture
• Must be accurately documented to ensure it is understood.

Objectives
• This layer focuses on the business processes in the context of a business

strategy.
• Starting from business needs defined by the business strategy, an enterprise
architect, working closely with the different lines of business in an
organization, can start modelling the major enterprise business processes.
• This will help the architect understand the global and major processes of an
enterprise and will promote the approach by involving business
representatives.
• Using BPM tools, business analysts can simulate the business processes,
providing a measurement of the optimization that occurs when doing process
reengineering.
• The business processes plan is owned by the business. The architect's role
consists mainly of capturing the business needs and identifying common
business services usable through different business lines in an organization.
Urbanization axis
• Definition of business process and their taxonomy

• Categorization of Processes (Governance, operational, support, ...)
• Definition of transversal processes (shared services)
• Concentrate on target process and critical ones (value chain)
• Clear definition of roles (ownership, responsibility, optimization)
• Describing processes lifecycles and end to end value chain lifecycle
• Define also non core BP, especially for Business Process outsourcing
• What is important is not to do a cartography, but to find, analyze, improve,
and optimize the value chains.

Business Process Management
• BPM is a management practice that provides for governance of a business

process environment toward the goal of improving agility and operational
performance.
• BPM is a structured approach employing methods, policies, metrics,
management practices and software tools to manage and continuously
optimize
an organization's activities and processes.
• Main Mission
• Initiate the review and assessment of existing Business Processes end-to-end with
Business Process Owners and Sponsors;
• Help design and implement process changes with a view to unlock hidden savings,
enhance performance and improve customers experiences through efficient
organizational changes and effective application of IT.

Bus. Process Terminology and Hierarchy
Business Process

Example: BP Hierarchy

Example: BP Hierarchy

Example: Process/App Cross Reference

Example: Schlumberger

Example: Schlumberger

Example of Matrix: BSI Bank

Functional Architecture
• After designing the major processes of an organization, major functional

blocks can be identified.
• The Functional Architecture defines the:
• Structure of the system’s functions/Services and their subfunctions/subservices and how
they are related (city planning).
• The execution sequencing of the functions and/or orchestration of services
• Principles and policies that govern information ownership, use, and management across
the enterprise.
• The scope and priority of each application from the landscape
• Application context: interfaces with other applications, data produced and consumed
(master data, reference data, etc.), actors, etc
• Maps with
• Application or Business Architecture

Functional/Service Architecture
The need to talk the same language
• Common entities and common domain models are defined in such a way
that they have common meaning in the organization and can be reused in
different lines of business.
• A city-planning metaphor can be used in this plan: Assembling the functional building
blocks into quarters and zones relate to the different lines of business in the
organization.
• A common language will promote the reuse of the functional building blocks
and the data that will be shared between those blocks.
• The canonical models should be shared in an enterprise repository.
• Governance considerations should define the way those models should be designed,
accessed, validated, and amended.

Functional Plan
Zoning and Mapping
• The description on the functional plan is made in business terms, divided in

such a way that it can be mapped to functions, information, applications and
services within applications.
• After identifying those functional building blocks, communication between
those blocks should also be defined, which means a canonical data model is
defined.
• This canonical model can be described using UML models leading to XML
representation of the data.
• This common language should be shared across the entire organization.

Functional Plan
Urbanization Rules
• Distinguish operational process and support process.

• Identify link between processes
• Define hierarchy between links.
• Identify functional block that constitute the process.
• Identify triggering event to launch and stop the process.
• Model processes and manage process anomalies.

The Capabilities Of A Credit Granting Process…
Corporate Credit
Product Collaterals Data First Product Collaterals Final Vote Get Check Collaterals
Rating Config- Payment
Selection Acquisition Entry Vote uration Evaluation & Decision Signature Contract Registration
Processes Building Credit

Product Collaterals Data First Product Collaterals Final Vote Get Check Entry in
Scoring Config- Land Payment
Selection Acquisition Entry Vote uration Evaluation & Decision Signature Contract Register
Consumer Credit
Product Data Get Check
Scoring Vote Decision Payment
Selection Entry Signature Contract
Disaggregation of the value chain
Product Product Collaterals Check

Scoring Scoring Rating Vote Decision
Configuration Configuration Registration Contract
Functions
Product Product Entry in Collaterals Collaterals Collaterals Get Data
Payment
Selection Selection Land Register Evaluation Evaluation Acquisition Signature Entry

Functions – The New View
Customer Facing Channel Partners
• Within a traditional bank, operations Business
Customers Banking Business
Partners
are captured in 5 areas 1. Develop 2. Generate
• Develop Product / Service Product / Demand
Service
• Generate Demand
• Fulfill Demand 5. Collaboration
• Plan & Manage the Enterprise 3. Fulfill 4. Plan &

• Collaboration Demand Manage
Enterprise
• Outside of the bank, external entities

are shown
• Customers and Suppliers/Partners Service Providers Regulatory
Institutions
• Service Providers
• Channel Partners
• Regulatory Institutions

Functions – The New View
• Within the traditional bank, operations

are captured in 5 areas
• Develop Product / Service
• Generate Demand
• Fulfill Demand
• Plan & Manage the Enterprise
• Collaboration
• Outside of the bank, external entities
are shown
• Customers and Suppliers/Partners
• Service Providers
• Channel Partners
• Regulatory Institutions

Module Map Decomposition
Customer Facing Channel Partners Suppliers
Enterprise 1. Develop Product / Service 2. Generate Demand

1.1. Develop Product / Service 2.1. Partner Relationship 2.2. Marketing
Mgmt.
2.3. Sales
5. Collaboration
5.1. Strategic Collaboration 5.2. Planning Collaboration 5.3. Operational Collaboration
3. Fulfill Demand 4. Plan & Manage Enterprise

3.1. Provide Service 4.1. Financial Management
3.2. Advanced Planning 3.3. Procurement

4.2. Project Management
Level 2
3. Fulfill Demand
3.3 Procurement 4.3. Human Resources
3.5. Logistics
3.4. Produce Product 4.4. Property and Advisory
Logistics Providers Financial Service Providers

Customer Facing Channel Partners Suppliers

5. Collaboration
3. Fulfill Demand 4. Plan &
3.1. Provide Service Manage
3.2. Advanced Enterprise
Planning 3.3. Procurement
3.3.1 Sourcing and Supplier Contract Management
3.3.2 Purchasing
Level 3
3. Fulfill Demand
3.3 Procurement
3.3.2 Purchasing
3.4. Produce
Product
3.3.3 Receiving of Indirect / Capital Goods and Services
3.5. Logistics

Customer Facing Channel Partners

5. Collaboration
3. Fulfill Demand 4. Plan &
3.1. Provide Service Manage
3.2. Advanced Enterprise
Planning 3.3. Procurement
3.3.1 Sourcing and Supplier Contract Management
3.3.2 Purchasing
3.3.2 Purchasing
Level 4
Request Resources
Manage
Create Perform
Requisition Create
Purchase Encumbrance
Approva Auction Bids
Requisitions Check
Processl
3. Fulfill Demand Acquire/Purchase Resources
Create
Choose or Manage Consolidate
Verify/ Create
Default Purchase Approved
3.3 Procurement
Negotiate Purchase
Supplier for Item Requisitions
Price Orders
Goods Catalog by Supplier
Manage Purchase
Purchase Purchase
3.3.2 Purchasing
RFI/RFQ/ Direct
Indirect Capital
RFP Materials &
Materials Goods
Purchase
process Supplies
Purchase Manage
- Request Resources
Manage
Automatic Outside Open to Track Open
Replenish- Vendor Buy/Blanket POs
ment Services POs
- Create Purchase
Approve
Manage & Validate
Requisitions
Purchasing Contract
Methods Payments
Requisitions
Manage Suppliers
Manage Track Maintain Manage

Supplier Supplier Supplier Buyer
Relationships Commitments Catalog Performance
3.4. Produce Provide Supplier

Self-Help
Product
3.3.3 Receiving of Indirect / Capital Goods and Services
3.5. Logistics

Functional Plan
Example: Reference Archi. For Banking

Functional Plan
Example: BSI Bank

Functional Plan
Example: Hospital (French)

Information Architecture
• Defines the
• Result of modeling the information that is needed to support the business processes and
functions of the enterprise.
• Data models, information flows, and an analysis of all inputs/outputs and decision-
making criteria for each of the activities of the business.
• Is often included in functional architecture
• Maps with
• The Information Architecture spans organizational boundaries and ties the business
processes identified in the Business Architecture together by identifying and defining
information dependencies.

Urbanization Rules
• Determine functional block or capabilities uniqueness.
• Define functional rules related to each functionality.
• Define synchronization rules for each flow
• Identifier triggering elements for entering or quitting a flow
• Identify enrichment rules to define business process
• Identify information or data used for from any transformation required during
the end to end flow
• Analyze flow volume and frequency
• Identify Referential data (also called master data)

Functional Plan / Information
Example: Geodis

Synthesis
• Process are decomposed by successive step until business functions appear.
• Business functions obtained could be automated or manual and can be common to
several processes.
• In term of granularity, a function could be macroscopic and call several application
services for execution

Application Architecture
• Defines the:
• Solution framework focused on developing and/or implementing applications to fulfill the
business requirements and to achieve the quality necessary to meet the needs of the
business.
• Technical standards, shared services, patterns, guidelines and templates for building
and integrating applications, and data architecture to be deployed.
• Data architecture of an application (database architecture, replication mechanism, data
models, etc.).
• Technologies required to support general infrastructure requirements (e.g., e-mail, file
sharing, desktop computing) as well as hardware and software infrastructure for
enterprise data and applications (e.g., DBMS, servers, networks, application server
software, data warehousing, etc.).

• Defines the requirements for the “ilities”

• Quality can be measured in terms of reliability, scalability, availability, performance,
security, etc.
• In addition to the structure and interrelationships of an individual application, Application
Architecture also concentrates on optimizing and managing the integration of multiple
applications.
• Application Architecture is expressed in terms of principles and guidelines governing
application design and evolution.
• These principles and guidelines address the entire lifecycle of an application from initial
development, through sustaining evolution and maintenance, to replacement or
retirement.
• Maps with
• The relationship between the applications and the function/services of the IT Architecture

Urbanization Rules
• Attach/ Mapping functionality and application or application components and

services
• Identify data flow between applications.
• Identify non covered, redundant, partially or fully covered functionalities in
applications
• Identify processes gap les ruptures or incomplete application coverage.
• Identify application common data.

Urbanization Rules

Urbanization Rules

Other Possible Urbanization Axis
• Unify Repositories/registries (master data)

• Defining and controling Data exchange: Replication, B2B, Backup
• Application categorizations following reference architecture or specific
framework
• Application landscape rationalization
• Standardization and control of interfaces
• Identification of horizontal shared services
• Exhaustive description of application dependencies
• Clear description of link with Functional and Infrastructure layers

Example: Embraer

Example: Embraer

Operational Architecture
• Also Named
• Technical or Infrastructure Architecture
• Defines
• The technical foundations to support the applications, data, and business processes
identified in the other three architectural layers.
• Contracts like Service Level Agreement, Business Disaster Recovery Plan, etc.
• Defines the tools and processes necessary to establish, monitor, manage and measure
all aspects of the technology, application and data assets of the enterprise.

• Identifies and plans the computing services that form the technical
infrastructure for the enterprise.
• These computing services provide the mechanism for achieving scalability, reliability,
availability, flexibility, security, integrity, and performance.
• The computing services are components which applications and infrastructure
developers can utilize in the development, customization, and/or integration of
applications in support of the business. Operations and service delivery processes like
process framework (ITIL), Service Operational Procedure (SOP)
• Must be aligned with the previous layers
• The most difficult layer to adapt, the most expensive (recurring cost) and the most
outsourced …
• Green IT puts also some pressure on teams.

Product Architecture
• Defines
• A subset of operational Architecture
• Standards and configurations for the enabling technologies and products within the
Technical Architecture.
• Applications and infrastructure developers utilize these technologies and products for
delivering services to the applications and/or business processes.

Examples

Example: Operations Center in 3D
Implenia facilities operations center
Source: EOLUS One island in Second Life

Example: IBM Center in 3D

Plan

What is an Enterprise Architecture Framework?

Why need an Enterprise Architecture Framework?
• In a large modern enterprise, a defined framework is necessary to be able to

capture a vision of the “entire organization” in all its dimensions and
complexity.
• Enterprise Architecture is a program supported by frameworks, which is able
to coordinate the many facets that make up the fundamental essence of an
enterprise at a holistic way.
• That’s why architecture frameworks have become critical for enterprise
architects.
• Just like the old saying, “if you don’t know where you want to go, any road will take you
there”

Enterprise Architecture Framework Objectives
• Establish terms and concepts for architectural thinking and provide a uniform
way to talk about Enterprise Architecture
• Gain a 360-degree view across IT and development projects and propose
real-time visibility to make rapid, well-informed decisions
• Operationalize best practices and automate portfolio processes
• Increase collaboration between Development and Service Delivery teams
• Codify current best practices and insights of both the systems and software
engineering communities
• Promote (micro)Service or Resource Oriented Architecture

Framework(s) for EA
A Standard Exist: ISO/IEC/IEEE 42010:2011
• IEEE 1471 is the short name for a standard formally known as ANSI/IEEE
1471-2000, Recommended Practice for Architecture Description of Software-
Intensive Systems.
• Within Institute of Electrical and Electronics Engineers (IEEE) parlance, this is a
"recommended practice", the least normative of its standards.
• In 2007 this standard was adopted by ISO/IEC JTC1/SC7 as ISO/IEC 42010:2007,
Systems and Software Engineering -- Recommended practice for architectural
description of software-intensive systems.
• In 2011 it was superseded by ISO/IEC/IEEE 42010:2011, Systems and
software engineering — Architecture description.

Framework(s) for EA
Standard Exist: ISO/IEC/IEEE 42010:2011
• IEEE 1471's contributions can be summarized as follows:

• It provides definitions and a metamodel for the description of architecture
• It states that an architecture should address a system's stakeholders concerns
• It asserts that architecture descriptions are inherently multi-view, no
single view adequately captures all stakeholder concerns
• It specifies the notions of view and viewpoint, where a viewpoint identifies the set
of concerns and the representations / modeling techniques, etc. used to describe the
architecture to address those concerns and a view is the result of applying a viewpoint to
a particular system.
• It establishes content requirements for architecture descriptions and the idea that
a conforming architecture description has a 1-to-1 correspondence between
its viewpoints and its views.
• It provides guidance for capturing architecture rationale and identifying
inconsistencies/unresolved issues between the views within an architecture description

Framework(s) for EA
A Standard Exist: IEEE-Std-1471-2000

Source: IEEE 80
Framework(s) for EA
Most Used Frameworks

Framework(s) for EA: Some History …
Zachman
2003
Zachman DOD
1987 TRM
DODAF
TAFIM 2003
C4ISR
1999
TOGAF 9
JTA 2009
ISO/IEC
14252 TOGAF 8.1
2003
TOGAF
TEAF
1995 TOGAF 10
2000
2003
E2AF
EAP 2003
1992 FEAF
Reference 1999
TISAF FEAF
Adopted By
1997 2003
Influenced
IAF V3 XAF
Supported By 2001 2003
UVA Model IAF V1
1994 1996
Zachman Framework
• The Zachman Framework, invented by John Zachman in the 1980s at IBM,
is an enterprise ontology and is a fundamental structure for Enterprise
Architecture thinking.
• The ontology provides a formal and structured way of viewing and defining
an enterprise using a two dimensional classification schema that reflects the
intersection between two historical classifications.
• The first are primitive interrogatives: What, How, When, Who, Where, and Why.
• The second is derived from the philosophical concept of reification, the transformation of
an abstract idea into an instantiation.
• The Zachman Framework reification transformations are: Identification, Definition,
Representation, Specification, Configuration and Instantiation.
• The Zachman Framework is not a methodology in that it does not imply any
specific method or process for collecting, managing, or using the information
that it describes.

Zachman Framework View described by its
viewpoint
Process
centric
Views
IT
centric
Views

Source: Zachman 84
TOGAF 9
• TOGAF was created and is maintained by The Open Group, an independent

industry association.
• It builds on an earlier framework known as TAFIM, or Technical Architecture
Framework for Information Management, originally devised by the U.S.
Defense Dept. In early 2009, The Open Group released TOGAF version 9.
• The basic TOGAF 9 document contains descriptions of an architecture
development method and related techniques, an architecture content
framework, an enterprise continuum, TOGAF reference models and a
capability framework.
• Version 9 creates a model for extensibility, among other enhancements.

TOGAF 9

Source: Open Group 86
TOGAF 9

TOGAF 9

Praxeme PRAXEME
Semantic, Pragmatic, Geographic
Logical, Software Model
Technical,Physical and Material
Use Praxeme as EA resilient Methodology

and implement your project with the
development process of your choice

Source: Praxeme 89
Framework(s) for EA: Octo Techology
Process
centric
Views
IT centric
views
IT centric
views

More Enterprise Architecture Frameworks…
Copyright © William El Kaim 2016 Source: PEFF 91

What an Enterprise Architecture Framework is not?
• An architecture framework does not include a methodology or process for

enterprise architecture.
• It also does not ensure that individual programs and projects fit into a global EA vision.
• It does not explicitly recognize the importance of other enterprise IT
dimensions and how they’re tied together
• For example, the importance of architectural governances or the different ways of
transitioning an enterprise.
• It does not depend on particular tools

Conclusion: Framework(s) for EA
• Each Framework has its own advantages and drawbacks

• No framework tells you how and where to start and this is a big question
• No framework tells you how to progress or to do it iteratively (methodology and/or EA
Governance)
• Some sources define a framework by describing what it contains (Togaf), and some
define it describing what it does (Zachman).
• Recommendations
• Chose the one the easiest framework to evangelize to your project architects, CIO,
developers, project managers.
• Taylor it to your requirements and know what you are not yet covering.
• Enhance it iteratively but do not change it each year (if possible)

Plan
Why Do I Need an Enterprise Architecture tool?
• Could I Build my own Enterprise Architecture Framework?

EA Tooling: Just For Drawing?
• Enterprise architecture is a discipline that uses drawings and diagrams.

• All real world EA contain lots of diagrams, and many are deemed central to the story
being told.
• This is because enterprise architecture is trying to represent n-dimensional data about
businesses and systems in two dimensions.
• Architects, engineers, and cartographers have worked for centuries to do the same thing
in their domains.
• Graphical abstract representations of complex relations are vital if we are to
understand, explain, and control IS environments.

EA Tooling Benefits
• Establish a common “culture” globally and aligning to best practices, IT

policies and business strategy
• Architecture Governance
• Project Development Methodology
• Centralized Documentation
• Minimize risks due to local centric architecture choices, for the projects and
for the company IT environment
• Technical Standards
• Leverage common solutions, reduce overall cost and maximize coherence
and synergy across systems and development platforms
• included software promotion and change management control
• Reference Architecture and Building blocks (Service)

EA Tooling Benefits
• Facilitate alignment and integration across projects

• Pattern and Best Practices
• Design and implement common, continuous and end to end Quality System
and SLA
• Better management of software supplier
• Better management of Operational Practices (ITIL)
• Rationalization of operations architecture
• Better knowledge of software landscape
• Application Portfolio Management
• The direction provided by vision and the as-is condition provided by context allow IT and
the business to orchestrate the work that will accomplish the long-term vision (To-BE)

EA Tooling: Adopt a Layered Vision
TOP
The Business Vision, goals

Business Process Plan and processes
Business objects, capabilities,

services, functions, etc.
Service and Functional Plan
The Application and Data

Technical Design
Application Plan
The description of the

Technical Infrastructure
Infrastructure Plan
DOWN

EA Tooling: Do Not Forget the Mappings!
• Business Vision
Event
• A process is triggered by events.
• Can be within an business activity or
transversal.
• A process is composed of operations or
successive tasks
• A process can be seen as realized by
functions.
• Functional Vision
• Tasks are realized by functions set grouped
by domain/functionality.
• Tasks creates or use information.
• Application Vision
• Function and information are materialized
through application components running on
technical architecture

EA Tooling: How are they built?
• Each EA tool comes with

• A central repository
• A metamodel that can be already hard-coded or open
• A script language to navigate inside the metamodel
• An meta-editor to create objects and relationships within diagram
• An editor for architect to describe their models and make simulation and impact analysis
• An import/export tool
• An administration tool
• Complementary modules to generate static web site or to offer a dynamic web access to
the repository.
• Frameworks that can be obtained freely or bought.

Ex. Togaf and Tooling

EA Tooling: Where Are We In 2016?

EA Tooling: Where Are We In 2016?
• EA modeling tools are mature

• Most of them are coming with ready to use metamodels that you can more or less
extend and customize.
• Two kinds of tools
• The ones needing architect to draw: Mega, Casewise, Software AG, Abacus
• The ones following a portfolio management approach (ERP for IT): LeanIX (SaaS)
• What is difficult is to:
• Load all information and ensure coherence and traceability through time and models
• Model exhaustively all views
• Ensure people model the same way
• Provide output from central repository (Office documents, web site)
• Control the operational cost of EA tool over the years (version update, maintenance,
etc.)

Ex. LeanIX
Copyright © William El Kaim 2016 Source: LeanIX 104

Ex. LeanIX

Ex. LeanIX

Plan

Could I Build my own Enterprise Architecture Framework?

Could I build my own Enterprise Architecture
Framework?
• Yes …
• Use the IEEE-Std-1471-2000
• Follow these steps
• Define your EA Information Model (metamodel)
• Define your Views
• Implement your framework in a tool

Define the EA Information Model (Metamodel)
• Example describing the
key elements of the
technical architecture
• Described in UML class
diagram (class attributes
are not described for the
sake of clarity)
• An application
• Has a component
architecture (N-Tiers)
• Is reusing shared service
(business or IT and
framework)
• Is composed of Software
Standard
• Is composed of Software
Products (Not Standard)
• Has software component
deployed on several
environments

Define your Views
• Depending on your
concerns and what you
need to describe for
specific stakeholders.
• Example describing
two different set of
views :
• Canonical views
• Aggregated views
reusing information from
canonical views

Ex: Native Artifacts Managed in Mega
• Software
• Application: Custom build or bought software component
• Service: Elementary software function that realize a task in order to offer a service to
other software component. A service could be public or private.
• Hardware
• Server. Hardware machine deployed in a datacenter within a specific environment
• Database
• Site. Used for describing any CWT datacenter.

Ex: Extended Attributes for Application
Application family
Application Lifecycle

Implement your framework in tools
View: Application Context (data flow and interfaces)
Building this View: Application is seen as a black box and only external relationships/message
exchanged with actors and applications are shown.
Mega
Mega CaseWise

Implement your framework in tools
View: Logical N-Tiers Architecture
Building this View: Describe the N-tiers client server architecture and the technical flows
between them based on “N-Tiers Architecture” city planning diagram.
<< N-Tiers Architecture >>
N-Tiers Architecture
Client Tool
Internet Explorer
Citrix Client
<< N-Tiers Architecture >> ICA Calls

Access Services
Citrix Serv er Apac he Proxy
<< N-Tiers Architecture >> Execute

Presentation Services Execute
Calls
D elphi Business Objec ts XI Client
<< N-Tiers Architecture >> Calls

Business Services
Business Objec ts XI Serv er Apache Tomc at

Makes query

Integration Services
Makes query
Apac he Axis
Makes query
Storage Services
Sybase Enterprise Serv er 12.5
Monitor
Infrastructure Services
N agios Mega CaseWise

Implement your framework in tools (UML)
• Create a UML profile
• And model

Plan

What is EA Governance?

• EA governance is the practice and orientation by which enterprise
architectures and other architectures are managed and controlled at an
enterprise-wide level.
• EA governance typically does not operate in isolation, but within a hierarchy
of governance structures, which, particularly in the larger enterprise, can
include all of the following as distinct domains with their own disciplines and
processes:
• Corporate governance, Technology governance, IT governance, Architecture
governance, Security Governance, etc.
• Each of these domains of governance may exist at multiple geographic
levels
• global, regional, and local - within the overall enterprise.
• EA governance is thus a broad topic, beyond the scope of an enterprise
architecture framework!
• The main objectives of EA is finally to build a culture of knowledge sharing

and reuse through a common language.
• This should be done in an evolutionary, not a revolutionary, way, with a
governance team acting in an operational environment with different scopes:
• the global business and strategy scope,
• the information systems scope,
• and the projects scope.
• Support should be provided using the right tooling at each level throughout
the organization.
• Organizations looking to achieve sustained compliance; to manage and
document compliance, will benefit from adopting frameworks around which
to build compliance.

EA Governance Could not be Done in Isolation!

EA Governance Could not be Done in Isolation!
The target
Progressively Implement The Vision, (we might
While Delivering Immediate Benefits attain one day)
Project Portfolio
Migration & Development Paths
Enterprise
3-5 Year Plan
Architects
Project Driven Tactical Steps
Frameworks Are Proliferating To Help With
Governance

Frameworks Are Proliferating To Help With IT
Governance
• During the past five years, a number of frameworks, methodologies, and
practices have been developed for or adopted by IT to better govern and
manage performance.
• Control objectives for information and related technologies (COBIT), IT Infrastructure
Library (ITIL), International Organization for Standardization (ISO) 17799, CMM,
PRINCE, MSP, PMBOK, the Balanced Scorecard, and Six Sigma.
• It is very easy to get confused by the “alphabet soup” of alternatives, which
can lead
• to paralysis (you can’t make a decision)
• or choosing one and then finding out later that it misses the mark.
• Most of these frameworks are not mutually exclusive and are most effective
when used in combination with one another.

Which Governance For Which Objectives?
IT governance Objectives Methodologies or Indicators
Processes
EA governance Decrease heterogeneity. TOGAF, TAFIM Release time accuracy and

Decrease project integration cost. planning accuracy
Increase roadmap planning
SOA governance Increase business and/or IT flexibility and Repository, Release time accuracy
reusability. librarian, “reuse”
Data governance Establish and maintain enterprise data Data modeling and No manual cleansing afterwards
model. managing changes, and decreased interface time
Cleanse the data. canonical formats, development
semantics, and
Comply to regulations data security. ontologies
Security governance Increase security and reduce risks. COSO, ISO 17799 Security and recovery plan
Quality governance Increase the quality of service. COBIT CIO dashboard

Which Governance For Which Objectives?
IT governance Objectives Methodologies Indicators
or Processes
Operational IT Improve help desk response time and ITIL User satisfaction
governance operations excellence.
Project portfolio Increase IT/business alignment. Project Better project, resources

governance (PPM) Optimize limited IT ressource prioritization visibility, and planning
allocation.
Application Optimize IT ressources allocation. IT management satisfaction

portfolio/life-cycle Manage demand prioritization. and BU satisfaction
governance (APM)
Demand Let business drive priorities. Chargeback, BU satisfaction and better

management APM+PPM+ITIL planning

IT Governance Frameworks
• For the purpose of compliance in

the IT world, there are three SECURE
ISO/CEI 27000 series
main frameworks
• COBIT
• ITIL
• ISO/CEI 27000 series
• Of course you can always build
your own …
• Or specialize the existing ones
• Or take the one specialized by a
consulting company for you.

Steer: COBIT
• The primary framework for IT governance is COBIT (Control Objectives for

Information and related Technology)
• Produced by the Information Systems Audit and Control Association (ISACA) and its IT
Governance Institute.
• is now issued and maintained by the IT Governance Institute (ITGI) as a framework for
providing control mechanisms over the information technology domain.
• Now in its third edition, COBIT has been extended to serve as an IT governance
framework by providing maturity models, critical success factors, key goal indicators,
and key performance indicators for the management of IT.

Steer: COBIT
• At the heart of COBIT are 34 high-

level control objectives.
• These control objectives are grouped
into four main domains:
• Planning and organization,
• Acquisition and implementation,
• Delivery and support,
• Monitoring.
• Corresponding to each of the 34
control objectives are 318 detailed
control objectives

Steer: COBIT Maturity Model
• COBIT Maturity Model provides a basis for assessing
each of the functional areas from a basis of the
definition and repeatability of each key process.
• The key processes reviewed were assigned a
maturity ranking of 0 to 5 as follows:
• “0” Management is unaware of the need for process or
control.
• “1” Awareness exists that a process or control should be
developed.
• “2” Ad hoc (reactionary) management. A process exists and
may have been performed several times, by at least 1
individual.
• “3” A defined process exists. Initial development of
performance metrics.
• “4” Management is more proactive, utilizes performance
metrics and follows best practices.
• “5” Management is very proactive, optimally efficient, and
setting/leading best practices.

Build: CMM
• Capability Maturity Model is a development model created after study of

data collected from organizations that contracted with the U.S. Department
of Defense, who funded the research.
• CMM describes process maturity!
• Intended to help software organizations improve the maturity of their software
development processes in terms of an evolutionary path from ad hoc, chaotic processes
to mature, disciplined software development processes.
• Can be used to measure the maturity of IT processes (in conjunction with IT
management frameworks such as ITIL to measure specific processes).

Build: CMM, PMBOK, Prince 2
• Whether an IT project involving software or hardware, or the implementation

of a new project, frameworks could be used to describe a structure for
successful project implementation.
• The Project Management Body of Knowledge (PMBOK), first created by
the Project Management Institute (PMI), describes the process elements of
projects of all kinds in terms of inputs like documents, plans, tools, and
techniques and outputs such as products.
• PRojects IN Controlled Environments (PRINCE2) is a process-based
method for effective project management.
• Used extensively by the UK Government, PRINCE2 is also widely recognized and used
in the private sector, both in the UK and internationally.
• The PRINCE2 method is in the public domain, and offers non-proprietorial best practice
guidance on project management.

Run: The IT Infrastructure Library (ITIL)
• IT Infrastructure Library (ITIL) defines and leverages best practices for

management and operations of IT organizations.
• ITIL is a set of policies and concepts for managing information technology infrastructure,
development, and operations.
• ITIL describes the “what” part for an IT ops professional but does not describe the quality
or how to improve processes.
• ITIL v3, introduced in June 2007, has gone one step further and defined how IT should
be working with the business in designing and transitioning services, whereas ITIL v2
was solely focused on operating services.
• ITIL is the de facto-standard for IT operations professionals (datacenter
management)
• CMM is different from ITIL, as it focuses on the maturity of a process and describes the
current maturity stage. With the knowledge of what stage an organization is in, a road
map for adoption of ITIL processes can be plotted.

Secure: ISO/IEC 27000 Series
• The ISO/IEC 27000-series comprises information security standards

published jointly by the International Organization for Standardization (ISO)
and the International Electrotechnical Commission(IEC).
• also known as the 'ISMS Family of Standards' or 'ISO27k' for short
• Download: http://standards.iso.org/ittf/PubliclyAvailableStandards/
• The series provides best practice recommendations on information security
management, risks and controls within the context of an overall information
security management system (ISMS), similar in design to management
systems for quality assurance (the ISO 9000 series) and environmental
protection (the ISO 14000 series).
• In particular, the ISO/IEC 27002 provides best practice recommendations on information
security management for use by those responsible for initiating, implementing or
maintaining an ISMS.

Secure: Ten Key Controls of ISO/IEC 27002
Copyright © William El Kaim 2016 Source: http://www.iso27001security.com/index.html 133

Plan

Conclusion: Resilient and Agile EA

EA: Can the dream come true?

Embrace All Development Types
• Greenfield development
• Fun for developer, new projects, excitement
• Brownfield development
• Modernization, migration, maintenance
• Eat all the innovation/new product budget
• IT on diet – No more development
• Maintenance mode only - terrible effects
• Kill application
• Yes you should …

Heart of Enterprise Architecture
• Understand and document

• My Information System patrimonial
• its components, its interactions
• Its information managed and data exchanged
• Its relationships with others (ecosystem and B2B
dialects)
• Manage
• Analysis, KPI, IT Portfolio
• Govern
• Bring under control Cost, IS Performance and
evolution risks

Resilient & Agile Enterprise Architecture
• Understand and document

• My Information System patrimonial
Deliver value with/to the business
• its components, its interactions
on time and on market
• Its information managed and data exchanged (Tailored EA framework like eTom, Agile, Lean,
• Its relationships with others (ecosystem and B2B MDx, xaaS, BPx, etc.)
dialects)
• Manage
• Analysis, KPI, IT Portfolio
• Govern Agile and elastic platform and Infrastructure to

support all architecture, “ilities” and deployment
• Bring under control Cost, IS Performance and needs
(ITIL, PaaS, Virtualization, SAN, etc.)
evolution risks
Use EA as a control tower for assessing and ensuring resilience

Resilient & Agile Enterprise Architecture
Resilient & Agile EA Business
Methodology, policies and rules should be applied Strategy Model
at all layers
Make EA more dynamic (not only static description)
– requires new set of integrated tools Business
Architecture
Application
Portfolio
Holistic Application
Views Architecture
Security
data and
Information
Integration
Technical
SOA
Architecture
Technology

EA Digital Codex Twitter
http://www.eacodex.com/ http://www.twitter.com/welkaim
Linkedin SlideShare
http://fr.linkedin.com/in/williamelkaim http://www.slideshare.net/welkaim
Claudine O'Sullivan

Introducción - A - La - Arquitectura - Empresarial (By William El Kaim)

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Introducción - A - La - Arquitectura - Empresarial (By William El Kaim)

Caricato da

Copyright:

Formati disponibili

Introduction to Enterprise Architecture

Copyright © William El Kaim 2016 http://www.eacodex.com/ 2

What is Enterprise Architecture?

Copyright © William El Kaim 2016 3

• An enterprise architecture (EA) is a conceptual blueprint that defines the

Copyright © William El Kaim 2016 4

• What is Enterprise Architecture?

Copyright © William El Kaim 2016 5

• What is Enterprise Architecture (EA)?

•Global Scope Globally based solution, ensuring company

Copyright © William El Kaim 2016 6

Specific BU organization Specific BU organization

EWITA = Enterprise Wide IT Architecture

Copyright © William El Kaim 2016 7

• What is Enterprise Architecture?

Copyright © William El Kaim 2016 8

Copyright © William El Kaim 2016

• The purpose of Enterprise Architecture (and city planning" for information

Copyright © William El Kaim 2016 10

Copyright © William El Kaim 2016 11

Copyright © William El Kaim 2016 12

Copyright © William El Kaim 2016 13

Copyright © William El Kaim 2016 14

• Enterprise Architecture is justified for businesses:

Copyright © William El Kaim 2016 15

• What is Enterprise Architecture?

Copyright © William El Kaim 2016 16

Copyright © William El Kaim 2016 17

• EA planning entails the definition of a current state (called AS-IS) or as-is

Copyright © William El Kaim 2016 18

Business process Technical City Planning

Copyright © William El Kaim 2016 19

Copyright © William El Kaim 2016 Source: Forrester 20

Participate in the projects arbitration committees

Drive the implementation

applications, data, etc…)

Communicate and train on IS Urbanization

Copyright © William El Kaim 2016 Source: Club Urba-EA 21

5. Flows complexity 1 2. Master data

6 axis to understand IS urbanization maturity TO BE

(with 2 to 4 criteria per axis) AS IS

Copyright © William El Kaim 2016 Source: Club Urba-EA 22

Develop Define “Current” Develop “Target”

Press Control Systems Implementation

Before Q3 ’07 and

Copyright © William El Kaim 2016 23

Copyright © William El Kaim 2016 24

• Two major approaches to

Copyright © William El Kaim 2016 25

Copyright © William El Kaim 2016 26

Copyright © William El Kaim 2016 28

Top down Bottom up

Process re-designed Product / Service re-designed

New application developed to Core modules developed to support

Data migrated Core module progressively added

"Big bang" launch Existing landscape adapted as necessary

All existing applications retired Applications retired on a case by case basis

Top down approach is effective when : Bottom up approach is effective when :

Examples : HR Examples : SAP

Copyright © William El Kaim 2016 29

Business Architecture Organigrams, actors

Cartography & functional

Code and infrastructure