Hk yeditepe university-systemsengg-seminar-102012

Post on 12-Jun-2015

160 views 0 download

Tags:

Transcript of Hk yeditepe university-systemsengg-seminar-102012

Enterprise Architecture and Business Process Modeling – Frameworks in PracticeHakan Kıranhakan.kiran@mind2biz.com.tr@hkMind2biz

Abstract

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.

2

Contents

• 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

3

Enterprise Architecture

• 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)”

4

Enterprise Architecture 5

• 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.

The World Before EA 6

The World Before EA

– 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.

7

The Advent of EA 8

The Advent of EA

• 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.

9

The Extended Enterprise

• 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.

10

The Extended Enterprise

• 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.

11

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 ?

Summary

• 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

13

Business Process and ModelingBusiness 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.

14

Conceptual Model of the Architecture

Conceptual model of architecture description (based on IEEE Computer Society 2000)

15

Enterprise Architecture Framework

• 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.

16

Enterprise Architecture Framework 17

Background• 1987 Zachman Framework for Enterprise ArchitectureIntent• 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

infrastructureScope• Holistic descriptive model of an enterprise’s information infrastructure

from six perspectives: planner, owner, designer, builder, subcontractor, and the working system

18Conceptual Description of The Zachman Framework

19The Zachman Framework

EA Lifecycle 20

Gather Data

System & Technology Architecture

Data Architecture

Application Architecture

Technology Architecture

Implementation Plan

Transition to Implementation

The TOGAF way

• Reference model– How to do certain tasks.– Not an outcome!

• Zachman, DoDAF, TOGAF, other sector oriented. • They’re all adjustable to your needs.

21

The TOGAF way

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

22

Enterprise architecture - TOGAF 23

Steps for each phase

A. Initiation and Framework:1. Use Business Scenarios to

define relevant business requirements

2. Identify stakeholders / concerns

3. Build consensus with partners

B. Baseline Description1. Build description of current

system2. Identify “what’s wrong”3. Inventory of re-usable building

blocks

C. Target Architecture:1. Identify all needed services2. Multiple views to address

stakeholder concerns

24

Steps for each phase

D. Opportunities and Solutions:

1. Evaluate and select major work packages

E. Migration Planning:1. Prioritize work2. Develop outline plan

F. Implementation:1. Develop full plan2. Execute

G. Architecture Maintenance1. Establish procedure for

maintenance of new baseline

25

Preliminary Phase: Frameworks & Principles• 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

26

Phase A: Architecture Vision

• 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

27

Phase B: Business Architecture

• 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

28

Phase B: Business Architecture - Contents

• Organization structure• Business goals and objectives• Business functions• Business Services• Business processes• Business roles• Correlation of organization and functions.

29

Phase B: Business Architecture - Steps• Confirm context• Define baseline• Define target

– Views are important• Validate

– Requirements– Concerns

• Perform Gap analysis• Produce report

30

Phase C: Information Systems Architectures

• 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

31

Phase C: Data or Applications first ?

• 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

32

Phase D: Technology Architecture

• 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

33

Phase E: Opportunities and Solutions

• Identify the major implementation projects

• Decide on approach– Make v Buy v Re-Use– Outsource– COTS– Open Source

• Assess priorities• Identify dependencies

34

Phase F: Migration Planning

• For projects identified in Phase E perform– Cost/benefit analysis– Risk assessment

• Produce an implementation road-map

35

Phase G: Implementation Governance

• Defines architecture constraints on implementation projects

• Architecture contract• Monitors implementation work

for conformance

36

Phase H: Architecture Change Management

• 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

37

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, 20074. Minoli Daniel, “Enterprise Architecture A to Z“, Taylor & Francis Group, LLC, 20085. Lankhorst Marc, “Enterprise Architecture at Work“, Springer-Verlag Berlin

Heidelberg, 20096. Zachman, J., “A framework for information systems architecture“ IBM Syst. J. 26,

19877. Van Den Berg, Martin, Van Steenbergen Marlies, “Building an Enterprise

Architecture Practice“, Springer, 20068. Lankhorst Marc, “Enterprise architecture modelling—the issue of integration“,

Advanced Engineering Informatics 18 P205–216, 2004

38Some references

Questions

hakan.kiran@mind2biz.com.tr@hkMind2biz