The document discusses enterprise architecture (EA) and business process modeling frameworks. It provides definitions of EA and business process modeling. EA is described as a master plan that integrates business strategy, operations, systems, and technology. Frameworks help capture the entire organization and address complexity. Common frameworks discussed include the Zachman Framework and The Open Group Architecture Framework (TOGAF).

1. Enterprise Architecture and Business
Process Modeling – Frameworks in
Practice
Hakan Kıran
hakan.kiran@mind2biz.com.tr
@hkMind2biz

2. Abstract 2
Many organizations have been in trouble with the complexity and the rate of
change of business and technology. There is a need for some systematic way to
handle the situation not by chance but by complete control over the issue.
Enterprise architecture (EA) is a complete expression of the enterprise; a master
plan which “acts as a collaborative force” between aspects of business planning
such as goals, visions, strategies and governance principles; aspects of business
operations such as business terms, organization structures, processes and data;
aspects of automation such as information systems and databases; and the
enabling technological infrastructure of the business such as computers, operating
systems and networks. In a large modern enterprise, a rigorously defined
framework is necessary to be able to capture a vision of the “entire organization”
in all its dimensions and complexity [Jaap Schekkerman]. In this seminar, we
present the practices behind EA, frameworks, business process modeling and
techniques and the context in which the EA project was carried out and
implications for research and practice.

3. Contents 3
• Enterprise Architecture – Definition
• The World Before EA
• The Advent of EA
• The Extended Enterprise
• Summary
• Business Process and Modeling
• Conceptual Model of the Architecture
• Enterprise Architecture Framework
• The Zachman Framework
• EA Lifecycle – TOGAF example

4. Enterprise Architecture 4
• Enterprise Architecture :
The analysis and documentation of an enterprise in its current
and future states from an integrated view of strategic direction,
business practices and technology resources.
• Enterprise Architecture is a strategic information asset base
which defines the mission
– the information necessary to perform the mission
– the technologies necessary to perform the mission and
– the transitional processes for implementing new technologies
in response to changing needs through a “baseline architecture”
(as-is), a “target architecture (to-be)” and a “sequencing plan
(migration plan)”

5. Enterprise Architecture 5

6. The World Before EA 6
• Enterprise architecture is very much a holistic approach to
the design of organizations.
– The 1980s and 1990s of the last century have seen a focus on
changing the way businesses operate. Business process redesign
and business process re-engineering were used to rationalize
processes and products.
– In the past, the industrial revolution automated many
production activities in companies. Work shifted from ‘blue-
collar work’ to ‘white-collar work’. Improving the performance
of white-collar work cannot be achieved by simply automating
it, but by working smarter, enabled by information technology.

7. The World Before EA 7
– As Hammer (1990) stated in the title of his provocative article
on business process reengineering: ‘Don’t automate, obliterate’,
i.e., radically rethink illogical business activities, which are there
because nobody dares to challenge them.
– Another reason for changing business processes was customer
focus. Companies need to compete and excel to keep and
expand their customer base.
– Given the complexity and risks involved in changing an
organizational way of working, a business process engineering
approach is needed.
– Architecture is progressively seen not just as a tactical
instrument for designing an organization's systems and
processes, but as a strategic tool for enterprise governance.

8. The Advent of EA 8

9. The Advent of EA 9
• To really profit from the strategic potential of enterprise
architecture, an organization needs to optimize the skills,
methods, and tools of its architects, and give them the right
position in the organization.
– In many companies, this has resulted in organizational units
such as ‘corporate architecture’ or ‘enterprise architecture’
– The acceptance of the role of the enterprise architect depends
directly on its perceived added value.
– A key element in the recognition of the role of enterprise
architecture is that we should be able to quantify the impact of
architecture, both financially as well as in terms of the
organizational performance.

10. The Extended Enterprise 10
• However, new challenges for enterprise architects are just
beyond the horizon. Customers have become increasingly
demanding and product innovation rates are high.
– Globalization of markets and the availability of new electronic
media lead to new players entering existing markets,
disintermediation, and an ever higher competitive pressure to
work more effectively, reduce costs, and become more flexible.
– The advent of e-business and e-government has definitely
changed the way organizations and cross-organizational
processes function.

11. The Extended Enterprise 11
• The scope of an enterprise architect increasingly includes the
extended enterprise, or business network, in which the enterprise
operates (Kalakote and Robinson 2001, Hoque 2000).
• Business network architecture has become a new playing field,
determining the borders of business models and business network
design.
• Modelling techniques for this type of architecture may change,
but more in the sense that different views will be used rather
than entirely new concepts.
• In this complicated, networked world, the role of the enterprise
architect as a ‘great communicator’ needs to grow and even enter
the realm of the ‘great negotiator’, as architectural decisions move
beyond the reach of a single organizational unit or managerial
entity.

12. The Extended Enterprise 12
A strong enterprise architecture
process helps to answer basic
questions like :
Is the current architecture
supporting and adding value to the
organization ?
How might an architecture be
modified so that it adds more value
to the organization ?
Based on what we know about
what the organization wants to
accomplish in the future, will the
current architecture support or
hinder that ?

13. Summary 13
• History
– Lack of Alignment
– IT centric
– Siloed initiatives
– Lack Cross-functional process owners
– Enterprise Optimization focus is in the wrong place
– We get lost in the details
• Nowadays and Future
– Enterprise Architecture is about Business Transformation
– Process Modeling is a component of Enterprise Architecture
– Cross-functional optimization is the focus
– Cross-functional process ownership is obvious and rewarded

14. Business Process and Modeling 14
Business Process :
A collection of related,
structured activities--a chain
of events--that produce a
specific service or product for
a particular customer or
customers.
Business Process Modeling :
Documentation of a business
process using a combination
of text and graphical notation.
Defines a process as a specific
ordering of work activities
across time and place with a
beginning, an end, and clearly
defined inputs and outputs.

15. Conceptual Model of the Architecture 15
Conceptual model of architecture description (based on IEEE Computer Society 2000)

16. Enterprise Architecture Framework 16
• Key elements of any Enterprise Architecture Framework :
– Definition of deliverables that should be produced
– Description of method by which deliverables are produced
• Enterprise Architecture Framework :
– Identifies the types of information needed to portray an
Enterprise Architecture
– Organizes the types of information into a logical structure
– Describes the relationships among the information types
– Often the information is categorized into architecture models
and viewpoints.

17. Enterprise Architecture Framework 17

18. Conceptual Description of The Zachman Framework 18
Background
• 1987 Zachman Framework for Enterprise Architecture
Intent
• Influenced by principles of classical architecture
• Establishes a common vocabulary and set of perspectives for describing
complex enterprise systems
• Provides blueprint, or architecture, for an organization’s information
infrastructure
Scope
• Holistic descriptive model of an enterprise’s information infrastructure
from six perspectives: planner, owner, designer, builder, subcontractor,
and the working system

19. The Zachman Framework 19

20. EA Lifecycle 20
Gather Data
System &
Transition to
Technology
Implementation
Architecture
Implementation
Data Architecture
Plan
Technology Application
Architecture Architecture

21. The TOGAF way 21
• Reference model
– How to do certain tasks.
– Not an outcome!
• Zachman, DoDAF, TOGAF, other sector oriented.
• They’re all adjustable to your needs.

22. The TOGAF way 22
• Never ending organization process which builds
upon several stages:
– Initiation
– Business architecture.
– Information architecture
– Applications architecture
– Infrastructure architecture
– Governance
– Gap analysis
– And again …

23. Enterprise architecture - TOGAF 23

24. Steps for each phase 24
A. Initiation and Framework:
1. Use Business Scenarios to
define relevant business
requirements
2. Identify stakeholders /
concerns
3. Build consensus with partners
B. Baseline Description
1. Build description of current
system
2. Identify “what’s wrong”
3. Inventory of re-usable building
blocks
C. Target Architecture:
1. Identify all needed services
2. Multiple views to address
stakeholder concerns

25. Steps for each phase 25
D. Opportunities and
Solutions:
1. Evaluate and select major work
packages
E. Migration Planning:
1. Prioritize work
2. Develop outline plan
F. Implementation:
1. Develop full plan
2. Execute
G. Architecture Maintenance
1. Establish procedure for
maintenance of new baseline

26. Preliminary Phase: Frameworks & Principles 26
• This phase prepares the
organization for undertaking
Enterprise Architecture
successfully
– Understand business
environment
– Commitment of key stakeholders
– Agreement on scope
– Establish principles
– Establish governance structure
– Agree method to be adopted

27. Phase A: Architecture Vision 27
• Initiates one iteration of the architecture process
– Sets scope, constraints, expectations
– Required at the start of every architecture cycle
• Validates business context
• Creates Statement of Architecture work

28. Phase B: Business Architecture 28
• The fundamental organization of
a business, embodied in
– its business processes and
people,
– their relationships to each other
and the environment,
– and the principles governing its
design and evolution
• Shows how the organization
meets it’s business goals

29. Phase B: Business Architecture - Contents 29
• Organization structure
• Business goals and objectives
• Business functions
• Business Services
• Business processes
• Business roles
• Correlation of organization and functions.

30. Phase B: Business Architecture - Steps 30
• Confirm context
• Define baseline
• Define target
– Views are important
• Validate
– Requirements
– Concerns
• Perform Gap analysis
• Produce report

31. Phase C: Information Systems Architectures 31
• The fundamental organization of
an IT system, embodied in
– relationships to each other and
the environment, and the
principles governing its design
and evolution
• Shows how the IT systems meets
the business goals of the
enterprise
Continued

32. Phase C: Data or Applications first ? 32
• It is usually necessary to address both
– Not always the case, depending on project scope and
constraints
• May be developed in either order, or in parallel
– Theory suggests Data Architecture comes first
– Practical considerations may mean that starting with Application
Systems may be more efficient
• There will need to be some iteration to ensure consistency

33. Phase D: Technology Architecture 33
• The fundamental organization of
an IT system, embodied in
– its hardware, software and
communications technology
– their relationships to each other
and the environment,
– and the principles governing its
design and evolution

34. Phase E: Opportunities and Solutions 34
• Identify the major
implementation projects
• Decide on approach
– Make v Buy v Re-Use
– Outsource
– COTS
– Open Source
• Assess priorities
• Identify dependencies

35. Phase F: Migration Planning 35
• For projects identified in Phase E
perform
– Cost/benefit analysis
– Risk assessment
• Produce an implementation
road-map

36. Phase G: Implementation Governance 36
• Defines architecture constraints
on implementation projects
• Architecture contract
• Monitors implementation work
for conformance

37. Phase H: Architecture Change Management 37
• Ensures that changes to the
architecture are managed in a
cohesive and architected way
• Establishes and supports the
Enterprise Architecture to
provide flexibility to evolve
rapidly in response to changes in
the technology or business
environment

38. Some references 38
1. Schekkerman Jaap, “How to survive in the jungle of Enterprise Architecture
Frameworks”, Trafford, 2004.
2. Bernard Scott A., “An Introduction to Enterprise Architecture”, Author
House, 2004.
3. Weske Mathias, “Business Process Management”, Springer, 2007
4. Minoli Daniel, “Enterprise Architecture A to Z“, Taylor & Francis Group, LLC, 2008
5. Lankhorst Marc, “Enterprise Architecture at Work“, Springer-Verlag Berlin
Heidelberg, 2009
6. Zachman, J., “A framework for information systems architecture“ IBM Syst. J.
26, 1987
7. Van Den Berg, Martin, Van Steenbergen Marlies, “Building an Enterprise
Architecture Practice“, Springer, 2006
8. Lankhorst Marc, “Enterprise architecture modelling—the issue of
integration“, Advanced Engineering Informatics 18 P205–216, 2004

39. Questions
hakan.kiran@mind2biz.com.tr
@hkMind2biz