Enterprise ArchitectureTJTSE25 2009

Yrityksen kokonaisarkkitehtuuri

J u k k a ( J u p s ) H e i k k i l äP r o f e s s o r , I S ( e B u s i n e s s )

F a c u l t y o f I n f o r m a t i o n T e c h n o l o g y

U n i v e r s i t y o f J y v ä s k y l ä

e - m a i l : j u p s @ c c . j y u . f i

t e l : + 3 5 8 5 0 5 8 1 8 3 6 1

h t t p : / / w w w . c s . j y u . f i / e l

What EA?

EA is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s

operating model (Weill, 2007)

Kokonaisarkkitehtuuri on

• Suunnittelumenetelmä, jolla tuotetaan toiminnan ja tieto- ja viestintäteknisten ratkaisujen tavoitetilan kuvaukset.

• Kuvaukset tavoitetilasta, nykytilasta ja siirtymäpolusta tavoitetilaan.

• Toimintamalli, jonka avulla ohjataan suunnittelua, varmistetaan laatu, tunnistetaan ja poistetaan päällekkäinen kehittämistyö ja saadaan tehdyt suunnitelmat laajasti uudelleen käytettäviksi.

• Organisaatioiden kyvykkyys käyttää suunnittelumenetelmää ja toimia sovitun toimintamallin mukaisesti. (ValtIT, 2008)

Business

Administration

Conclusion

There are fundamental differences in the domains of architecting

Why? Time frame

Differentiation/Segmenting vs. universality

Transparency & Publicity

Governance & Incentives

Legal frameworks

EA development and descriptions(Sowa & Zachman, 2003, Pavlaka, 2006)

(VERSIONS)

CASE MANUFACTURERS FRAMEWORK

META- METAMODEL

(VERSIONS)

INFORMATION METAMODEL SYSTEMS FRAMEWORK

ENTERPRISE FRAMEWORK

PRODUCT FRAMEWORK

(VERSIONS)

MODEL

(VERSIONS)

PRODUCT

J

The conclusion Complex representation: Too many descriptive (as-is; fat) and normative blueprints (to-be; thin & fat) of BAIT-architectures

Why?

Different purposes for different groups

Meaningful abstractions

Time horizons

Optional designs

Strategy and EA (Ross, Weill & Robertson, 2008)

Business Model and Operating Model (Riihinen, 2007)

Business model- Products

- Customers- Markets

- Value system- Value proposition

What?Why?

Operating model Business processes

Organization Technology

How?Is implemented by

Business Architecture (Riihinen, 2007)

Operating assets

Business portfolio

BusinessModel

A

OperatingModel X

BusinessModelsB, C, D

OperatingModel Y

BusinessModels

E, F

OperatingModel Z

Strategy and an EA implementation (adapted from riihinen, 2007)

Information Architecture

Process Architecture

Application Architecture

Technical Architecture

Biz specific config

Std components

Risk & security policies

Strategy

Business Architecture

Interconnections

Requirements

Ensuring Business Driven Approach in public admin (FEA, 2007)

Consolidated Reference Model v. 2.2. with Federal Transition Framework (2007)

Includes training and education, eventually

Conclusion:

Interoperability requirements vary

Why?Networked business

Mergers and acquisitions

International standards and digital bonds

http://www.marinetraffic.com

Business architecture

Information architecture

Techinical architecture

Governance

Dynamic Architecture

DYAprocesses

StrategicDialogue

ArchitecturalServices

Developmentwithout

Architecture

Developmentwith

Architecture

New developments

Business solutions

Businesssolutions

Dynamic Architecture (Van Den Berg & van Steenbergen, 2007)

Some developments will not follow EA

So there co-exist to sets of applications w and w/o EA

Why?

Competitive advantage

Isolated applications

Mergers & acquisitions

Outsourcing

Defining relationships between existing and forthcoming methods

Approach Preliminary Phase

domains (also known as People, Processes, and Material/Technology) to deliver a business

capability.

The main frameworks suggested to be co-ordinated with TOGAF are:

! Business Capability Management (Business Direction and Planning) that determines

what business capabilities are required to deliver business value including the definition of

retur n on investment and the requisite control/perfor mance measures.

! Portfolio/Project Management Methods that determine how a company manages its

change initiatives.

! Operations Management Methods that describe how a company runs its day-to-day

operations, including IT.

! Solution Development Methods that for malize the way that business systems are

delivered in accordance with the structures developed in the IT architecture.

As illustrated in Figure 6-2, these frameworks are not discrete and there are significant overlaps

between them and the Business Capability Management. The latter includes the deliver y of

perfor mance measured business value.

The overall significance is that the enterpr ise architect applying TOGAF cannot narrowly focus

on the IT implementation, but must be aware of the impact that the architecture has on the entire

enter prise.

ArchitectureDevelopment

Method

SolutionDevelopment

Methods

OperationsManagement

Methods

BusinessCapability

Management

Portfolio/Project

ManagementMethods

Figure 6-2 Management Frameworks to Co-ordinate with TOGAF

72 TOGAF Version 9 (2009)

!"#$%#&'()*+(,-

.*/001*234*5,4)*67(%,8*9$$*:';3&<*:4<47"4=!"#$%#&'()*+(,->*?(&*@(7*74='<&7'A%&'()

In addition, multiple methods co-exist

When applying EA, you’ll apply multiple methods

Why?

Mergers & Acquisitions

Networked business

Technical development

Iterative processIf you think you haven’t TOGAFed

enough...

!

An Introduction to TOGAF™ 9

"""#$%&'()$*%#$)(! A W h i t e P a p e r P u b l i s h e d b y T h e O p e n G r o u p +!

What does TOGAF Contain?

TOGAF reflects the structure and content of an architecture capability within an enterprise, as shown

in Figure 1.

Figure 1: TOGAF Content Overview

!

Central to TOGAF is the Architecture Development Method (documented in TOGAF 9, Part II). The

architecture capability (documented in TOGAF 9, Part VII) operates the method. The method is

supported by a number of guidelines and techniques (documented in TOGAF 9, Part III). This

produces content to be stored in the repository (documented in TOGAF 9, Part IV), which is classified

according to the Enterprise Continuum (documented in TOGAF 9, Part V). The repository is initially

populated with the TOGAF Reference Models (documented in TOGAF 9, Part VI).

Architecture Development Method (ADM)

The ADM describes how to derive an organization-specific enterprise architecture that addresses

business requirements. The ADM is the major component of TOGAF and provides guidance for

architects on a number of levels:

• It provides a number of architecture development phases (Business Architecture, Information

Systems Architectures, Technology Architecture) in a cycle, as an overall process template for

TOGAFsummary

Conclusion

The process and methodologies are burdensome and tedious

Why? There are many things to cover

Method designers (most often) strive for universal, non-domain specific methodologies

Relevant abstractions are still developing (and evolving)

To summarize the problems of EA

(FEAR, 2008-2009)

Frameworks are hard to understand, learn, and adapt

Methodologies are too general and toilsome to implement

Architectural representations are extensive, too many, tricky to maintain (with incompatible tools)

Processes of architecting are evolving and difficult to communicate, time consuming and complex with unclear responsibilities and roles.

In some cases: lacking capabilities for designing systemic change (analysis-paralysis)

Operational Enterprise

DESIGNERS-DESCRIBERS

PlannersPolicy WritersOperations:

HR, FM, TM, IM

DECIDERS

OwnersExecutivesManagers

Staff

Enterprise DescriptionDesigns (Business & Tech)‏Plans (Project, Annual…)‏Reports, Org Charts, Job

Descriptions, Précis, Process Maps

etc

Improve Designs &

Descriptions

Continuous Coherency Improvement

ImproveFunctioning Enterprise

ResourcesPeople, Money, Information,

Technology, Property, Assets…

• Structures• Patterns•Frameworks• DesignsENTERPRISE

ARCHITECTURE

ASSESSMENTAny Investment or Whole Enterprise

DESIGNLeadership/Facilitation

Observers – Stakeholders – Partners

ADVICENew Rules

Methods, ModelsDesigns

ADVICE Gaps / OverlapsFrom Strategy to Operations

Coherent ViewCoherency mgmt

(Gotze et al., 2009)

More attention to:

- communication and co-operation

- continuous improvement

- learning and advice

- including all stakeholders

Extending EASo, what is often omitted?

Quality assurance is neglected, or forgotten

What: Ensuring functional processes’s quality

Capabilities improvement is postponed and late

What: RBV = Unique resources, capabilities development and IS

Innovation replaced with sticking to the old comprehensible

Related with options and capabilities enhancement

Participation, I mean real participation

We need to steer the process better to learn

• to incrementally build a working, acceptable and feasible architecture

• to design better methodologies for various domains

• to design and run the development for purpose

• to keep the original reason to change our operations in mind!!!

An example of a ‘meta’-governance model

Case FEAR-ohjausmalli (Heikkilä, Kella, Liimatainen & Seppänen, to appear soon)

What is special in public admin?

Keeping records forever

Cannot select customers

Equal treatment of customers (citizens, companies, organizations)

Transparency and publicity in decision making

Good governance based on obedience of law, less on strategy

‘Problem ownership’ is unclear

EA-governance for Development initiatives (FEAR,

2006-2009)

Should put EA in the context of the development initiatives

should embed cabinet objectives, legal requirements and constraints in the design for the purposes of measurement, audit and control

should improve the strategic management of projects and change

Should ensure feasibility and minimum QA requirements throughout the process

Should provide alternative designs

Should facilitate and assure capabilities enhancement

Should build EA incrementally by the results coordinating projects

INTERRELATIONSHIP WITH EA AND DEVELOPMENT INITIATIVES/

PROJECTS Development initiatives should

develop interoperable processes, and base the design componentized public services, where feasible.

Components are documented and maintained in EA

The process should make this to happen

Clinger-Cohen Act alike in Finland?

EA

Project

FEAR-ohjausmalli (Heikkilä et al., 2009)

A Use case with roles

Laadunvarmistus

A use case of KOKOA

Laadunvarmistus

FEAR-ohjausmalli (Heikkilä et al., 2009)

Kuva 4 Toteuttamiskelpoisuuden arvionti: lähtötiedot ja tulostiedot

Kuva 5 Toteuttajien arvionti: lähtötiedot ja tulostiedot

FEAR-ohjausmalli (Heikkilä et al., 2009)

Kuva 6 Kokonaisarkkitehtuurin mukaisuuden arviointi: lähtötiedot ja tulostiedot

FEAR-ohjausmalli (Heikkilä et al., 2009)

Kuva 7 Liiketoimintamallinnus: lähtötiedot ja tulostiedot

FEAR-ohjausmalli (Heikkilä et al., 2009)

Kuva 8 Toimintamallien valinta: lähtötiedot ja tulostiedot

DetailsJYVÄSKYLÄN YLIOPISTO OHJAUSMALLI !!"!#!$%!

FEAR-projekti Versio 0.98 31.3.2009

&''()!*!

+,-./01.22'3!4.',)'5)3!26,(7"!-.!(/280(')58(!0)96!.:4'83('462'3))(!

!"#$%##&'($)*&+,("()#(*

!"#$%&'(#)('#*'#!+#,-*#!)(-.##$&(*!#.$&%&*'&&*/!!"##$$%&&'(#)!*+!&,&'#&&+-%./0/0!-*.".")&(/%%0$)1&22()#&*--*3%,&%./$#*--*4$)$#$256#*--*7+"/$//(#*--*3$1(##65()$)*--*8/&&5()$)*9*"+:&)(/"()#(*--*;"10")*'&*/%</#&)//()*#%.(*3=>#?@22$**--*A1#$$)/"B(,%%/*'&*()C+&)*;DE*-5%.&(/%%/*-*"/&&5(/#&+,$&+,("**-*1$).(2@/#@)*"/&&5(/-*'&*."%2%#%/#&/"*-*5%%#"/'"1#&5()$)**1'.#2..%$3/0-3&!-*#656)1$#.()$)*.6?##@&/#$*-*?0()+$/%+//($)*.+((##(/??/*-*B$2(,&+&*-*+$/%+//()6.?56#*F"5&#G*%2."(/$#G*.%5BB&)(#G*&2(1&)..('&#H*!4$52+.&2#/&##2%$!+*+$&+.+%.##.!-*()C+&)*/",$2#%,%%/*F2&(##$$#G*#(2&#G*5&#$+(&&2(#*9*.&2%/#"H*-*B&2,$2%-G*,%".+&-G*2$&/():/"B(5%./$#*-*$0$22(/#$)*B"(/#"-*'&*1&).()#&/%%))(#$25&#*

!%2"/B+(/5&**IEJ*FK*I&2&)L$0*EL"+$L&+0H**=+..(#$1#%%+(.?,?..??0$)*.?B/??/#&/"5&22(**;DE-5%.&(/%%0$)*&+,("()#(>*;DE*MNO*;%2.(/1&22())")*,$+.."B&2,$2%)*/%%))(##$2%)*'&*#"#$%##&5(/$)*B$+(&&##$$#* *;DE*MPP*D&.$5(/#"#($0"#*'&*)((0$)*?226B(#"*;DE*MQP*=/(&.(+'"'$)*.%,&(2%)*'&*1&22())&)*5$#&#($0"#*;DE*MQR*7&2,$2%#($#"'$)*+?15(##$2?*'&*"/"(##$$#*&/("()#(&*,&+#$)*5")#&*#"(5(&2&&*.&##&,(//&*'%2.(/$)*/$.#"+()*B"+#&&2$(//&* *;DE*MQS*;%2.(/%%/2&()*5%.&(/$)*#($#"'6+'$/#$256/$2"/#$$)*2&&0()#&/%"/(#%/* * * *;DE*MQT*E&2&//&*B(0$##6,($)*#($#"'$)*'&*&/(&.(+'"'$)*#%+,&2%".(##$2%*;DE*MRN*7+"/$//($)*.%,&&5()$)*;DE*MRR*U$+.."2&/.%'$)*.6?##@*'%2.(/1&22())"//&* *;DE*MRS*=/(&.(+'"'$)*'&*#($#"'$)*+$.(/#$+@()#(*/61.@(/$)*&/("())()*'&*&/(&).6/(##$2?)*#($0")1&22())&//&* *;DE*MRT*=/(&.&/B66##$$#*'%2.(/1&22())"//&* * *;DE*MRV*7&(..&#($0")*5$#&#($0"#* *;DE*MRO*WE8*8WX-?./(2@()#(#%))%./$)*/",$2#&5()$)*'%2.(/1&22())"//&*;DE*MSY*7&(..&#($0")*2&&0%)1&22()#&*;DE*MSM*E61.@B"/#("/"(##$$#*'%2.(/1&22())"//&*;DE*MSN*7&(..&#($#"'$)*5&22()#&5()$)*#($0")/((+#"&*,&+#$)*;DE*MSQ*!%))(/#&%#%5()$)*'&*5&./&5()$)*/61.@(/$//6*&/("())(//&*UZ![4=-B&2,$2%)*&,%22&*;DE*MSV*U(0$")$%,"##$2%)*.6?##@*'%2.(/$//&*1&22())"//&*;DE*MSO*=,"(5$)*2610$.""0()*"1'$25($)*.6?##@*'%2.(/$//&*1&22())"//&* *;DE*MTY*;%2.(/1&22())")*\4]-/.$$5&#*

!01234,)44)#.$&%!+567!%)##5&)28!.()-.))&2!9#!&*:.#)'.-3'--.&2'#.$(6#)3(65#/!!

Input

Meth

ods,

standard

s to c

omply

Output

In real-life: multiple parallel projects, which proceed out-of-sync

Making sure of

strategic alignment

real implementation and real changes in the organization

concerted development and co-operation with partners, sub-contractors

development of human resources and information systems simultaneously

After competitive bidding?

Consequence:

Emphasizes the importance of

prioritizing

quality deployment

emphasizes the importance of change management

Potential methodsFor prioritizing

Roadmapping?

Ensuring links to strategy?

For quality deployment

CMMI, ITIL developing ServQual?

Customer centric process should measure more direct effects?

For change management

Methods for ensuring and managing interoperability

CE2 (ECR, ECN -processes)

Participation, Learning cycles?