View
214
Download
2
Category
Preview:
Citation preview
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?
Recommended