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.
Inleiding
Het grootste probleem bij het modelleren van processen ligt in het goed in beeld hebben van de bedrijfsprocessen zelf. Zijn het de juiste processen? Hebben we alle noodzakelijke processen te pakken of zijn er nog witte vlekken? Zijn de processen op de juiste manier afgeleid van de klantbehoeften? Zijn ze afgesteld op de te bereiken bedrijfsdoelen? Zitten ze logisch en begrijpbaar in elkaar? Bovendien wordt het feit dat het bij bedrijfsprocessen in essentie om communicatie gaat tussen mensen nog al eens vergeten. Al met al veel werkende systemen maar vaak minder werkbare processen.
Op zoek naar een manier om grip te krijgen op het vakgebied van bedrijfs(-proces)modellering ben ik de afgelopen jaren binnen allerlei klussen onder andere op de volgende onderwerpen gestuit:
Hoe moet de bedrijfsstrategie worden doorvertaald naar processen (top-down)?
Hoe kan bovenop het bestaande applicatielandschap een procesarchitectuur worden ontwikkeld (bottom-up)?
Hoe ziet de financiële structuur van een waardeketen eruit?
Hoe moet regie worden gevoerd bij een ingewikkelde productcombinatie?
Hoe kunnen uitbestedingsmogelijkheden worden onderkend?
Hoe zien de klantprocessen eruit?
En meer marktsegment gerelateerd:
Hoe kan een traditioneel energiebedrijf worden opgesplitst naar verschillende bedrijven?
Hoe kunnen de content-, service- en netwerklaag van een telecomoperator het best worden doorvertaald naar bedrijfsprocessen
Hoe past het elektronisch medicatie dossier (EMD) binnen de besturing op diagnose behandeling combinatie (DBC)?
Bij dit soort vragen ging ik altijd hardnekkig op zoek naar een bedrijfsgrondvorm waarop alle processen in hun samenhang konden worden afgebeeld. Mijn ervaringen binnen de logistieke wereld aan het begin van loopbaan had mij overtuigd van de noodzaak daarvan. Voor ieder informatievoorzienings project of het nu om een bestaande situatie ging of om nieuw te introduceren producten en diensten werd een logistieke grondvorm opgesteld om de juiste processen te kunnen afbeelden en de daaruit voortvloeiende systeemeisen. De logistieke grondvorm geeft de samenstelling en beweging van goederen weer ‘van zand tot klant’. Maar het opstellen van zo’n grondvorm bleek vervolgens binnen de telecombranche een stuk lastiger voor me te zijn.
Waaraan zou een bedrijfsgrondvorm moeten voldoen. Zo’n grondvorm zou een basiskaart moeten zijn voor de bedrijfsvoering net zoals een basiskaart van een geografisch gebied in een atlas. Daarmee krijgt een bedrijfsgrondvorm een soort kadasterfunctie. Op die basiskaart moeten vervolgens bedrijfsmodellen voor alle relevante bedrijfsaspecten kunnen worden afgebeeld: producten, processen, bedrijfsregels, prestatie-indicatoren, menselijke expertise, IT, organisatorische verantwoordelijkheden et cetera. En waar zou dat dan toe moeten leiden? Consistentie van de bedrijfslogica en transparantie in de besluitvorming. En anders? Stuurloos ronddobberen! Al met al een lastige klus die alleen te klaren bleek te zijn door standaard uitgangpunten te zoeken in de diversiteit van bestaande modellen en methoden met als uitgangspunt: houdt het zo grofmazig en eenvoudig mogelijk en laat ruimte voor eigen invullingen, afwijkingen en uitzonderingen.
Startpunt om tot een duidelijke bedrijfsgrondvorm te komen is het opzetten van een productstructuur die nodig is om de door de klant gevraagde producten en diensten te kunnen realiseren. Want wat je maakt is wie je bent! Een duidelijke product/dienst architectuur maakt de waardestromen (value streams) inzichtelijk. Hoe lopen goederen/diensten, informatie en geldstromen en welke processen moeten daarvoor worden ingericht.
Hamburgermodel
Een manier om producten en diensten in kaart te brengen vond ik in het zogenaamde “hamburgermodel”, ontwikkeld door Wim Gielingh voor de fysieke bouwwereld [Gielingh, 2008]. In dit model worden gevraagde functionaliteit en geboden oplossing tegenover elkaar gezet als top en bodem van het broodje. Het totale broodje geeft daarmee het product of productelement weer (zie afbeelding 1). Deze afbeeldingwijze dwingt je om bij het opstellen van producteisen uit te gaan van de wensen van de klant (een prima manier van werken bij bijvoorbeeld six sigma).
Afbeelding 1: het hamburgermodel
Een heel erg goede toepassing van het hamburgermodel vond onlangs in het boek van Tim Zaal: Integrated Design and Engineering [Zaal, 2009]. Binnen de bouwwereld wordt het model gebruikt om de samenstelling van product/gebouw uit zijn fysieke componenten (bill of material) weer te geven.
Maar buiten fysieke componenten zijn binnen de meeste bedrijfssectoren ook niet fysieke producten of diensten te onderkennen. Hoe kunnen die dan worden afgebeeld en in een product/dienststructuur worden ondergebracht? Bij het zoeken naar een oplossing hiervoor hanteerde ik het uitgangspunt ooit door mijn collega Eric Winter aangedragen dat er in principe maar vier soorten producten en diensten zijn die kunnen worden geleverd: een idee of concept (verbeelding), een handmatige of geautomatiseerde activiteit (verrichting), een tastbaar product (voorwerp) en de beschikbaarheid of capaciteit ergens van (voorziening). Om deze verschillende soorten producten aan elkaar te kunnen knopen heb ik gebruik gemaakt van het bekende IGOE-model (input, guide, output, enabler). In een zin geformuleerd laat dit model zien wat (O) gemaakt wordt, waarvan (I), hoe (G) en waarmee (E). Afbeelding 2 toont het klassieke model waarbij de waardestroom van input naar output van links naar rechts loopt en een rechtop gedraaide versie ervan dat binnen een top-down product/dienst structuur kan worden gehanteerd. Zo ontstaat in feite een bedrijfsfunctie hiërarchie binnen de product/dienst structuur.
Afbeelding 2: het IGOE-model; basismodel (horizontaal) en 90° gedraaid (verticaal)
Door vervolgens het hamburgermodel en het IGOE-model aan elkaar te koppelen ontstaat een vast patroon dat toepasbaar is op elk besturingsniveau, fungerend als een soort business DNA. Binnen verschillende opdrachten probeer ik altijd op ieder niveau met dit patroon de chaos te lijf te gaan (zoals chaostheorie gebruikt maakt van fractals).
Afbeelding 3: het ‘PSOA’ basispatroon
Het patroon, weergegeven in afbeelding 3, levert een bouwblok op voor een architectuurstijl die ‘product/service oriented architecture’ (PSOA) genoemd zou kunnen worden. In ieder geval maakt het de aansluiting met een SOA aanpak vanuit business optiek een stuk eenvoudiger. Omdat het bij bedrijfsvoering in essentie gaat om het creëren van waarde en deze werkwijze de afbeelding van de waardestromen boven tafel tilt spreek ik liever van een ‘value-stream oriented architecture’ (VOA) waarbij in de methodiek de door producten en diensten gecreëerde waardestroom van beneden naar boven loopt.
Voorbeelden
Hoe zien die plaatjes er dan uit? Ik zal een aantal voorbeelden laten zien. In afbeelding 4 wordt de primaire product-/dienst structuur van een telecombedrijf weergegeven dat IP diensten over glas levert. In dit model worden de bedrijfsfuncties nog weggelaten, maar worden de hamburgers met elkaar verbonden door connectoren die corresponderen met de verbindingen uit het IGOE-model. De ‘R’ connector staat voor ‘regie’. Bij de keuze voor kleuren en symbooltjes om te ‘geboden oplossing’ (bodem van de hamburger) weer te geven zijn de eerder genoemde vier verschillende product/dienst soorten als uitgangspunt genomen. Conventies hiervoor staan nog niet vast, maar worden met de opdrachtgever afgesproken.
Afbeelding 4: telco productstructuur voor IP-diensten over glas
Het voorbeeld is een gestripte versie van een product-/dienst structuur die binnen een telecomonderneming is opgesteld en waarbinnen totale portfolio in kaart werd gebracht. Deze werd uitgangspunt gehanteerd voor onder meer de volgende activiteiten:
consistent maken van de samenhang van deelproducten;
formuleren uitgangspunten voor de kostenstructuur;
opstellen protocol voor het uitvragen van de klant bij storingen;
toepassen van het eTOM model (enhanced Telecom Operations Map) van het Telemanagement Forum dat binnen de telecomsector als mondiale standaard wordt gehanteerd voor processen;
definiëren van de benodigde bedrijfsprocessen (in dit geval verder uitgewerkt in ARIS van IDS-Scheer) en de kpi’s daarbinnen;
ontwerpen initiële levering (aansluiting) inclusief regie daarbinnen en continue levering (verbruik) in hun onderlinge relatie;
afbeelden van de IT op de processen.
Als belangrijkste resultaten bleek de aanpak consistentie in de keten op te leveren en inzicht te bieden in witte vlekken in procesbeschrijvingen.
Een andere toepassing van de methodiek wordt weergegeven in afbeelding 5. Hier is een bedrijfsdashboard gecreëerd om bedrijfsdoelen via ‘als-dan’ relaties in hun onderlinge samenhang zichtbaar te maken. De IGOE aanduiding is uit de ‘highlevel’ bedrijfsfuncties innoveren en produceren weggelaten. Een hamburgermodel op dit niveau fungeert als totaalframe voor de onderneming. Een dergelijk dashboard kan worden opgesteld voor de verschillende besturingsniveaus: totale onderneming, verschillende product/markt combinaties, verantwoordelijke organisatorische eenheden, afdelingen en personen. Ook tussen deze niveaus worden de doelen via ‘als-dan’-relaties verbonden. Door bedrijfsdoelen en –functies op deze manier met elkaar in balans te brengen wordt een consistente bedrijfsinrichting verkregen (balanced business).
Afbeelding 5: basispatroon als bedrijfsdashboard
Tot slot nog een plaatje uit de zorgsector. Afbeelding 6 laat een ‘product breakdown structure’ (PBS) zien waarop het proces ‘voorbereiding operatie’ kan worden afgebeeld. Het model geeft een overzicht van alle benodigdheden (met de aanwezigheid van de patiënt als uitgangspunt) om een operatie te kunnen uitvoeren en de bedrijfsfuncties die daartoe moeten worden uitgevoerd.
Deze structuur vormt de basis voor onder andere de volgende onderwerpen:
vaststellen van het niveau in de PBS waarop het proces nog patiëntspecifiek is (naar analogie van het klantorder ontkoppelpunt in de logistiek);
bepalen van de kostenopbouw en het niveau tot waar volgens de DBC code (diagnose-behandeling combinatie) wordt gebudgetteerd;
verder detailleren van onderkende bedrijfsfuncties met aanwezige protocollen en werkinstructies;
maken van procesuitwerkingen tot op het niveau van stappen uit het medicatieproces; verder detailleren van de vastleg- en raadpleegmomenten in het EMD (elektronisch medicatie dossier).
Het hier getoonde voorbeeld is op zich weer een deelpatroon binnen een totaalmodel dat kwaliteit van leven voor de ‘zorgconsument’ als vertrekpunt heeft. Via zorgvragen gedurende diens levensloop wordt verder ingezoomd naar zorgpaden, behandelingen en verrichtingen. Door een robuuste samenhang en transparante weergave ervan wordt zichtbaarheid in de zorg verkregen.
Conclusies
In dit artikel is ingegaan op een beperkt aantal uitgangspunten van de werkwijze met de hamburgers. Naast de uitgangspunten ‘gevraagde functionaliteit versus geboden oplossing’ en het IGOE model wordt ook nog gebruik gemaakt van een standaard indeling voor product- en dienst soorten en een standaard voor het vinden van meetmomenten in bedrijfsprocessen. Bij belangstelling wil ik daar een volgende keer graag dieper op in gaan.
Bij mijn werkzaamheden ben ik tot de conclusie gekomen dat op deze manier voor de meeste bedrijfssectoren communiceerbare en uitwerkbare plaatjes kunnen worden opgesteld. Bovendien bleek het mogelijk om bestaande referentiemodellen en methodieken te integreren in de denkwijze. Ook is de werkwijze bruikbaar in zowel bestaande situaties als voor nieuw te ontwikkelen business. In de praktijk bleek bovendien dat mensen uit verschillende disciplines in de afbeeldingen hun eigen werk herkenden. In een aantal gevallen werden langlopende discussies over inrichtingsvraagstukken (letterlijk) ogenblikkelijk beslecht. In workshop verband leidt een hamburgermodel als grote landkaart aan de wand bovendien tot verrassende resultaten.
Door de werkwijze te hanteren die ik in dit artikel heb beschreven bleek het mogelijk te zijn tot de juiste processen te komen, consistentie met klanteisen en bedrijfsdoelen te bereiken en een logische en begrijpbare en daardoor toepasbare bedrijfsarchitectuur te creëren.
Referenties
[Gielingh, 2008] W. Gielingh: “A theory for the modelling of complex and dynamic systems”, ITcon Vol. 13, p. 421, September 2008.
[Zaal, 2009] T. Zaal: “Integrated Design and Engineering - as a Business Improvement Process”, Maj Engineering Publishing, ISBN:9789079182039, 2009.
Zaakgericht werken is een principe dat een belangrijke rol speelt bij lokale overheden, maar zeker ook breder toepasbaar is. Het heeft veel overeenkomsten met service-oriëntatie. Het basisidee is dat je de diensten die je aanbiedt goed definieert en dat je de bijbehorende service levels bewaakt. Er zijn allerlei architectuurbouwblokken die een rol spelen bij zaakgericht werken zoals zaaksystemen, zaakmagazijnen en Persoonlijke Internet Pagina's. De vraag is echter wanneer de verschillende bouwblokken relevant zijn en hoe ze met elkaar samenhangen. Is bijvoorbeeld een zaakmagazijn noodzakelijk voor het publiceren van de status van vergunningen op Internet? In dit item zet ik alle belangrijke architectuurbouwblokken op een rij en laat hun samenhang zien.
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.
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!
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.
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.
Net gelezen in een reclame mail van DataMonitor: "Increasingly globalized and regulated markets are demanding unprecedented level of business process agility, control and transparency. As enterprise application platforms have failed to cater for the needs of highly-differentiated business processes, BPM is emerging as a possible solution.". Ik geloof dat niet. Waarom niet? Nou, eigenlijk vanwege een simpele redenering.
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.
Evaluation of modelling languages is important both to be able to select the most suitable languages according to the needs, and to improve existing languages. In this paper Business Process Modeling Notation (BPMN) is presented and analytically evaluated according to the Semiotic Quality Framework. BPMN is a functionally oriented language well suited for modeling within the domain of business processes, but probably also general processes not only within the business domain. The evaluation indicates that BPMN is easily learned for simple use, and Business Process Diagrams (BPDs) are relatively easy to understand. Tools may fairly easily map BPDs into the BPEL4WS format, but executable systems then require creation of Web Services representing the Activities in BPDs. ...
We describe in this paper an insurance company that has recently wanted to standardize on business process modeling language. To perform the evaluation, a generic framework for assessing the quality of models and modeling languages was specialized to the needs of the company. Three different modeling languages were evaluated according to the specialized criteria.
The work illustrates the practical utility of the overall framework, where language quality features are looked upon as means to enable the creation of models of high quality. It also illustrates the need for specializing this kind of general framework based on the requirements of the specific organization.
Business Process Models are typically used to express inter or intra –enterprise business activities/processes. Contractual obligations need to be fulfilled through execution of business processes on behalf of the contracting parties . To do so, business contract terms and conditions need to be semantically integrated to existing internal business process models. Contract obligation, performance, non-performance and other related concepts have been expressed as conceptual models in a Multi-Tier Contract Ontology (MTCO). Based on the MTCO, business process modelers may model the contract obligation fulfillment process as Contract Workflow Models(CWM) using Business Process Modeling Notation (BPMN) diagrams. ...
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.
Business Process Management (BPM) systems provide a broad range of facilities to enact and manage operational business processes. Ideally, these systems should provide support for the complete BPM life-cycle: (re)design, configuration, execution, control, and diagnosis of processes. In the research presented, we evaluate the support provided by the FileNet P8 BPM Suite, which is consistently ranked as one of the leading commercial BPM systems. Taking realistic business scenarios as starting point, we completed a full pass through the BPM cycle with several tools from the FileNet P8 BPM Suite. We checked whether the expected support was provided by these tools and we also tested their interoperability. ...
Business practice shows that, often, different process models are employed in the various phases of the Business Process Management life cycle, each providing a different paradigm for capturing and representing the business process domain. Recently, significant efforts have been made to overcome the disintegration of process models by providing complementary language standards for process design (BPMN) and execution (BPEL), based on the claim that these languages are semantically integrated. However, the conceptual mapping between both languages remains unclear, thus it is undecided whether any BPMN diagram can be transformed to BPEL. In this paper we argue that there is conceptual mismatch between BPMN and BPEL that needs to be identified in order to guide the language integration process semantically. In our analysis we take into account the various perspectives of the Business Process Management life cycle, in particular business and technical analyst perspectives. Our approach is generic and can also be utilized as a guiding framework for identifying conceptual mismatch between other business process modeling languages.
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.
Slowly but surely Business Process Management Systems1 gain in popularity and maturity. “The market for Business Process Automation software is small but growing rapidly. According to IDC, revenues are expected to approach $2 billion by 2006, compared with $295 million in 2001” 2. More and more organizations start projects orproof of concepts for implementing a BPMS tool for one or few of its processes. In itself a noble ambition: for people who believe that the Business Process is thé most important vehicle for running, improving and changing a business, BPMS is the way to go. This article therefore argues more the point of when and how to apply BPMS in the organization than the application of these tools itself.
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.
