Dimensies in architectuur



Dovnload 118.04 Kb.
Datum13.06.2018
Grootte118.04 Kb.

De dimensies in architectuurbeschrijvingen


Danny Greefhorst
IBM Business Consulting Services
greefhorst@nl.ibm.com

Henk Koning
Vrije Universiteit, Amsterdam
henk@cs.vu.nl

Hans van Vliet
Vrije Universiteit, Amsterdam
hans@cs.vu.nl

In de afgelopen jaren heeft architectuur een belangrijke rol gekregen in veranderingsprocessen in IT. Ondanks het feit dat de waarde van architectuur algemeen wordt erkend blijkt het communiceren over architectuur erg lastig. Architectuur is multi-dimensionaal en omvat een veelheid van aspecten. Er is een aantal architectuurraamwerken gedefinieerd om dit probleem op te lossen. Hoewel losse raamwerken zeker bijdragen, toont het geheel van beschikbare raamwerken een woud aan termen en schijnbare tegenstrijdigheden. In dit artikel analyseren wij bestaande raamwerken en leiden daar een aantal basisdimensies uit af. Deze dimensies geven een dieper inzicht in architectuur in het algemeen en architectuurraamwerken in het bijzonder, waardoor beter over architectuur gecommuniceerd kan worden.

Inleiding


De architectuur van een systeem kan beschreven worden vanuit vele gezichtspunten, afhankelijk van de belangen die spelen in het veranderingsproces. Het bestaan van vele gezichtspunten is niet nieuw; zij worden ook onderkend in de IEEE/ANSI standaard P1471 voor architectuurbeschrijvingen. De standaard onderscheidt ‘views’ en ‘viewpoints’, waarbij een viewpoint een voorschrift is voor een view op een specifiek systeem. Elk viewpoint geeft een unieke manier aan om naar een systeem te kijken. Het viewpoint bevat tevens aanwijzingen voor hoe deze manier van kijken moet worden opgeschreven Een architectuurbeschrijving bestaat uit views die samen de belangen van de betrokken partijen afdekken. Een probleem is dat P1471 geen specifieke viewpoints voorschrijft. Dit resulteert in een discussie onder IT-architecten over de te hanteren viewpoints.

Architectuurraamwerken stellen een aantal standaard viewpoints voor. Voorbeelden van bekende architectuurraamwerken zijn het Zachman framework voor informatiesystemen [4], de RM-ODP standaard voor gedistribueerde systemen [2] en het 4+1 model voor software architectuur [3]. Alleen deze drie raamwerken al verschillen behoorlijk in de dimensies die ze voorstellen. Deze verschillen geven aan dat het doel en de context van het raamwerk tot verschillende modellen leidt. Het is lastig om er achter te komen wat deze basisgedachten van de architectuurraamwerken zijn en in welke mate ze toepasbaar zijn in andere situaties. Het is ook lastig om raamwerken onderling te vergelijken vanwege de verschillen in terminologie en soms het geheel ontbreken van uitleg hierover. Het resultaat is dat als je te maken krijgt met een architectuur die gemaakt is volgens een raamwerk waarmee je niet bekend bent, je meer moeite zult hebben hebt met het begrijpen van de inhoud. Het niet of verkeerd begrijpen van architecturen hindert bij het bereiken van de bedrijfsdoelstellingen zoals deze in de architectuur zijn geborgd. Al met al genoeg aanleiding om de dimensies in architectuurraamwerken en hun onderliggende dimensies eens aan een nader onderzoek te onderwerpen.


Architectuurraamwerken


Architectuurraamwerken komen voor in twee smaken: enterprise-raamwerken en applicatieraamwerken. Enterprise-raamwerken hebben de hele organisatie op het oog, bevatten vaak meerdere dimensies en leiden tot veel modellen/afzonderlijke documenten. Voorbeelden zijn: het Zachman framework [4, 5], het Information Framework (IFW) [6], The Open Group Architecture Framework (TOGAF) [7], Integrated Architecture Framework (IAF) [8] en de Methodology for Architecture Description (MAD) [9]. Applicatieraamwerken zijn gericht op één applicatie of een familie van vergelijkbare applicaties. Ze bevatten vaak slechts een beperkt aantal modellen en leiden veelal tot maar één document. De informatie in applicatieraamwerken is van een lager detailniveau dan de informatie in enterprise-raamwerken. Voorbeelden van applicatieraamwerken zijn: het 4+1 model [3], het Siemens raamwerk [9, 10] en het 2+2 model van de Vrije Universiteit [12].

Zachman framework


De basis voor enterprise raamwerken is gelegd door John Zachman in 1987 [4]. Zijn gedachte was dat de architectuur van informatiesystemen lering kon trekken uit architecturen in meer gevestigde ontwerpdisciplines. Vanuit deze gedachte construeerde hij een generiek raamwerk van twee dimensies. De eerste (verticale) dimensie van het raamwerk bestaat uit de perspectieven van specifieke betrokkenen in het architectuurproces: de planner, de eigenaar, de ontwerper, de bouwer en de onderaannemer. Later gaf Zachman meer logische namen aan deze perspectieven: contextueel, conceptueel, logisch, fysiek en uit-context. Met ‘uit-context’ wordt aangegeven dat voor onderaannemers het omliggende systeem niet meer relevant is. De tweede (horizontale) dimensie van Zachman is gebaseerd op algemeen herkenbare vragen als: “wat”, “hoe”, “waar”, “wie”, “wanneer” en “waarom”. Voor informatiesystemen vertaalde Zachman dit naar de kolommen data, functie, locatie, personen, tijd en motivatie. Door deze twee dimensies ontstaat een matrix van dertig vakken waarin architectuurbeschrijvingen kunnen worden gepositioneerd.

4+1


Het 4+1 model [3] is bedoeld als applicatieraamwerk voor software (zie Figuur 1) en is ontwikkeld door Philippe Kruchten.

Figuur 1 het 4+1 model



Dit raamwerk heeft maar één dimensie, die geen naam heeft gekregen. De vier viewpoints, logical, process, development en physical, zijn van belang voor gebruikers, ontwikkelaars, implementeerders en (netwerk) beheerders. Een vijfde viewpoint, scenario’s, laat zien hoe de elementen uit de andere viewpoints samenwerken.

Overzicht


We geven nu een overzicht van een aantal belangrijke architectuurraamwerken. Bij elk raamwerk vermelden we waar het is beschreven, welke dimensies er in het raamwerk worden onderkend en welke waarden in deze dimensies worden onderscheiden. Eventuele verdere onderverdelingen van waarden in het raamwerk staan tussen haakjes aangegeven. Een lege cel geeft aan dat de waarde niet in de bron wordt vermeld.


Framework

Source

Dimension

Values

2+2 model

[12]




Context, Technical Infrastructure, Conceptual, Development

4+1 model

[3]




Logical, Process, Development, Physical, Scenarios

ARIS

[18]




Organizational, Data, Control, Function, Product/Service

Boar

[15]




Infrastructure, Data, Applications, Organization




Inventory, Principles, Models, Standards

DYA

[14]




Business (Product, Proces, Organisatie),
Informatie (Gegevens, Applicatie),
Technisch (Middleware, Platform, Netwerk)




Algemene Principes, Beleidslijnen, Modellen

IAF1

[8]

Main architecture areas

Business, Information, Information Systems, Technology Infrastructure

Design phases

Contextual, Conceptual, Logical, Physical, Transformational

Special viewpoints

Business and ICT System, Security, Governance

Zachman

[4, 5]

Types of description

Data, Function, Network, People, Time, Motivation

Perspectives

Contextual, Conceptual, Logical, Physical, Implementation, Out-of-Context

IFW

[6]

Types of information

Organization (Strategy, Structure, Skills),
Business (Data, Function, Workflow, Solution),
Technical (Interface, Network, Platform)

Levels of constraint

Deconstruction (Domain Concept, Domain Classification),
Composition (Generic Template, Design Context),
Implementation (Operational Bound)

Content

Organisation Model, Financial Services Data Model, Financial Services Function Model, Financial Services Workflow Model, DesignWare, Finance Industry Solutions, Technical Model, Financial Application Architecture

Transformation




Ownership

Global, Industry, Enterprise, Local, Individual

Route maps




MAD

[9]




Inter-organizational, Organizational, Process, Information, Application, Distribution, Configuration

March

[24]

Architecturen

Product, Proces, Organisatie, Informatievoorziening, Infrastructuur

Scope

Context, Concept, Logisch

Tijd

Nu, minder dan 2 jaar, 2 tor 5 jaar

RM-ODP

[2]




Enterprise, Informational, Computational, Engineering, Technology

Siemens

[10, 11]




Conceptual, Module, Execution, Code

Tapscott

[19]




Business, Work, Information, Application, Technology

TOGAF

[7]

Categories

Business, Data, Applications, Technology

Composite Views

System Engineering, Enterprise Security, Enterprise Manageability, Enterprise Quality of Service, Enterprise Mobility

GEM

[21]

Operational processes

External Infrastructure (Suppliers, Partners, Customers)
Business Architecture (Business Organisation, Business Processes, Business Information),
Application Architecture (Presentation, Business Logic, Data Access),
Technical Architecture (Middleware, Operating System, Hardware)

Migration Infrastructure

Operations & Support,
Specification, Test, Training & Deployment
Development & Maintenance
Architecture & Engineering

Gartner

[22]

Scope

Multi enterprise Grid, Enterprise, Business Process, Brick

ADS

[23]

Aspects

Functional, Operational

Level

Specified, Physical

Tabel 1 Overzicht bestaande architectuurraamwerken

Algemene observaties


Als je de architectuurraamwerken en bijbehorende dimensies bestudeert, vallen een aantal dingen op:

  • Er worden verschillende termen voor vergelijkbare aspecten gebruikt, en vice versa.

  • Veel termen zijn niet duidelijk gedefinieerd, waardoor de exacte betekenis niet duidelijk is.

  • Sommige raamwerken lijken sterk op elkaar, maar zijn het toch net weer ‘even anders’.

  • De relatie tussen de waarden binnen een dimensie is soms moeilijk te ontdekken, waardoor de dimensie moeilijk te begrijpen valt.

Het ligt voor de hand te proberen deze observaties te verklaren uit een nadere analyse. Deze analyse leidt dan tot het begrip “basisdimensie”, wat we verderop zullen uitleggen. Een verklaring voor de verschillen in de raamwerken is dat de auteurs hebben gepoogd om, gegeven een bepaalde context en een bepaald doel, alle relevante aspecten te combineren. Zo is bijvoorbeeld de “perspectieven” dimensie van Zachman een combinatie van informatie over belanghebbenden, mate van detail en een planningstermijn. Verder zien we dat raamwerken vaak uit twee dimensies bestaan. De eerste dimensie beschrijft vaak de typen informatie (onderwerpen) die kunnen voorkomen in een architectuurbeschrijving. Een grove onderverdeling in typen informatie is het onderscheid tussen IT en business. Deze grens is in enterprise-raamwerken duidelijker waarneembaar dan in applicatieraamwerken, wat niet zo vreemd is aangezien applicatieraamwerken vooral gericht zijn op het beschrijven van één applicatie. De waarden in de primaire dimensie representeren entiteiten die relatief onafhankelijk van elkaar beschreven kunnen worden. De tweede dimensie in raamwerken is vaak sequentieel van aard; er is een bepaalde volgorde waarin de modelen binnen deze dimensie opgesteld worden. Een voorbeeld is de IAF dimensie “design phases”. De auteur van het raamwerk heeft bepaald hoe bepaalde modellen van elkaar afhangen.

Het begrip “dimensie”


Op basis van voorgaande observaties proberen we nu door te dringen tot de essentie van architectuurraamwerken middels het begrip “dimensie”. Wij definiëren een dimensie als een criterium op basis waarvan een architectuurbeschrijving kan worden opgedeeld in gezichtspunten. Een gezichtspunt is een waarde binnen een dimensie. Dus een dimensie is een manier om tot gezichtspunten te komen. Deze gezichtspunten leiden typisch tot hoofdstukken of paragrafen in een architectuurbeschrijving, maar het kunnen ook afzonderlijke documenten zijn. Een criterium dat slechts een gedeelte van de architectuurbeschrijving opdeelt is in deze definitie géén dimensie. Een architectuurbeschrijving moet een duidelijke beschrijving geven van de dimensies waarin hij is opgedeeld. Standaardisering van dimensies is belangrijk om te komen tot gemeenschappelijke terminologie. Merk op dat wij dimensies positioneren als middel om over architectuur te communiceren; het is niet de bedoeling om alle mogelijke dimensies en gezichtspunten beschreven te hebben.

Basisdimensies.


Met onze definitie in de hand hebben we geprobeerd de dimensies in de bestaande architectuurraamwerken te herleiden tot een aantal basisdimensies. We hebben ons hierbij laten inspireren door onze ervaring in IT tot nu toe en door aanvullende literatuur. De resulterende negen basisdimensies zijn opgenomen in Tabel 2. Bij elke dimensie staat een korte omschrijving en enkele mogelijke waarden. De waarden dienen slechts als illustratie en zijn geen voorstel voor een standaard.

Veel dimensies in bestaande raamwerken komen niet in onze lijst terug omdat ze niet voldoen aan de definitie, ze geen duidelijk criterium hebben voor de waarden, of ze een combinatie zijn van meerdere basisdimensies. Wij willen daarmee niet zeggen dat deze dimensies niet waardevol zijn in de praktijk.




Dimension

Description

Type informatie

Het onderwerp van het gezichtspunt

(business, organisatie, techniek)

Scope

Het gebied waarop de architectuur informatie betrekking heeft

(bedrijfstak, organisatie, business unit, systeem familie, systeem, component)

Detailniveau

De gedetailleerdheid van het gezichtspunt

(hoog, midden, laag)

Belanghebbenden

De beoogde doelgroep van het gezichtspunt

(klant, eindgebruiker, architect, analist, ontwikkelaar)

Transformatie

De overgangsfasen waarover de architectuur iets moet zeggen

(huidige situatie, korte termijn, middellange termijn, lange termijn)

Kwaliteits-eigenschappen

De kwaliteitseigenschap die wordt behandeld

(functionaliteit, betrouwbaarheid, bruikbaarheid, efficiency, onderhoudbaarheid, portabiliteit)

Metaniveau

De mate van generalisatie

(instantie, model, meta-model, meta-meta-model, meta-meta-meta-model)

Aard

De aard van de informatie in het gezichtspunt

(beleid, principe, richtlijn, beschrijving, standaard)

Representatie

De manier waarop de architectuur informatie is weergegeven in het gezichtspunt

(formeel, semi-formeel, informeel)

Tabel 2 Voorgestelde basisdimensies

Beschrijving basisdimensies


Wij willen de voorgestelde basisdimensies graag verder toelichten.

Typen informatie – Deze dimensie is heel sterk terug te vinden in de bestaande raamwerken. Het gaat over de onderwerpen van het betreffende architectuurmodel, zoals business, organisatie of techniek. Binnen techniek kun je een specifieker onderscheid maken tussen bijvoorbeeld interfaces, netwerken en platformen. Je kunt 'typen informatie' ook zien als concepten uit domein-specifieke beschrijvingstalen. Veel twee-dimensionale raamwerken bestaan uit een combinatie van een 'typen informatie' dimensie met een 'detailniveau' dimensie.

Scope – Het gebied waarop de architectuurinformatie betrekking heeft. Dit is ons voorstel voor een ‘zuivere’ top-down dimensie. Mogelijke waarden zijn bedrijfstak, organisatie, business unit, systeem familie, systeem, systeem component. Scope is in het Gartner framework [22] de hoofddimensie (wel met andere waarden).

Detail niveau – Deze dimensie geeft de variatie aan in de mate van detail in de onderdelen van een architectuurbeschrijving. De informatie van een bovenliggend niveau blijft gelden; er worden alleen details aan toegevoegd. Het belangrijkste doel van deze dimensie is om gegevens te kunnen weglaten die niet relevant zijn of onbekend zijn in een bepaalde context of op een bepaald moment in de tijd. Om de informatie hanteerbaar te houden worden details in afgebakende stappen toegevoegd. Het hoogste niveau (minste details) geeft het overzicht. Als je je bij het toevoegen van details laat leiden door wat nodig is voor bepaalde belanghebbenden, kom je in de Zachman perspectieven dimensie terecht.

Belanghebbenden – Deze dimensie deelt de architectuurbeschrijving in naar belanghebbenden. Belanghebbenden zijn vaak alleen geïnteresseerd in bepaalde delen van de informatie. Wij zien dit terug bij Zachman, 4+1, IAF en RM-ODP.

Transformatie – De transformatie dimensie heeft veranderingen in de tijd als indelingscriterium. Dit kan lopen van huidige situatie in stappen naar lange termijn. De overgang van een stap naar de volgende kan ook het onderwerp zijn van architctuurinformatie. De stappen kunnen ook aangegeven worden door eigenschappen van de nieuwe fase, zoals in het Capability Maturity Model (CMM) de fasen ‘initial’, ‘repeatable’, ‘defined’, ‘managed’ and ‘optimised’.

Kwaliteitseigenschappen – Enkele dimensies in bestaande raamwerken noemen kwaliteitseigenschappen als waarden. Wij zien dit als een aparte dimensie met een gezichtspunt per eigenschap. Waarden kunnen ontleend zijn aan kwaliteitsraamwerken, zoals het Extended ISO model [20]. Deze dimensie ondersteunt het redeneren over zaken als performance en beveiliging.

Metaniveau – Deze dimensie maakt het mogelijk om op hogere niveaus over architectuurinformatie te redeneren. Deze niveaus beschrijven niet zozeer domein-specifieke informatie, maar algemene classificaties, regels en relaties die gelden voor dergelijke informatie.

Aard – Deze dimensie geeft de mate aan waarin architectuurinformatie zich doet gelden. We onderscheiden ‘beleid’, ‘principe’, ‘richtlijn’, ‘model’ en ‘standaard’. Een beleidslijn is uiteraard meer van belang dan een richtlijn. We vinden deze dimensie terug bij Boar [15] en DYA [14].

Representatie – Deze dimensie biedt de mogelijkheid om architectuur informatie in te delen naar de manier waarop de informatie gerepresenteerd wordt. Een informele representatie is natuurlijke taal (die ruimte laat voor verschillende interpretaties). Semi-formeel is bijvoorbeeld UML. Formele beschrijvingstalen, zoals Rapide [17] zijn het andere uiterste. Met formele talen kan code gegenereerd worden en kan automatisch geredeneerd worden over eigenschappen van de architectuur.

Gebruik van de basisdimensies


De lijst van dimensies kan op verschillende manieren worden gebruikt: als communicatiemiddel, als checklist voor een architectuurbeschrijving, of als basis voor een architectuurraamwerk. Ons primaire doel met deze lijst is om betere communicatie over architectuur mogelijk te maken. Het is verstandig om in een architectuurbeschrijving documentatie op te nemen over de waarden in de verschillende dimensies die door de beschrijving worden afgedekt. In gesprekken over een architectuurbeschrijving kunnen deze dimensies gebruikt worden om hem te positioneren. Als checklist kan de lijst gebruikt worden om te zien of er mogelijk relevante architectuurinformatie nog beschreven moet worden. In het denkwerk over een nieuw architectuurraamwerk voor een bepaald domein kunnen de voorgestelde dimensies een bijdrage leveren. Voor een nieuw raamwerk kunnen de meest van toepassing zijnde dimensies geselecteerd worden, kunnen de mogelijke waarden binnen de dimensies bepaald worden en kan dit geheel vertaald worden naar documentstructuren.

Tot slot


Wij hopen dat wij door dit overzicht van architectuurraamwerken, door onze observaties en voorgestelde ‘zuivere’ dimensies een beter inzicht hebben gegeven in architectuur en een nuttig hulpmiddel hebben aangereikt om over architectuur te communiceren. Het lijkt ons interessant om verder studie te doen naar de rol die bepaalde dimensies en waarden daarin spelen in bepaalde situaties. Het vakgebied zou zeker geholpen zijn met een verdere standaardisatie op dit gebied, maar dit zal alleen lukken voor standaards die veel praktische waarde hebben en breed worden herkend. Wij zijn iedereen erkentelijk die heeft bijgedragen aan onze inzichten. In het bijzonder danken we Philippe Spaas, Harry Hendrickx, Jan Campschroer, Erik Vermeulen, en Michiel Perdeck.

Referenties


[1] IEEE Std 1471-2000: “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”, 2000.

[2] ISO/IEC CD 10746-1, “Basic Reference Model of Open Distributed Processing”, 1994.

[3] P. Kruchten: “The 4+1 View Model of Architecture”, IEEE Software, 1995.

[4] J. A. Zachman: “A Framework for Information Systems Architecture”, IBM Systems Journal 26, No. 3, 1987.

[5] J.F. Sowa and J.A. Zachman: “Extending and formalizing the framework for information systems architecture”, IBM Systems Journal 31, No. 3, 1992.

[6] R. Evernden: “The Information FrameWork”, IBM Systems Journal, 1996.

[7] The Open Group: “The Open Group Architectural Framework”, Version 8

[8] H. Goedvolk, D. Rijsenbrij: “White Paper Integrated Architecture Framework”, version 1.0, 1999.

[9] J.L. Meinema: “Corporate architecture: a conceptual approach”, University of Twente, 1999.

[10] C. Hofmeister, R.L. Nord, D. Soni: “An Industrial Perspective of Software Architecture”, In Proceedings of the Eleventh International Conference on Data Engineering, IEEE Computer Society, Taipei, Taiwan, March 1995.

[11] C. Hofmeister, R. Nord, D. Soni: “Applied Software Architecture”, Addison Wesley, 2000.

[12] N. Lassing, D. Rijsenbrij, H. van Vliet: “Viewpoints on modifiability”, International Journal of Software Engineering and Knowledge Engineering, Vol. 11, No. 4, 2001, 453-478.

[13] C.Smith, L. Williams: “Performance Solutions”, Addison Wesley, 2002

[14] R. Wagter et al.: “DYA: snelheid en samenhang in business en ICT-Architecture”, Tutein Nolthenius, 2001.

[15] Bernard H. Boar: “Constructing Blueprints for Enterprise IT Architecture”, Wiley, 1998.

[16] “Rational Unified Process”, Rational Corporation, Version 2002.05.20.005, 2002.

[17] Nenad Medvidovic, Richard N. Taylor: “A Classification and Comparison Framework for Software Architecture Description Languages”, IEEE Transactions on Software Engineering 26, 1 (2000), pp 70-93

[18] A.W. Scheer : “Architecture of Integrated Information Systems”, Springer, 1992.

[19] D. Tapscott , D. Caston: “Paradigm Shift - The New Promise of Information Technology”, McGraw-Hill, 1993.

[20] B. van Zeist et.al.: “Kwaliteit van software producten, praktijkervaring met een kwaliteitsmodel”, Kluwer Bedrijfsinformatie, 1996.

[21] J.M. de Baat: “CMG's Multi-Channel Management Vision on Architecture”, October 1999.

[22] B. Rosser: “Defining Architecture for IT: A Framework of Frameworks”, Gartner, Research Note, 12 August, 2002.

[23] R. Youngs et al.: “A standard for architecture description”, IBM Systems Journal, Vol. 38, No. 1, 1999.

[24] L. Hermans: "Uitbuiten synergie ICT- en business strategie", Informatie, ten Hagen Stam, September 2002.



1 Recentelijk is er in IAF ook een “Enterprise” architectuurgebied bijgekomen, welke een holistische representatie van de organisatie in zijn geheel beschrijft.



Deel met je vrienden:


De database wordt beschermd door het auteursrecht ©tand.info 2017
stuur bericht

    Hoofdpagina