Enterprise Architecture TJTSE Yrityksen kokonaisarkkitehtuuri

Transcription

1 Enterprise TJTSE Yrityksen kokonaisarkkitehtuuri Jukka (Jups) Heikkilä Professor, IS (ebusiness) Faculty of Information Technology University of Jyväskylä tel: h t t p : / / w w w. c s. j y u. f i / e l 1

2 Abstraction encompasses the set of significant decisions about the system structure. (Kruchten, 2004; c.f. Axelrod, 2006) A system is defined... as a set of different elements so connected or related as to perform a unique function not performable by the elements alone (Rechtin, 1990; c.f. Axelrod, 2006) 2

3 fwks Systematic, holistic planning to serve the needs of stakeholders Governance model Methodology/Process/Roadmap What we are trying to achieve and how is it measured (KPI) Service description Business, Application, Information and Technology architecture 3

4 Other top-down approaches in use (adapted from Boehm, 1979; 1983) Requirements elicitation Delaying error detection! Requirements analysis design Module design Coding Module testing Integration testing Acceptance testing System testing Multiplying costs of correcting! 4

5 V-Style (Boklöv, 1985) So fing alles an: Jan Boklöv bei einem Sprung 1984 (c.f., shtml) Jan Boklöv i Holmenkollen 2004 (Scanpix) 5

6 The V-model (NCOSE/INCOSE, 1991) Tempus fugit! Cannot reverse 6

7 Das V-Modell (das V-Modell, 1997; 2004) Verification & validation Contract awarded Specification & subdivision System specified System designed Detailed design completed System elements realised System integrated Delivery conducted Acceptance completed Realisation & integration 7

8 Evaluation based on what? Present ICT-enabled business Businessdriven evaluation Business objectives for the target system Implementation: Fitting IS with changed business Dialogue??? Specification of new IS Prototype of new IS New IS installed Specificatio n based evaluation (V-models) 8

9 Remember this? (Pavlaka, 2006) 9

10 e.g. IAF & governace models (MacAulay, 2004) Contextual Conceptual Why? What? How? With what? Logical Physical IAF Business Modelling RUP Requirements Analysis & Design Implementation Test Deployment Configuration & Change Management Project Management Environment Inception Elaboration Construction Transition 10

11 Business Modelling Requirements Analysis & Design Implementation Test Deployment Configuration & Change Management Project Management Environment Inception Contextual Conceptual Logical Physical Elaboration Construction Transition IAF RUP Another view (IAF + RUP or GERAM, 1999) '("&)$*$+,)$-&.-&+"/) 0"12$3"4"&)#!"#$%&'&($)*+,-$-!"#$%&%'(")*+#,%-'!"#$%&.#/(%$#+*+#,%-' '4/5"4"&),)$-& 6/"3,)$-&!"+-44$##$-& 11

12 Enterprise architecture fwk/model (McGovern et al., 2004) Construction Meta architecture Concentration is on high-level decisions that influence the structure of the system. Selection and Tradeoffs occur here. Definition of the strucuture, relationships, views, assumptionsand rationale are created for the system. Decomposition and separation of concerns occur here. Guidelines Creation of models, guides, templates and usage of design patterns for the system. At this stage, frameworks are used and standards are employed. Providing guidance to engineers so the integrity of the architecture is maintained occurs here. 12

13 What arhcitecture is/isn t (MacAulay, 2004) Table 1. Comparing and Design Delivers Does Not Deliver Non-functional requirements Prototypes Functional scope and Comprehensive functional requirements responsibilities (who does what) Detailed data analysis Key design and product choices Built and implemented systems High level design Design constraints Design Functional requirements and Solution Vision how they will be met Comprehensive and traceable non- Detailed data analysis and functional requirements data model as necessary Security and governance architectures System design documentation Built and implemented systems 13

14 !"#$!"#$%"&'()$*#+#%,*'-./*&,!"#$%&'("')*+,-'("'.'"'/0' 1#&'-*(+/&(&'*%2/*(#.(3)1+/ "#-'*4(!"#0'**'*(+/& 5'03/#-#2%'* ""# ()$*#+#%,*'()0%)**#%)0 -*$1./.&.02 &'*0"%,'(!"#0'**(#. '/5'"!"%*'('/2%/''"%/2 "#%$ ()$*#+#%,*'-./*&&%)0'3")04"0*,!"#$%&'(1#&'--%/2(0#/*5")05*(.#" 1#&'--%/2(#.(3)1+/("#-'4!"#0'**'*(+/&(5'03/#-#2%'* ""&$ ()$*#+#%,*'()0%)**#%)0 5..&, *)!!#"5('/5'"!"%*'('/2%/''"%/2 '"() "#$ ()$*#+#%,*'-./*&, '/5'"!"%*'(&'*%2/*4(+/&(1#&'-*(5# *)!!#"5(+/+-6*%*(+/&(#!'"+5%#/!"#$%&'%(!)*$ #+,*'-"!&)*)"# )+,*#+#.&#$%). "#*$ ()$*#+#%,*'-./4&*,!"#$%&' %1!-'1'/5+,-' 1#&)-'*(#.(3)1+/!"#.'**%#/*4(#!'"+5%#/+-!"#0'**'*4(5'03/#-#2%'* 6*)*#%7'()$*#+#%,*'-./*&&%)0 8.)7*+$,'951*.#%*,'")/':*;%)%$%.),< &'.%/'(53'(1'+/%/2(#. '/5'"!"%*'(1#&'--%/2 0#/*5")05* "!,,'/& "*+ ()$*#+#%,*'=+*#"$%.)"& >2,$*?, *)!!#"5(53'(#!'"+5%#/(#.(53'!+"5%0)-+"('/5'"!"%*'!"#$%&'%)+,*#+#.& '"#,$ %&'/5%.%'*(0#/0'!5*(#. '/5'"!"%*'(%/5'2"+5%#/ GERAM fwkcompo nents (IFIP-IFAC, 1999) 14

15 Construction '"() %&'/5%.%'*(0#/0'!5*(#. '/5'"!"%*'(%/5'2"+5%#/!"#$%&'("')*+,-'("'.'"'/0' 1#&'-*(+/&(&'*%2/*(#.(3)1+/ "#-'*4(!"#0'**'*(+/& 5'03/#-#2%'* ""# Meta architecture #+,*'-" ()$*#+#%,*'()0%)**#%)0 -*$1./.&.02 &'*0"%,'(!"#0'**(#. '/5'"!"%*'('/2%/''"%/2 '"#,$ 6*)*#%7'()$*#+#%,*'-./*&&%)0 8.)7*+$,'951*.#%*,'")/':*;%)%$%.),< &'.%/'(53'(1'+/%/2(#. '/5'"!"%*'(1#&'--%/2 0#/*5")05* "!,,'/&!&)*)"# "#%$ ()$*#+#%,*'-./*&&%)0'3")04"0*,!"#$%&'(1#&'--%/2(0#/*5")05*(.#" 1#&'--%/2(#.(3)1+/("#-'4!"#0'**'*(+/&(5'03/#-#2%'* Concentration is on high-level decisions that influence the structure of the system. Selection and Tradeoffs occur here. )+,*#+#.&#$%). Definition of the strucuture, relationships, views,!"#$ ""&$ assumptionsand rationale are created for the system.!"#$%"&'()$*#+#%,*'-./*&, Decomposition and separation of concerns occur here. Guidelines ()$*#+#%,*'()0%)**#%)0 5..&, *)!!#"5('/5'"!"%*'('/2%/''"%/2!"#$%&'%(!)*$ "#$ Creation of models, guides, templates and usage ()$*#+#%,*'-./*&, of design patterns for the system. At this stage, frameworks '/5'"!"%*'(&'*%2/*4(+/&(1#&'-*(5# are used and "#*$ *)!!#"5(+/+-6*%*(+/&(#!'"+5%#/ standards are employed. Providing guidance to engineers so the ()$*#+#%,*'-./4&*, integrity!"#$%&' %1!-'1'/5+,-' of the architecture is maintained occurs!"#$%&'%)+,*#+#.& here. 1#&)-'*(#.(3)1+/!"#.'**%#/*4(#!'"+5%#/+-!"#0'**'*4(5'03/#-#2%'* "*+ ()$*#+#%,*'=+*#"$%.)"& >2,$*?, *)!!#"5(53'(#!'"+5%#/(#.(53'!+"5%0)-+"('/5'"!"%*' 15

16 An ideal model? (adapted from Boehm, 1979; 1983; and Pavlaka, 2006 by Jups) Requirements elicitation To-be (thin) Acceptance testing Requirements analysis To-be (thin) System testing design To-be (fat) Integration testing As-is (fat) Module design Transition plan To-be (fat) Coding Module testing 16

17 An example fwk: TOGAF 9 17

18 TOGAF EA framework by the open Group90 generic framework for large organizations aims at open standards 18

19 Background TOGAF is developed and maintained by The Open Group Forum and its 350 members. Open Group is a vendor-neutral and technology-neutral consortium. The first version of TOGAF, developed in 1995, was based on the US Department of Defense Technical Framework for Information Management (TAFIM) 19

20 TOGAF is the de facto global standard for assisting in acceptance, production, use and maintenance of architectures. It is based on iterative process model supported by best practices and re-usable set of existing architectural assets 20

21 by TOGAF ISO/IEC 42010:20071: The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. TOGAF embraces and extends this definition. In TOGAF, architecture has two meanings depending upon the context: 1. A formal description of a system, or a detailed plan of the system at a component level to guide its implementation 2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. 21

22 BAIT = BDAT Table 1: Types Supported by TOGAF Type Business Data 2 Application Technology Description The business strategy, governance, organization, and key business processes. The structure of an organization's logical and physical data assets and data management resources. A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization. The logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards. 22

23 Development Method (ADM) describes a method for developing an enterprise architecture, and forms the core of TOGAF The TOGAF ADM defines a recommended sequence for the various phases and steps involved in developing an architecture, but it cannot recommend a scope - this has to be determined by the organization itself 23

24 Scoping Figure 5-2 Progressive Development Four dimensions are typically used in order to define and limit the scope of an architecture 24

25 ADM 25