Bij veel organisaties bestaat het beeld dat de Project Start Architectuur (PSA) bedoeld is om de Solution Architecture van het project weer te geven en daarmee de scope te bepalen. Als gevolg daarvan is het een dik document en duurt het enkele maanden om het op te stellen. Dit artikel laat zien dat deze invulling van de PSA fundamenteel onwenselijk is. De PSA bevat geen Solution Architecture!
Inleiding
Organisaties streven verschillende doelen na. Zo willen zij hun marktaandeel verhogen, hun kosten verlagen, hun time-to-market verkleinen, hun service aan de klanten verhogen en, in toenemende mate, hun samenwerking met ketenpartners intensiveren. Deze doelen worden niet vanzelf bereikt. Daar moet bewust naartoe gewerkt worden. De beste kans van slagen daarin heeft een organisatie die zijn bedrijfsvoering in samenhang en geïntegreerd heeft ingericht. Veel organisaties ervaren in hun streven dat de wirwar die is ontstaan in hun ICT-landschap de flexibiliteit en het verandervermogen te veel beperken. Dit, juist in een tijd waarin de behoefte aan flexibiliteit en verandervermogen groot is. Complexiteitsbeheersing en standaardisering zijn aandachtspunten die daarom in de toekomstige veranderingen meegenomen moeten worden.
Architectuur is een middel dat kan helpen om de sturing van een organisatie te ondersteunen. Architectuur is hierbij gedefinieerd als:
“Architectuur is een consistent geheel van principes en modellen dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatie-voorziening en technische infrastructuur van een organisatie.”
De sturing vanuit architectuur is er op gericht om de bedrijfsvoering van de organisatie in samenhang en geïntegreerd in te richten op een dusdanige wijze dat de complexiteit beheerst wordt en standaardisatie wordt doorgevoerd.
Architectuurrequirements
Het streven naar samenhang, complexiteitsbeheersing en standaardisering (en dus flexibiliteit en verandervermogen) brengt met zich mee dat aan de doorgevoerde veranderingen extra eisen worden gesteld. Projecten, waarbinnen de veranderingen hun gestalte krijgen, worden uitgevoerd om een oplossing op te leveren voor een businessprobleem. De behoefte van de opdrachtgever moet vervuld worden. Deze behoefte wordt vastgelegd door het opstellen van requirements, meestal uitgesplitst in business-, user- en systemrequirements (BUS-requirements) om het verschil in detailniveau duidelijk te kunnen maken.
Het werken onder architectuur betekent onder meer dat aan deze projectoplossingen additionele eisen worden gesteld; de architectuurrequirements. Deze eisen worden gesteld om ervoor te zorgen dat de oplossing die het project oplevert past in het grotere geheel en daarmee de samenhang bevordert en de complexiteit in ieder geval niet vergroot en liefst nog verkleint. Daarnaast wordt een bijdrage geleverd aan standaardisatie. Deze architectuurrequirements betreffen dan niet de functionele oplossing van het probleem zelf, zoals de BUS-requirements, maar de inrichting van de oplossing en de vrijheidsgraden die daarbij gelden. Deze inrichting moet toekomstvast zijn. De architectuurrequirements hebben dus een bredere scope en een langere termijn dan de BUS-requirements. Figuur 1 laat deze relatie zien.
Figuur 1 Relatie architectuur- en BUS-requirements
De essentie van de PSA
De essentie van de PSA is om de architectuurrequirements duidelijk te maken aan het projectteam en dan met name de ontwerpers / ontwikkelaars. Daarbij worden de requirements concreet gemaakt en met de ontvangers besproken. Deze architectuurrequirements vormen het kader waarbinnen het project moet worden uitgevoerd. Door binnen dat kader te blijven wordt ervoor gezorgd dat het eindresultaat, dat door het project wordt opgeleverd, past in de totale informatievoorziening. Dit architectuurkader bestaat uit de concrete standaarden, normen en richtlijnen die een vertaling zijn van de principes en beleidslijnen uit de algemene referentie architectuur (figuur 2).
Figuur 2 Relatie referentie architectuur – PSA
De principes in de referentie architectuur zijn meestal op een dusdanig abstractieniveau beschreven dat een ontwerper daar moeilijk mee uit de voeten kan. Door deze principes concreter te formuleren en voor elk van deze geconcretiseerde principes de consequentie(s) voor het onderhavige project aan te geven, worden zij dusdanig werkbaar, dat zij op dezelfde manier te behandelen zijn als de BUS-requirements. Zij zijn daarmee binnen het verdere verloop van het project een gelijksoortige eend in de bijt.
Naast de concrete vertaling van de principes en hun consequentie(s), wordt er in de PSA voor de verschillende deelarchitecturen een afbakening gegeven op basis van de scope van het project. Deze afbakening is een visuele weergave van de verschillende componenten van die deelarchitectuur die binnen de scope vallen en van hun interfaces. Figuur 3 laat een voorbeeld hiervan zien van een procesarchitectuur.
Figuur 3 Voorbeeld afbakening Procesarchitectuur
Tot slot, maar daarmee zeker niet het minst belangrijk, geeft de PSA ontwerpbeslissingen weer die hun impact hebben buiten de scope van het project en daarom mede vanuit de architectuur genomen zijn. Deze ontwerpbeslissingen liggen op het gebied van diezelfde samenhang, complexiteit en standaardisering. Binnen het project worden de BUS-requirements gaandeweg steeds verder uitgewerkt en zijn daarbij aan verandering onderhevig. Het merendeel van deze projectoverstijgende ontwerpbeslissingen zal daarom in de loop van het project naar boven komen. Op dat moment worden zij besproken en worden de beslissingen vanuit het architectuurperspectief genomen. De beslissingen worden in de PSA vastgelegd, zodat zij opgenomen kunnen worden in de referentie architectuur. Deze ontwerpbeslissingen gelden namelijk niet alleen voor de betreffende oplossing, maar ook voor alle gelijksoortige oplossingen.
De kernbegrippen van de PSA zijn dus samenhang, consistentie en integratie. De verschillende deeloplossingen moeten passen op elkaar en binnen de totale informatievoorziening. Dit kan gezien worden als het buitenkant- of ‘black-box’ perspectief van de oplossing.
De essentie van de Solution Architecture
TOGAF9 geeft de volgende definitie van een Solution Architecture:
“A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.”
Een project wordt gestart om een bedrijfsprobleem op te lossen. De BUS-requirements worden vertaald naar een visie op de oplossing en een high-level specificatie ervan. Vrij vertaald betreft de Solution Architecture de beschrijving van de oplossing voor het bedrijfsprobleem. Dit kan gezien worden als het binnenkant- of ‘white-box’ perspectief.
Architectuur versus ontwerp
In de aanhef van dit artikel is aangegeven dat de Solution Architecture soms wordt opgenomen in de PSA. Mijns inziens ligt de oorzaak daarvan in het feit dat de twee verschillende architectuurperspectieven, zoals die hiervoor genoemd zijn (‘black-box’ en ‘white-box’) door elkaar zijn gaan lopen. Beiden worden architectuur genoemd, maar er wordt iets verschillends mee bedoeld. In de kern betreft het hier het onderscheid tussen architectuur en ontwerp.
Een algemene geaccepteerde definitie van architectuur, die aan deze verwarring heeft bijgedragen, is die van de ISO-standaard ISO/IEC 42010:2007. Deze definitie luidt:
“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”.
In deze definitie worden beide perspectieven verwoord. Het white-box perspectief komt tot uitdrukking in ‘de fundamentele organisatie van het system in zijn componenten en hun relaties’. Dit is de betekenis van architectuur zoals die terugkomt in de Solution Architecture. Dit wordt architectuur genoemd, terwijl eigenlijk structuur en ontwerp wordt bedoeld. Het gaat hierbij om de beschrijving van een specifieke oplossing voor een bedrijfsprobleem.
De PSA is bedoeld voor architectuur in de betekenis van de ‘principes die het ontwerp en de evolutie sturen’. Het gaat hierbij om de specifieke toepassing van algemeen toepasbare ontwerpprincipes en standaarden die bruikbaar zijn voor een klasse van systemen teneinde integratie, samenhang en flexibiliteit te realiseren. De architectuurprincipes geven richting aan het ontwerp. De architectuur gaat dus aan het ontwerp vooraf. Juist omdat de oplossing van een project in het grotere geheel moet passen, worden aan het ontwerp beperkingen opgelegd door de architectuur. Architectuur beperkt de ontwerpvrijheid. In het ontwerp worden de principes gehanteerd. Om dat te kunnen moeten deze vooraf bekend zijn.
De Solution Architecture apart van de PSA
De Solution Architecture is het ontwerp van de oplossing voor het bedrijfsprobleem waarvoor het project is opgezet. De PSA bevat de architectuurprincipes, die geconcretiseerd zijn tot architectuurrequirements waaraan die oplossing moet voldoen. Een ontwerp wordt pas gemaakt als de requirements die aan de oplossing worden gesteld, bekend zijn. En dus, zoals architectuur vooraf gaat aan ontwerp, gaat de PSA vooraf aan de Solution Architecture.
Een tweede reden waarom het beter is om de PSA en de Solution Architecture apart te houden is, dat ze, zoals eerder gesteld, verschillende doelen hebben met een verschillende scope en termijn. De verantwoordelijkheid voor het oplossen van het bedrijfsprobleem (Solution Architecture) ligt bij de Stuurgroep van het project. De architectuurfunctie, al dan niet vertegenwoordigd door een Architectuurraad, is ervoor verantwoordelijkheid dat de oplossing in het grotere geheel past. Daar was immers de PSA voor bedoeld. Op het moment dat de oplossing niet goed past in het grotere geheel (anders gezegd: de korte termijn doelstelling strookt niet met die van de lange termijn) moet een afweging gemaakt worden of de oplossing aangepast moet worden of dat de architectuur een veer moet laten. Dit moet expliciet bediscussieerd worden tussen de verantwoordelijke partijen, zodat de consequenties duidelijk worden en er eventueel verzachtende maatregelen genomen kunnen worden. Een scheiding van PSA en Solution Architecture bevordert de betrokkenheid van beide instanties en daarmee de openheid van de discussie. Hierdoor worden beide belangen in balans overwogen. Deze balans is ook de reden dat de PSA wordt opgesteld door de projectarchitect, die buiten het projectteam staat. Hij is verantwoording verschuldigd aan de Architectuurraad. De Solution Architect is doorgaans onderdeel van het projectteam en dus verantwoording verschuldigd aan de projectleider. Wel moet hij ervoor zorgen dat de Solution Architecture inhoudelijk voldoet aan de PSA.
Een derde reden voor het gescheiden houden van de PSA en de Solution Architecture is dat het opstellen van de PSA anders te lang duurt en dat er teveel wordt gedaan op een te vroeg moment in het project. De PSA wordt opgesteld op een moment dat het project formeel nog moet beginnen. Sterker nog, de definitieve ‘go’ moet nog gegeven worden. Het bevindt zich in de analysefase, waarbinnen de requirements verzameld en nader gespecificeerd worden. Op basis daarvan wordt een plan van aanpak voor het project opgesteld. Als op dit moment de Solution Architecture (lees: het ontwerp) al gemaakt wordt, wordt de doorlooptijd voor het opleveren van het plan van aanpak (onnodig) langer. Daarbij kunnen deze ontwerpactiviteiten overbodig zijn als op basis van dat plan van aanpak de definitieve go niet gegeven wordt.
Een ander aspect hieraan is, dat met de vermenging van PSA en Solution Architecture de scheiding tussen projectarchitect en Solution Architect vervalt. Dit wordt dan meestal één en dezelfde persoon. Hierdoor besteedt de architect zijn kostbare en schaarse tijd aan het maken van ontwerpen. Dus eigenlijk doet een architect een deel van het werk dat een project hoort te doen, waardoor hij onvoldoende tijd overhoudt voor het architectuurwerk. Maar de architect heeft andere dingen te doen en moet ontwerp overlaten aan de ontwerpers. Een ander gevolg van het vermengen van de rollen is dat in de praktijk het architectuuraspect vergeten wordt. Het belang van het oplossen van het bedrijfsprobleem overheerst dan over het architectuurbelang van de integratie, samenhang en flexibiliteit. De druk vanuit het project krijgt de overhand. De hierboven geschetste balans is verstoord.
Bovenstaande redenen geven aan dat zowel vanuit de theorie als de praktijk duidelijk is dat de Solution Architecture niet in de PSA thuishoort!
The core of any EA development is the framework, i.e. its meta-architecture. The framework is the glue between components and artifacts. Without a good framework, there is no navigation between artifacts and their components.
Without a framework, we can deliver predictable and repeatable outcomes. An EA framework represents the architecture of the EA, that is the meta-architecture of the Enterprise, i.e. an EA structure with hooks where components fit back in, like the chassis where the car parts mount on.
In this paper, we investigate the mapping between ArchiMate’s concepts and TOGAF’s implicit and explicit meta models along the following lines. First, we ask whether TOGAF’s meta model aligns with ArchiMate’s. We investigate the generic, meta meta level of both and go deeper into the business architecture, data architecture, applications architecture and technology architecture as prescribed by TOGAF, to see whether we can express the required TOGAF notions in ArchiMate. We conclude with recommendations to the designers of both ArchiMate and TOGAF.
Bedrijfsprocessen in kaart brengen blijft een vak apart. Er zijn inmiddels schitterende modelleertools waarmee procesmodellen met één druk op de knop kunnen worden omgezet in werkende applicaties die die processen kunnen ondersteunen of op basis van bedrijfsregels zelfs volledig kunnen uitvoeren, maar in het woud van mogelijke tools en methodieken is het vaak moeilijk kiezen. Bovendien zijn beschikbare proces referentiemodellen die er voor verschillende branches en toepassingsgebieden zijn vaak lastig vertaalbaar naar de eigen praktijk.
This paper is the second in a series in which we intend to shed light on the possibilities of using the ArchiMate language with an architecture method and inform you on the pitfalls you may face. This paper follows up “Using ArchiMate with an Architecture Method”, which outlined some of the fundamental ideas behind ArchiMate and set out nine questions to ask of a method to be used in conjunction with it.
This second paper returns to answer the nine questions we defined in the first paper (to help you integrate the use of ArchiMate with your chosen architecture method) using TOGAF as an example architecture method.
The ArchiMate language for enterprise architecture has recently been adopted by The Open Group as a technical standard. This may result in a steep rise in its popularity. However, ArchiMate is only a language and does not prescribe a way of working. Hence, it will be used in combination with some other method to guide the process of architecting. Some assume it will be easy to use ArchiMate when following the process of their preferred architecture method. Indeed, it will be easy to use the ArchiMate box symbols in drawing artifacts/diagrams. Perhaps many will do this, thinking they have thus used the ArchiMate language with their method.
Danny Greefhorst, Sander Rodenhuis, Toine Schijvenaars, Erwin Oord, Jan Willem van Veen
Monday, 11 May 2009
Een enterprise-architectuur in twee weken
Architectuur is een belangrijk instrument bij het veranderen van organisaties. Organisaties zijn in veel gevallen nog wel op zoek naar hoe ze dit instrument precies moeten hanteren. Deze zoektocht leidt er veelal toe dat architectuur overmatig wordt toegepast en onvoldoende aansluit op de doelstellingen. Dit artikel beschrijft een pragmatische visie en een bijbehorende aanpak voor enterprise-architectuur. Deze aanpak levert in twee weken al veel toegevoegde waarde.
Since architecture is a relative new field, much debate goes on about the methods and techniques to be used within the field. Since one of the key competencies of an architects is to be able think conceptually, it is only natural for architects to engage in lengthy discussions about their tools, techniques, approaches and methods. A recent example of such a discussion can be found on the Via Nova Architectura website, where a rather opinionative posting on TOGAF 9 resulted in an involved discussion with 38 elaborate responses.
De komst van de alweer negende versie van het architectuurraamwerk van de Open Group – TOGAF – heeft een verhit debat in de architectencommunity veroorzaakt. Daan Rijsenbrij stelde in zijn column in de Automatiseringgids dat TOGAF een regelrechte bedreiging voor de creativiteit van architecten vormt en pleitte voor een bijsluiter met die strekking. Op Via Nova Architectura leverde dit niet minder dan 38 reacties op – de één nog gepeperder dan de andere. Is de Open Group doorgeschoten in haar ambitie om een wereldstandaard voor architectuur neer te zetten, of hebben ze alleen misgeschoten?
In het boek "bedrijfsarchitectuur" geven de auteurs een goed overzicht van het architectuur vakgebied in de volle breedte. Het is bewonderenswaardig hoeveel informatie de auteurs in dit boek bijeen hebben kunnen brengen. Het is wel wat jammer dat het boek voor een deel weer eigen terminologie introduceert.
In 1982 schreef Jaap van Rees het roemruchte artikel ‘de methode doet het niet’. Sinds die tijd is er een ware vloedgolf aan methodenboeken op de markt verschenen. Veel methoden zijn trouwens activiteitgeoriënteerd, dus uitermate geschikt om op basis van uurtje-factuurtje op mechanische wijze body shopping uit te voeren. Het is dan ook niet voor niets dat veel methodes door softwarehuizen zijn bedacht dan wel worden gepropageerd.
‘De methode doet het niet’ geldt des te sterker voor projecten die een hoge mate van creativiteit en situatieafhankelijkheid vergen. ....
Henk Jonkers, Marc M. Lankhorst, Maria-Eugenia Iacob, Erik Proper
Tuesday, 17 March 2009
De internationale standaard voor het modelleren van enterprise-architecturen
De Open Group werkt al jaren aan standaarden. Eerst waren dat standaarden op het gebied van protocollen en operating systems. Sinds het einde van de jaren negentig richt men zich ook op standaarden voor het werk van architecten. The Open Group Architecture Framework (TOGAF), waarvan onlangs versie 9 is verschenen, is uitgegroeid tot een van de meest toonaangevende methoden voor enterprise-architectuur. In dit artikel kijken we naar ArchiMate, de nieuwe Open Group-standaard voor architectuurmodellering.
Dragon1 is een beweging die enterprise architectuur uitdraagt als ontwerp- en realisatiediscipline voor duurzame, toekomstvaste en integrale bedrijfs/IT-oplossingen. In deze blog zet ik kort uiteen wat de essentie is van Dragon1. Dit zodat iedereen zelf een beeld kan vormen over wat Dragon1 is in het licht van andere bewegingen, methoden en aanpakken. En ook de mogelijkheid heeft om er kennis van te nemen.
Bij de opzet van Dragon1 we gekozen voor het bewegingsmodel. Naast een methode in boeken, cursussen, sjablonen, voorbeelden en checklisten, is er bij Dragon1 ook een Dragon1 Usergroup, een Dragon1 Architecture Foundation en een XR. e-magazine.
Met al deze zaken wordt ervoor gezorgd dat steeds meer mensen kennis kunnen nemen op een laagdrempelige en zeer toegankelijke wijze van het gedachtengoed dat Dragon1 heet. Iedereen die wil bijdragen aan Dragon1 kan dat via de Usergroup. Dat gebeurt nu nog kleinschalig elke maand in Wageningen.
Architectuur leer je niet uit een boekje, maar van een meester en na jarenlange uitoefening. Daarom: Niet TOGAF is verplichte kost voor de architect, maar de oratie van Daan Rijsenbrij. TOGAF is een goed (reactief) analyse/managementinstrument, voor IT-architectuur, of beter gezegd: IT-structuur en IT-constructie. Dragon1 is volgens de Dragon1-gebruikers meer een (proactief) ontwerp/strategisch instrument voor bedrijfstransformaties en IT-innovatie onder enterprise architectuur. Maar methoden blijven methoden. Je hebt goeroes nodig die aan de hand van een methodische aanpak laten zien hoe je mooie dingen maakt.
Er zijn de afgelopen tien jaar veel architectuurmethoden, technieken en raamwerken verschenen. Veel van deze methoden en technieken zijn afkomstig van adviesorganisaties en niet publiek beschikbaar. Er is echter een duidelijke trend naar open standaarden en TOGAF en ArchiMate zijn daarvan goede voorbeelden. In dit artikel wordt een overzicht gegeven van TOGAF, waarbij met name wordt ingegaan op TOGAF 9. Aanleiding is de publicatie ervan op 2 februari 2009 op de Open Group conferentie in San Diego.
In the introduction of the book the author promises “to answer some of the common sense business questions related to Enterprise Architecture”. Reading the book, I got very soon the impression that he in fact, wanted to answer every potential question. Some aspects are discussed on the level to guide the Architect, others to teach the Business Manager.
The EA framework is the meta-architecture of the Enterprise or the Architecture of the Enterprise Architecture. This item explores what an EA framwork is and what is should consist of.
In dit artikel pogen de auteurs de balans op te maken van een aantal ontwikkelingen op het terrein van bedrijfsmodellering. Met het positioneren van een aantal veelbesproken technieken voor visuele modellering wordt gepoogd meer helderheid te scheppen in het enorme aanbod op dit gebied. Tot slot wordt er gekeken naar voor de nabije toekomst te verwachten of gewenste uitbreidingen op bestaande praktijken.
In this research project, ing. J.M. Cloo developed a framework for evaluating architecture modeling methods for their suitability for modeling services and applied it to three of the most frequently used methods within Capgemini by Business architects: DEMO (Dietz, 1999) and Business modeling Method for Information planning (BMI). The framework consists of criteria for modeling methods and a classification of these criteria.
Systems development methods are used to express and communicate knowledge about systems and software development processes; i.e. methods encapsulate knowledge. Since methods encapsulate knowledge, they also encapsulate rationale. Rationale can in this context be understood as the reasons and arguments for particular method prescriptions. In this paper we show how the combination of two different aspects of method rationale can be used to shed some light on the communication and apprehension of methods in systems development. This is done by way of clarifying how method rationale is present at three different levels of method existence. By mapping existing research on methods onto this model, we conclude the paper by pointing at some research areas that deserve attention and where method rationale could be used as an important analytic tool.
Massimo Cossentino, Salvatore Gaglio, Brian Henderson-Sellers, Valeria Seidita
Monday, 05 June 2006
Several different approaches to Situational Method Engineering exist. They differ in terms of the primary element of the paradigm: the method fragment definition. Here, we introduce four method fragment definitions from the literature and compare their metamodels according to structural and functional criteria. The structural comparison showed a general alignment of some concepts that are sometimes referred with different names while the study of the compositional aspects results in evidence of substantial differences.
Het doel van dit onderzoek was om een methode te ontwikkelen voor de evaluatie van digitale architectuur. Er zijn verschillende gebieden onderkend die allemaal te evalueren zijn. Twee belangrijke stromingen zijn de productgeoriënteerde aanpak en de procesgeoriënteerde aanpak. De keuze is gemaakt om het product van architectuurontwikkeling te evalueren, de architectuurdocumentatie. De Architectuur Documentatie EvaluatieMethode is een raamwerk die verschillende scans bevat die uitgevoerd kunnen worden.
Tijdens de evaluatie van de gemeente Amsterdam door middel van de voorbereidende scan werd vrijsnel duidelijk dat er verschillende belangrijk geachte elementen niet aanwezig zijn. Zo is de rationaliseringsketen niet expliciet gemaakt waardoor er geen fundering is voor alle gekozen oplossingen in de architectuurdocumentatie. Tevens zijn er geen stakeholders en concerns opgenomen waardoor de validiteit van de architectuurprincipes niet gegarandeerd is. De gemeente Amsterdam dient de rationaliseringsketen dan ook expliciet op te nemen in de volgende versie. Aangezien de architectuurdocumentatie belangrijke elementen mist zou de holistische scan niet mogen worden uitgevoerd.Dit is omwille van het onderzoek toch gedaan. ...
David Campbell, Guido Chorus, Yves Janse, Chris Nellen, Paul van Vlaanderen, Robin van ’t Wout
Friday, 15 June 2007
Dit document is het resultaat van een onderzoek binnen het vakgebied van de Digitale Architectuur, zoals dit gedoceerd wordt aan de Radboud Universiteit te Nijmegen. Het onderzoek is door zes studenten uitgevoerd onder begeleiding van prof. dr. Daan Rijsenbrij en prof. dr. Erik Proper. Dit document beschrijft de eerste fase van het onderzoek; de ontwikkeling van een architectuurevaluatiemethode. In de tweede fase wordt dit onderzoek voortgezet op individuele basis. Een aantal onderdelen van de methode worden dan verder uitgediept. Ook wordt de in dit document voorgestelde methode getest door een bestaande architectuur te evalueren. Deze fase is niet beschreven in dit document.
This report is a result of research conducted for the Radboud University of Nijmegen and Sogeti Nederland B.V. Our main research question was to determine how an architect can create a usable description of an enterprise. This research question was defined because architects require insight into the enterprise which enables them to develop a usable architecture. At the time this research initiated it was yet unknown how usable descriptions could be created.
Vítor Estêvão Silva Souza, Ricardo de Almeida Falbo, Giancarlo Guizzardi
Friday, 22 June 2007
The rapid evolution of the area of Web Engineering has motivated the proposal of several methods and frameworks for the development of Web Information Systems (WISs). In particular, it is becoming more and more common to use containerbased architectures and frameworks when it comes to their development. Following this idea, we have proposed a method for designing frameworkbased WISs, called FrameWeb. and, in this paper, we present FrameWeb's UML profile for modeling framework components in design models.
This paper presents experiences and reflections from using the EKD Enterprise Modeling method since the beginning of the 1990’ies. A large number of application cases have been carried out. The paper focuses on the EKD modeling language, the EKD modeling process and supporting tools.
A large number of strategies, approaches, meta models, techniques and procedures have been suggested to support method engineering (ME). Most of these artifacts, here called the ME artifacts, have been constructed, in an inductive manner, synthesizing ME practice and existing ISD methods without any theory-driven conceptual foundation. Also those ME artifacts which have some conceptual groundwork have been anchored on foundations that only partly cover ME. This paper presents an ontological framework, called OntoFrame, which can be used as a coherent conceptual foundation for the construction, analysis and comparison of ME artifacts. Due to its largeness, we describe here its modular structure composed of multiple ontologies. For each ontology, we highlight its purpose, sub-domains and theoretical foundations. We also mention the approaches and process by which OntoFrame has been constructed.
The discipline of situational method engineering (SME) promotes the idea of retrieving, adapting, and tailoring fragments, rather than complete methodologies, to specific situations. In order to succeed in creating good methodologies that best suit given situations, fragment representation and cataloguing are very important activities. We introduce a visual SME approach,whose roots are in domain engineering. This approach relies on the Application-based DOmain Modeling (ADOM) approach, which provides a framework for representing both applications and domains and validating them each against the other. Furthermore, the proposed ADOM-based approach aims at supporting all the SME-related activities, while in this paper we focus only on its fragment representation and cataloguing parts. The main advantages of the approach are its expressiveness, its support for specifying, constraining, and...
We propose a three stage method development life cycle. The requirements engineering phase consists of elicitation and representation of method intentions, the design phase produces the architechture of the method and the construction phase consists of organizing method features in a coherent whole. We concentrate in this paper on the Design and Construction phases of the life cycle. We explaion our notion of method architecture and organization and illustrate them. Finally we show the relevance of method architecture and organization in SME. The design and consturction engineering phases of our life cycle are illustrated for a small SME example.
Little scientific research has as yet been done on projects conforming to Enterprise Architecture. To lay foundations for such research, this paper presents a theoretical framework for defining the Project Architecture (PA) in the context of working with Enterprise Architecture. One part of the PA is the Project Start Architecture (PSA), which bounds the project to the Enterprise Architecture (EA) and/or Domain Architecture (DA). We start with explicating the context of a PSA in terms of its relation to the EA and DA. Subsequently, we define the PA in terms of three dimensions. The first dimension con-tains four aspect areas. The second dimension features four abstraction levels. The third dimension contains two project content categories: the PSA (containing prescriptions inherited from the EA and/or DA) and the PED (the Project Exclusive Design, containing the fundamental analysis and design artifacts that have been created specifically for the project). A real-life case is used to help illu-strate and validate the theoretical framework. Additionally, a mapping with RUP artifacts is made to further clarify the framework of the PA with examples of well-known analysis and design artifact types.
The aim of this research is to develop an information agent framework for knowledge discovery in enterprise architecture (EA). This framework is based on specific purpose ontology and knowledge discovery techniques. Such framework would facilitate strategic decision making for EA stakeholders by enabling them to analyze and monitor the portfolio of processes, data, applications, and organizational units in terms of their correlation and impact in the overall organization. This framework is very useful for affording key stakeholders with the appropriate view that is reliant on an accurate and concise picture of systems, applications, technologies and other infrastructure elements in the business and how these integrate to serve the enterprise. The paper discusses the concepts and components of this framework. Potential benefits of this framework over existing approaches are also discussed.
In this article, we explore the possibilities of combining ArchiMate, a modelling language for enterprise architecture (EA), with TOGAF, The Open Group Architecture Framework, a design method for EA.
In een serie van artikelen wordt een generiek uitbreidbaar (IT-) Architectuurraamwerk beschreven. In dit eerste artikel wordt gedetailleerd ingegaan op de essentie van het ontwerpproces.
In een serie van artikelen wordt een generiek uitbreidbaar (IT-)Architectuurraamwerk beschreven. In dit tweede artikel wordt het Metamodel xAF beschreven en zal nader worden ingegaan op de Architectuur-principes.
