Towards Architectural Maturity A starting point for architectural documentation of PinkRoccade Local Government s software product line

Transcription

1 Twards Architectural Maturity A starting pint fr architectural dcumentatin f PinkRccade Lcal Gvernment s sftware prduct line Niels Sauvé May 2010

2 Twards architectural maturity A starting pint fr architectural dcumentatin f PinkRccade Lcal Gvernment s sftware prduct line Eindhven May 2010 Authr N. Sauvé Eindhven University f Technlgy Department f Industrial Engineering & Innvatin Sciences Sectin Infrmatin Systems Under the authrity f: PinkRccade Lcal Gvernment Flight Frum DD Eindhven Under the supervisin f: Dr. S. Angelv First supervisr TU/e Ir. W.F. Rietveld Secnd supervisr TU/e Ir. A. Quanjer Supervisr PinkRccade Lcal Gvernment Page 2 f 90

3 Abstract This study has taken place at PinkRccade Lcal Gvernment with the gal f elabrating the cre f the architectural descriptin fr their sftware prduct line. The need fr detailed architectural dcumentatin f the sftware prduct line was identified in the preliminary stages f this study. The architectural descriptin cnsists f a set f architectural viewpints which are selected t address the cncerns f internal stakehlders f PinkRccade Lcal Gvernment. Cncrete architectural mdels are als included in the dcumentatin, as well as a descriptin f the research apprach twards the identificatin and definitin f the architectural viewpints and the creatin f the architectural mdels. The architectural dcumentatin and the prcess f creating this dcumentatin cmply with the cnceptual framewrk recmmended in the IEEE standard n architectural dcumentatin. Page 3 f 90

4 Preface This thesis is part f my graduatin prject at PinkRccade Lcal Gvernment. The prject was carried ut between January 2009 and January 2010 and is part f the final phase f the Master degree prgram f Business Infrmatin Systems at Eindhven University f Technlgy. PinkRccade Lcal Gvernment gave me the chance t perfrm a thesis study in a business setting. The purpse f this study was t elabrate the cre elements f the architectural dcumentatin fr the sftware prduct line f PinkRccade Lcal Gvernment. In this preface I wuld like t thank my supervisrs. I wuld like t thank Dr. Samuil Angelv fr his cntinuus supprt, his cnstructive criticism, and fr the fact that he was always there when help was needed. Als, I wuld like t thank Ir. Erica Rietveld fr her critical view n the definitin and the ratinale f my thesis study, and f curse fr her guided tur thrugh the city f Leiden. My gratitude als ges t Arnud Quanjer wh has been a great supervisr at PinkRccade Lcal Gvernment. His cnstructive ideas and guidance really aided in shaping the prject and its utcme. Last, but nt least, I wuld like t thank all my lved nes wh have been there fr me in this challenging year. Dad, I m s glad that everything has returned back t nrmal (r even better), and Inge, thank yu fr standing by my side during these last cuple f mnths! Page 4 f 90

5 Executive summary During the preliminary stages f the study, PinkRccade Lcal Gvernment was assessed with regard t the architectural maturity f their rganizatin. PinkRccade Lcal Gvernment was characterized by architectural prcesses which were primarily ad hc and infrmal. The need fr mre frmal, cmplete and cnsistent architectural dcumentatin f their existing sftware prduct line was identified. Therefre, this thesis prject fr the architectural descriptin f the sftware prduct line f PRLG was defined. This dcument presents the research apprach twards the selectin and definitin f the architectural viewpints and the creatin f the architectural mdels. Based n the stakehlder cncerns, a set f viewpints was selected and defined. The viewpints were dcumented in cnfrmance with the IEEE standard n viewpint specificatin. Each viewpint was dcumented by means f a name, stakehlders addressed by the viewpint, stakehlder cncerns addressed by the viewpint, language and mdeling techniques used fr the view, library viewpint reference, and ratinale fr the selectin f the viewpint. The final architectural descriptin cntains nine viewpints; each viewpint addresses different requirements and cncerns f stakehlders: Functinal viewpint Interface viewpint Custmer rganizatinal viewpint Custmer services viewpint Business prcess viewpint Applicatin prcess viewpint Cmmunicatin viewpint Data viewpint NORA viewpint The final set f nine viewpints required elabratin f a substantial amunt f views (sme f them at several aggregatin levels). This was nt feasible within the prject scpe and as a result, nly high-level and intermediate views were elabrated fr a number f viewpints. These architectural mdels, which were created in cnfrmance with their assciated viewpint s cnventins, are presented in this dcument. The prject was limited by fcusing n the internal stakehlders nly. Due t time limitatins, the fcus f the study was n dcumentatin f the business and cnceptual architecture aspects, mitting the technlgy infrastructure f the system at this stage. A prerequisite f the prject was that architectural descriptin had t be cmpliant with the NORA 2.0 standards. This architectural descriptin elabrates the cre elements fr the architectural dcumentatin f the sftware prduct line. It can be seen as a first step twards imprving architectural maturity f PinkRccade Lcal Gvernment. Page 5 f 90

6 Table f cntents Abstract... 3 Preface... 4 Executive summary... 5 Table f cntents... 6 Chapter 1 Cmpany Intrductin Histry f PinkRccade Lcal Gvernment Prduct characteristics Market characteristics Sftware prduct line f PinkRccade Lcal Gvernment Architectural maturity f PinkRccade Lcal Gvernment Chapter 2 Prject definitin Purpse f the prject and system definitin Limitatins and prerequisites f the prject Thesis structure Research apprach Chapter 3 Identificatin f stakehlders and cncerns Prcess f selecting stakehlders Structure f the interviews Stakehlder requirements and cncerns Chapter 4 Viewpints Prcess f viewpint selectin and creatin f views Structure f viewpints Viewpints fr PinkRccade Lcal Gvernment Chapter 5 Views Intrductin Aggregatin and abstractin level Views f PinkRccade Lcal Gvernment Chapter 6 Summary and recmmendatins Summary Recmmendatins References Page 6 f 90

7 Appendix A Architectural Maturity Mdel A.1 Intrductin t AMM cncept A.2 Results f NASCIO maturity assessment Appendix B Architectural descriptins B.1 Purpses f architectural dcumentatin B.2 IEEE Standard B.3 Architectural descriptin as rganizatinal knwledge Appendix C NORA C.1 Reference mdel C.2 Metamdel and Principles Appendix D Requirements and cncerns f stakehlders Appendix E Architectural mdels Appendix F Aggregatin and abstractin level Appendix G Functinal view Appendix H Applicatin prcess view Appendix I Cmmunicatin view Page 7 f 90

8 Chapter 1 Cmpany Intrductin First a general intrductin and a brief review f PinkRccade Lcal Gvernment s histry will be presented in sectin 1.1. In the next sectin the prduct characteristics f PRLG are elabrated. Sectin 1.3 cntains infrmatin abut the market characteristics f PRLG. Sectin 1.4 describes the current sftware prduct line f PinkRccade Lcal Gvernment, including a histry verview. In sectin 1.5 the architectural maturity f the rganizatin is examined. 1.1 Histry f PinkRccade Lcal Gvernment PinkRccade Lcal Gvernment (abbreviated as PRLG) is a Dutch rganizatin with its headquarter in Eindhven. The rganizatin was set up in PRLG is specialized in the field f ICT fr lcal gvernments. Their main fcus is n develping, implementing and maintaining dmain-specific sftware slutins fr lcal gvernments in the Netherlands. Besides the develped sftware prducts, PRLG als ffers several services supprting the ICT prcess at lcal gvernments, fr example help desk services, caching and training. PinkRccade Lcal Gvernment has a histry f mre than half a century in the Dutch ICT market, and several name changes have ccurred during this time. The cmpany s riginal name in 1950 was Rijkscentrale Mechanische Administratie (RMA). This was a gvernmental initiative t supprt administrative activities fr ministries and gvernmental institutins. In 1969, the RMA was renamed t Rijks Cmputer Centrum (RCC), and the range f duties was expanded t supplying services fr autmatic data prcessing/handling fr gvernmental institutins. In 1990 the Rijks Cmputer Centrum (RCC) became independent f the gvernment and expanded their range f prducts and services by taking ver the Maatschappij vr Infrmaticadiensten (general ICT service prvider) and Instituut vr Enquêteverwerking (institute fr handling surveys). Five years later the name changed int Rccade Infrmatica Grep. In 1999, the cmpany was quted n the Dutch stck exchange, Eurnext, and frm that pint it was renamed t PinkRccade. At the start f 2005, ICT service prvider Getrnics bught up almst all stcks f PinkRccade. The new cmpany, renamed t Getrnics PinkRccade, became the largest ICT service prvider f the Netherlands. Mst f the activities f the ld PinkRccade were accmmdated in ne f the subdivisin f the divisin Business Applicatin Services (BAS). This subdivisin was sld in February 2009 t the investment cmpany Ttal Specific Slutins (TSS), which renamed it t PinkRccade Lcal Gvernment, being the current name. In ttal ver 400 peple are currently (March 2010) emplyed at PRLG. Page 8 f 90

9 1.2 Prduct characteristics Lcal gvernments in the Netherlands need t cntrl administrative gvernmental prcesses. These prcesses are supprted by slutins develped by PinkRccade Lcal Gvernment. The cmpany als takes care f the implementatin and maintenance f the slutin. The business prcesses within fllwing dmains are supprted by slutins f PRLG: Public services (civil affairs, wrk, incme, and healthcare) Taxes and land registries Basic registratins (persns and addresses) Yuth welfare Educatin Data exchange with ther gvernmental institutins Business Intelligence Dcument management systems Financial and Human Resurce management fr lcal gvernment Next t the develpment, implementatin and maintenance f the slutins, several services are prvided t lcal gvernments. Examples f these services are: Help desk services Training Psting services where experienced emplyees f PRLG execute certain peratinal activities within the lcal gvernment Management Cnsultancy, e.g. caching f bard f directrs Infrastructural services Tailr-made sftware develpment PinkRccade Lcal Gvernment calls this the ne stp shp -thught; ne cmpany prviding all the necessary prducts and services fr a specific custmer. Regulatins and laws cncerning lcal gvernments are cnstantly subject t changes. The changes als influence the ICT structure and prcesses f lcal gvernments. Therefre, it is imprtant fr PRLG t wrk clsely tgether with plicymakers and their custmer, t effectively adapt the sftware slutins t externally enfrced changes. Page 9 f 90

10 1.3 Market characteristics PinkRccade Lcal Gvernment slely fcuses n lcal gvernments. This market cnsists f 441 lcal gvernments. Yearly, this number is subject t changes, because f the trend f smaller lcal gvernments merging int bigger cperatins and gvernmental institutins. In Octber 2009, 271 lcal gvernments are custmer f PinkRccade Lcal Gvernment. These lcal gvernments purchased at least ne f the slutins prvided by PRLG. The market share f PinkRccade Lcal Gvernment is therefre 61, 5 % f all lcal gvernments. Hwever, the ppulatin f the Netherlands is nt equally divided ver all lcal gvernments. Therefre, the amunt f citizens served by PRLG divided by the ttal amunt f citizens in the Netherlands gives a mre realistic idea f the market share: 60%. PinkRccade Lcal Gvernment has tw types f cmpetitrs: Cmpanies prviding slutins fr the prcesses f all dmains within lcal gvernments Cmpanies prviding slutins fr the prcesses f a certain dmain within lcal gvernments, fr example an educatinal slutin In the first categry there are three active cmpetitrs: Centric, GuwIT and Vicrea, with Centric being the cmpetitr with the largest market share f 75%, measured in the amunt f citizens served. The market share f PinkRccade Lcal Gvernment is quite stable. The cst f an implementatin f a cmpletely new IT system can rise t millins f Eurs. Therefre very few lcal gvernments decide t change t a cmpletely new system f a cmpetitr. The biggest market pprtunities fr PRLG arise frm: the crss and up sell f slutins t existing custmers the merging f smaller lcal gvernmental int ne bigger gvernmental institutin where a cllective IT system has t be cnsidered. Page 10 f 90

11 1.4 Sftware prduct line f PinkRccade Lcal Gvernment The first versin f the sftware system dates frm arund In these early days the sftware system was mainly purchased by lcal gvernments as a back-ffice sftware system supprting administrative prcesses at the cunters f the lcal gvernment ffices. The sftware system f PRLG has gne thrugh sme radical changes the last decades because f several reasns, the mst imprtant mentined belw: the changing business cntext (e.g. changes in administrative gvernmental prcesses, new laws and regulatins), the technical evlutin in the field f cmputer systems the rise f the internet (e.g., lcal gvernmental websites where gvernmental prcesses are supprted) expansin f the sftware system t ther gvernmental dmains and specific changes in the technical cntext f the sftware system (e.g. cmpliance with StUF (Standaard Uitwisselings Frmaat standardized cmmunicatin frmat fr gvernmental rganizatins)). The current sftware system is as a cmplex system, cnnecting multiple gvernmental rganizatins, supprting business prcesses f multiple dmains within the gvernmental cntext and servicing multiple custmer channels (e.g. cunters at lcal gvernment ffices, lcal gvernmental websites, and persnal internet prtals fr citizens). The sftware system f PinkRccade Lcal Gvernment cnsists f a prtfli f sftware slutins, and each sftware slutin cnsists f sftware prducts. Each sftware slutin addresses a specific dmain within the lcal gvernment, and each sftware prduct supprts gvernmental prcesses f a specific subdmain within that area. Fr example, the sftware slutin Taxes and land registries has a sftware prduct named CiVisin Belastingen Basis which supprts the basic gvernmental prcesses fr lcal taxes. All sftware prducts, which are mutually intercnnected, cnstitute the sftware system f PinkRccade. The sftware system f PinkRccade Lcal Gvernment can be defined as a sftware prduct line a set f sftware prducts that are develped frm a cmmn set f cre assets in a prescribed way [SEI, 2010]. PinkRccade Lcal Gvernment has named the sftware prduct line CiVisin. Frm a custmer s (lcal gvernment) pint f view, it is nt mandatry t purchase the cmplete sftware prduct line f PinkRccade Lcal Gvernment. A lcal gvernment can decide which sftware slutins t purchase, depending n their requirements. If a lcal gvernment decides t purchase a partial set f sftware slutins, it is pssible that certain functins f the slutin are unavailable because f interdependencies with ther sftware slutins. Page 11 f 90

12 1.5 Architectural maturity f PinkRccade Lcal Gvernment In the preceding sectin the sftware prduct line f PinkRccade Lcal Gvernment was intrduced. This sectin fcuses n the rganizatin f architectural prcesses and the architectural dcumentatin f the sftware system. The architectural maturity f PinkRccade Lcal Gvernment was examined in the preliminary stages f the prject. This assessment quantifies the quality f the current architectural prcesses and the underlying architectural prducts. The utcme f the assessment was used as pint f departure fr determining the next steps needed t imprve architectural maturity f the rganizatin. T structure the assessment the Architectural Maturity Mdel (AMM) cncept is intrduced. A few different methdlgies and maturity mdels exist in scientific literature under the name f Architectural Maturity Mdel. Fr the assessment f PinkRccade Lcal Gvernment the NASCIO Enterprise Architecture Maturity Mdel [NASCIO, 2003] was applied. The ratinale fr chsing this apprach is elabrated in appendix A. The NASCIO Enterprise Architecture Maturity Mdel distinguishes five general maturity levels. Each level cntains statements that are indicative f an architecture prgram at that level. Fr an verview f all the NASCIO levels refer t appendix A. During the preliminary stages f the prject several interviews were held with internal stakehlders f PinkRccade Lcal Gvernment. These stakehlders were asked what the current status f the architectural prcess was, t what extend the rganizatin was invlved in the architectural prcess, and in what maturity level the current rganizatin wuld best fit. Furthermre, the available architectural dcumentatin was examined n cmpleteness, cnsistency and frmality. Based n the interviews and the available architectural dcumentatin, PinkRccade was classified in maturity level 1 f the NASCIO Enterprise Architecture Maturity Mdel (see appendix A.2). Level 1 is characterized by architectural prcesses which are primarily ad hc and infrmal. Furthermre, the need fr mre frmal, cmplete and cnsistent architectural dcumentatin f the sftware prduct line has been identified, and there is a general cnsensus that steps twards architectural maturity need t be cnsidered [NASCIO, 2003]. Page 12 f 90

13 Chapter 2 Prject definitin In this chapter the thesis prject at PinkRccade Lcal Gvernment is defined. The first sectin describes the purpse f the prject. Sectin 2.2 discusses the prerequisites and limitatins f the prject. The structure f the thesis is described in sectin 2.3. The research apprach is presented in sectin Purpse f the prject and system definitin The utcme f the architecture maturity assessment in sectin 1.5 suggests that the architectural prcesses within PinkRccade Lcal Gvernment regarding their sftware system are primarily ad hc and infrmal. Furthermre, there is a general cnsensus that steps twards imprving architectural maturity t a sufficient level need t be cnsidered, and the need fr mre frmal, cmplete and cnsistent architectural dcumentatin has been identified. This need was underlined by the stakehlder interviews held during the preliminary stages f the study. Here, cncrete business cases f stakehlders presented themselves, emphasizing the need fr architectural dcumentatin (see appendix D). This architectural descriptin can be created thrugh a reverseengineering effrt (see appendix B fr mre infrmatin). Therefre, a master thesis prject was defined by PinkRccade Lcal Gvernment. The gal f this thesis was defined as the elabratin f the cre f the architectural descriptin fr the sftware prduct line f PinkRccade Lcal Gvernment. PRLG pursues a threefld purpse with this prject: Identificatin and definitin f architectural viewpints by taking the requirements and cncerns f a selected grup f internal stakehlders int accunt Elabratin f these architectural viewpints int views with cncrete architectural mdels Descriptin f the research apprach twards selectin f the architectural viewpints and the creatin f the views. Appendix B cntains mre infrmatin regarding the subject f architectural descriptins. The sftware system f PinkRccade Lcal Gvernment, which is mdeled in the architectural descriptin, has t be defined unambiguusly. As described in sectin 1.4, the sftware prduct line f PinkRccade Lcal Gvernment cnsists f a prtfli f sftware slutins, and each sftware slutin cnsists f sftware prducts. The sftware system f PinkRccade Lcal Gvernment, which is subject f the architectural descriptin, is therefre defined as an implementatin f the whle sftware prduct line at a lcal gvernment. This way it is pssible t map the relatinships between all sftware slutins and the system s envirnment. In the remainder f this thesis the terms sftware prduct line and sftware system are used interchangeably. Page 13 f 90

14 2.2 Limitatins and prerequisites f the prject There are tw limitatins established by PinkRccade Lcal Gvernment regarding this prject: PinkRccade Lcal Gvernment requested that the fcus f the architectural descriptin is initially n internal use - Therefre, the grup f architectural stakehlders is limited t internal stakehlders f PinkRccade Lcal Gvernment. This des nt mean that external stakehlders are nt relevant, but they fall utside the scpe f this prject (see als sectin 6.2). PinkRccade Lcal Gvernment indicated that the fcus f the architectural descriptin shuld primarily be n dcumenting the business and cnceptual architecture aspects f the sftware system - In ther wrds, the gal f the prject is t gain insight int the system structure, embdied in its cmpnents, their relatinships t each ther plus the envirnment, and gain insight int the business prcesses at lcal gvernments and the sftware system s rle in these prcesses. The functinal and cnstructinal architecture f the technlgy infrastructure f the system are, due t time limitatins, nt in the scpe f this prject and are nt dcumented. A prerequisite f the prject is that the architectural descriptin must be cmpliant with the NORA 2.0 standards [NORA 2.0, 2007]. Since the sftware prduct line f PinkRccade is supprting administrative prcesses at lcal Dutch gvernments, it has t be cmpliant with certain prcedures and regulatins enfrced by the Dutch gvernment. NORA 2.0 is an abbreviatin fr Nederlandse Overheid Referentie Architectuur 2.0 ( Dutch gvernmental reference architecture ). It signifies a dcument which cntains principles, mdels and standards fr the design and the rganizatin f the e-gvernment. The fcus f NORA 2.0 is supprting cllabratin between gvernmental institutins. Mre infrmatin n the mdels and principles behind NORA 2.0 can be fund in appendix C. Page 14 f 90

15 2.3 Thesis structure Chapter 3 t 5 recrd the architectural descriptin. The architectural descriptin f PinkRccade Lcal Gvernment is presented in the architectural descriptin frmat as defined by the IEEE standard. The IEEE standard recmmends including five elements in the architectural descriptin: 1. Identificatin f stakehlders and cncerns: The architectural descriptin must identify the stakehlders and their cncerns. Examples f cncerns are purpse, apprpriateness, feasibility and risks. 2. Selectin f architectural viewpints: The descriptin must identify the viewpints which are used. Furthermre the ratinale fr their selectin must be explained and each viewpint must be linked t the apprpriate cncerns f the stakehlders. The mdeling language is als defined in the viewpint. 3. Architectural views: The architectural descriptin must include multiple views, where each view crrespnds t nly ne viewpint. Each view cntains a single mdel r multiple architectural mdels. 4. Cnsistency amng architectural views: The descriptin must cntain an analysis f cnsistency acrss all f its architectural views, and any incnsistencies must be recrded. 5. Architectural ratinale: The descriptin must include the ratinale fr the architectural cncepts and decisins selected. Furthermre it must prvide evidence f the cnsideratin f alternative architectural cncepts and the ratinale fr the chices made. Kruchten et al. [2009] state that there are several benefits f using design ratinales in architecture. Hwever, the gal f this prject is nt t create a cmplete architectural descriptin (see sectin 2.1). The last element, architectural ratinale, will therefre nt be elabrated. This element recrds the ratinale behind key architectural decisins during the design f the system made by the respnsible architect(s) [Maier et al., 2001]. As nted by Kruchten et al. [2009] this infrmatin is really imprtant t recrd, but des nt fall within the scpe f this prject. Besides the architectural ratinale, the ther recmmended elements fr the architectural descriptin are cvered by the thesis. The chapter utline is: Chapter 3 Identificatin f stakehlders and cncerns Chapter 4 Selectin f architectural viewpints Chapter 5 Architectural views and cnsistency amng these architectural views Page 15 f 90

16 2.4 Research apprach This sectin cntains a shrt summary f the research apprach which resulted in the architectural dcumentatin n the sftware prduct line f PinkRccade Lcal Gvernment. Step 1 - Stakehlder selectin: In the first step the apprpriate amunt f stakehlders fr the prject was determined and specific internal stakehlder were selected t actively participate in creating the architectural descriptin. A mre extensive descriptin f this prcess step can be fund in sectin 3.1. Step 2 Stakehlder interviews: The selected stakehlders were interviewed individually by the researcher. The gal f these interviews was t recrd the requirements and the cncerns f the stakehlders regarding the architectural descriptin f the sftware prduct line. A mre extensive descriptin f this prcess step can be fund in sectin 3.2. Step 3 First selectin f viewpints and first versin f views: After the stakehlder interviews, the first set f viewpints was selected, and the underlying views were elabrated. The viewpints and views (which cnsist f architectural mdels) were created in parallel. A mre extensive descriptin f this prcess step can be fund in sectin Step 4 Evaluatin f viewpints and views: After the selectin f the first set f viewpints and the creatin f the related views, a frmal evaluatin tk place. The frmal evaluatin cnsisted f tw parts: a frmal presentatin t the Architectuur vakgrep and stakehlder evaluatin meetings. A mre extensive descriptin f this prcess step can be fund in sectin Step 5 Creatin f final versin f viewpints and views: The insights gathered during the evaluatin were used t evaluate the selectin f viewpints and t shape the views int their final versin. A mre extensive descriptin f this prcess step can be fund in sectin Page 16 f 90

17 Chapter 3 Identificatin f stakehlders and cncerns The sftware system f PinkRccade Lcal Gvernment affects many peple inside and utside the rganizatin. The users f the system are, fr example, a grup which is influenced by the system. Hwever, besides users many ther grups exist which are als affected by the system: develpers f the system, maintainers f the system, testers f the system, etc. All these grups can be defined as stakehlders f the system. In the IEEE Standard the cncept f an architectural stakehlder is explained as an individual, team, r rganizatin with interests in, r cncerns relative t a system. The first step twards creating the architectural descriptin is identifying a selectin f stakehlders wh will be prviding input fr the architectural descriptin. Sectin 3.1 cntains a descriptin f the prcess f selecting stakehlders. Once the selectin had been made, the stakehlders were frmally interviewed fr the first time. The structure f these interviews is cvered in sectin 3.2. During the interviews the stakehlders requirements and cncerns with regard t the system and its architectural descriptin were recrded. Sectin 3.3 presents the results f the interviews. These requirements and cncerns are the starting pint fr the creatin f architectural viewpints which is cvered in chapter Prcess f selecting stakehlders The prcess f selecting the right stakehlders fr input n the architectural dcumentatin was a difficult task. As stated by Rzanski and Wds [2005], ppulating the cmmunity f stakehlders is a subjective activity. The apprpriate amunt f stakehlders fr the research must be determined, and imprtant stakehlders shuld nt be verlked. In this study seven stakehlders were selected as representatives. This number was chsen in dialgue with the master architect at PinkRccade Lcal Gvernment. A larger amunt f stakehlders culd have been selected; the chances f delivering a successful architectural prduct are better, when the size f the stakehlder grup is extended [Rzanski and Wds, 2005]. Hwever, due t time cnstraints this was nt pssible in this research. A larger stakehlder grup implies that mre time is needed t actively invlve all individuals. S chsing the amunt f stakehlders leads t a trade-ff, and a larger set f stakehlder did nt seem feasible, cnsidering the shrt time span f the research. The prcess f selecting the apprpriate stakehlders was executed tgether with the master architect. The grup f ptential architectural stakehlders was limited t internal stakehlders nly. Furthermre, the dcumentatin n the technical infrastructure was ut f the scpe f this study. In accrdance with these limitatins, stakehlders interested in the technical infrastructure and external stakehlders were excluded. The stakehlders were selected based n their individual qualities. Leading qualities in the selectin were the dmain knwledge f the stakehlder, mtivatin, and ability t prduce requirements fr the architectural descriptin. Page 17 f 90

18 In ttal seven stakehlders were selected as representatives, with five different rganizatinal rles: Master architect Dmain architects (2 stakehlders) Business Managers (2 stakehlders) Designer Sales representative The tw additinal representatives fr the dmain architect and business manager rles were invited because f their ptentially valuable cntributin in the identificatin f stakehlder cncerns. T assure that n imprtant stakehlders were verlked, the classificatin f stakehlder grups by Rzanski and Wds [2005] was used. This classificatin enumerates the ptential architectural stakehlders accrding t their rles and cncerns. The relative imprtance f each stakehlder class will vary frm prject t prject, but it gives a general idea f the stakehlders f a sftware system. The stakehlder classes and their descriptin are listed in table 3.1 (the riginal classificatin by Rzanski and Wds cntains external stakehlders, which are irrelevant fr this research and thus remved frm this verview). Stakehlder Class Acquirers Assessrs Cmmunicatrs Develpers Maintainers Supprt staff System administratrs Testers Descriptin Oversee the prcurement f the system r prduct Oversee the system s cnfrmance t standards and legal regulatin Explain the system t ther stakehlders via its dcumentatin and training materials Cnstruct and deply the system frm specificatins (r lead the team that d this) Manage the evlutin f the system nce it is peratinal Prvide supprt t users fr the prduct r system when it is running Run the system nce it has been deplyed Test the system t ensure it is suitable fr use Table 3.1 A classificatin f stakehlders [Rzanski and Wds, 2005] Within PinkRccade Lcal Gvernment the names f the rganizatinal rles are smewhat different frm the classificatin f Rzanski and Wds. Hwever, by mapping the rganizatinal rles f the selected stakehlders nt the classificatin it can be determined whether imprtant stakehlder classes are verlked. As shwn in table 3.2, tw stakehlder classes are nt cvered, i.e. assessrs and testers, but in dialgue with the master architect it was determined that these classes are nt relevant fr this prject. Stakehlder Class Organizatinal rle Acquirers Sales representatives Assessrs Cmmunicatrs Sales representatives, Dmain architects, Business managers Develpers Master architect, Dmain architects, Designer Maintainers Designers Supprt staff Designers (2 nd line supprt) System administratrs Designers Testers Table 3.2 Mapping f rganizatinal rles nt the stakehlder classes f Rzanski and Wds Page 18 f 90

19 3.2 - Structure f the interviews After the selectin f stakehlders, the next step was interviewing these stakehlders. The main gal f the interviews was t recrd the requirements and the cncerns f the stakehlders regarding the architectural descriptin f the sftware prduct line. The selected stakehlders were interviewed individually during a frmal sessin with the researcher. During these sessins the requirements f the stakehlder were analyzed by asking questins related t wrk situatins where an architectural descriptin culd add value. The utcme f these interviews was recrded. Furthermre, the stakehlders were asked what mdeling technique wuld best fit their needs. Hwever, nt all stakehlders were familiar with the subject f architectural descriptin. T supprt them several mdels f familiar architectural framewrks were shwn during the sessins, i.e. Kruchten s 4+1 view mdel [Kruchten, 1995]. These were used t crystallize the stakehlder s ideas int cncrete mdeling cncepts. 3.3 Stakehlder requirements and cncerns This sectin cntains the requirements and cncerns which were recrded during the interviews with the stakehlders. These requirements and cncerns are the starting pint fr the selectin f the architectural viewpints. Belw, the requirements per stakehlder rle are enumerated. Since the dmain architect and business manager rles are represented by tw stakehlders, their requirements are cmbined in ne table. Refer t Appendix D fr detailed infrmatin n all the requirements. Frm a structural pint f view, each requirement is numbered using tw figures: X.Y X being the number assigned t the stakehlder rle and Y being the rdering number f the requirements per stakehlder rle. This way the reference t the requirements is simplified. If a stakehlder indicated a preferred mdeling technique fr a specific requirement, this is als dented. Stakehlder 1: Master Architect N. Requirement: 1.1 Dcumentatin fr new emplyees t familiarize with system and prcess 1.2 Gain detailed insight int hw sftware cmpnents are intercnnected 1.3 Dcumentatin f system architecture if key persns leave cmpany Table 3.3 Requirements f Master Architect Stakehlder 2: Dmain Architects N. Requirement: 2.1 Gain insight int interfaces f a sftware cmpnent 2.2 Gain detailed insight int hw sftware cmpnents are intercnnected 2.3 Descriptin f dmain specific prcesses at custmer 2.4 Overview f underlying data elements (per dmain) Table 3.4 Requirements f Dmain Architects Preferred mdeling technique Preferred mdeling technique Stakehlder 3: Business Managers N. Requirement: Preferred mdeling technique 3.1 Gain high-level insight n cnnectins between sftware cmpnents 3.2 Dcumentatin f prcess wrkflw at custmer UML Activity Diagrams 3.3 Overview f cntributin f system t prcesses at custmer Table 3.5 Requirements f Business Managers Page 19 f 90

20 Stakehlder 4: Designer N. Requirement: Preferred mdeling technique 4.1 Insight int the runtime behavir f the system (in time) UML Sequence Diagrams 4.2 Overview f underlying data elements/classes UML Class Diagrams 4.3 Gain insight int interfaces f a sftware cmpnent Table 3.6 Requirements f Designer Stakehlder 5: Sales Representative N. Requirement: 5.1 Which custmer prcesses are supprted by the system f PRLG 5.2 Dcumentatin n hw the prcesses are supprted by the system 5.3 Mapping f system elements int NORA system ntatin Table 3.7 Requirements f Sales Representative Preferred mdeling technique Page 20 f 90

21 Chapter 4 Viewpints In sectin 3.3 the requirements and the cncerns f the system stakehlder at PinkRccade Lcal Gvernment have been elabrated. These requirements and cncerns are the input fr the selectin and definitin f the viewpints. Fllwing the cnceptual framewrk f the IEEE standard (appendix B), an architectural descriptin is rganized int ne r mre architectural views. Each view addresses ne r mre cncerns f the stakehlders and represents ne r mre structural aspects f the sftware prduct line. The cnventins by which a view is created and depicted is recrded in a viewpint. The viewpint determines the mdeling language, the ntatins and the set f stakehlders fr whm the viewpint is relevant. Viewpints are the subject f this chapter. In sectin 4.1 the selectin prcess f the viewpints, and the prcess twards creatin f the assciated views is described. The structure f the viewpints is described in sectin 4.2, and sectin 4.3 presents the results f this prcess an verview f the selected viewpints. The assciated views are elabrated in chapter Prcess f viewpint selectin and creatin f views The selectin and definitin f the architectural viewpints and the elabratin f the assciating views was an iterative prcess, visualized in figure 4.1. The first step was acquiring the requirements and cncerns f stakehlders, which was presented in chapter 3. The next step cnsists f tw activities which were executed in parallel; the first selectin f viewpints and creatin f the first versin f the views. This step is presented in sectin This step is fllwed by a frmal evaluatin and the final selectin and definitin f the viewpints and the elabratin f the final versin f the assciated views, which are bth elabrated in sectin Final versin f viewpints and mdels Evaluatin by stakehlders First versin f viewpints and mdels Interactin with stakehlders 1st cycle 2nd cycle Figure 4.1 The iterative prcess f creating the viewpints and mdels Page 21 f 90

22 4.1.1 First selectin f viewpints During the creatin, the stakehlders were asked t prvide feedback n the wrk in prgress. This happened in an infrmal manner, mainly with the team f architects. This feedback was used t change the viewpint selectin and alter the assciated mdels, thereby supprting the requirements f the stakehlders. During the selectin and definitin f the architectural viewpints the fllwing elements were taken int accunt: Stakehlders requirements and cncerns - Imprtant input fr the viewpints are the requirements and cncerns f the stakehlder. NORA Since the custmers f PinkRccade Lcal Gvernment are gvernmental institutins, the sftware system has t be cmpliant with prescribed regulatins and laws. These guiding principles n gvernmental sftware systems and their architecture are primarily dcumented in NORA 2.0 (see als appendix C). These regulatins als affect the architectural dcumentatin and the underlying viewpints. Therefre PinkRccade Lcal Gvernment requested that the viewpints shuld be cmpliant with the NORA 2.0 framewrk. Literature - The last element, which was taken int accunt while selecting and defining the viewpints, is the set f viewpints defined in literature, s called library viewpints. A library viewpint is a viewpint has already been defined in literature. These existing viewpints were used as reference surces f inspiratin fr the definitin f the viewpints fr PinkRccade Lcal Gvernment Evaluatin by stakehlders and final versin f viewpints and views After selecting the first set f viewpints and cmpleting the first versin f the views, a frmal evaluatin tk place. The frmal evaluatin cnsisted f tw parts: 1. Frmal presentatin t the Architectuur vakgrep (Architecture wrking grup) f PinkRccade Lcal Gvernment, cnsisting f architects and designers 2. Stakehlder evaluatin meetings The gal f the frmal presentatin was t receive feedback n the first versin f the viewpints and views by the grup f architectural experts within the Architecture wrking grup. During the presentatin all viewpints and underlying mdels were presented and later n discussed by the attending representatives f the Architecture wrking grup. This feedback was afterwards incrprated in the final versin f the viewpints and mdels. Hwever, as Rzanski and Wds [2005] state, the frmal presentatin allws limited amunt f analysis f the viewpints and views. Therefre it is recmmended that it is used in cnjunctin with a mre sphisticated evaluatin technique t achieve an effective verall evaluatin. That is why stakehlder evaluatin meetings were planned t present the first versin f the viewpints and mdels t the stakehlders individually. Rzanski and Wds [2005] call this methd a structured walkthrugh. The cncept behind this methd is t assess the dcumentatin in detail by stepping thrugh stakehlder scenaris, and thereby validating the added value f the architectural dcumentatin. Advantage f this methd is that participants are mre deeply invlved cmpared t a frmal presentatin. This can lead t mre valuable insights. These insights were used t select the final set f viewpints and t shape the assciated views int their final versin. Page 22 f 90

23 4.2 Structure f viewpints Befre the selected architectural viewpints are presented, the structure f the viewpints has t be defined. The elements which are recrded per viewpint are intrduced in this sectin. In this thesis the selected viewpints fr PinkRccade Lcal Gvernment will be presented by using the fllwing elements [IEEE ]: Viewpint name A descriptive name assigned t the viewpints t be able t distinguish them frm each ther. By lking at the name, the reader shuld get a rugh idea what the viewpint represents. Stakehlders addressed by the viewpint This element lists the stakehlders wh have certain requirements and/r cncerns which are addressed by the viewpint. This list is limited t the selected stakehlders but the viewpint culd ptentially be useful fr ther stakehlders within the rganizatin as well. Requirements/cncerns addressed by viewpint This element lists the requirements and/r cncerns which are addressed by the viewpint Language and mdeling techniques A descriptin f the language and mdeling techniques which are applied in the viewpint Library Viewpint When fllwing the recmmended practice this element describes the surce f the library viewpints. Hwever, the set f viewpints fr PinkRccade Lcal Gvernment were defined primarily based n the stakehlder cncerns, and the pre-defined viewpints frm existing publicatins were mainly used as a surce f inspiratin. Therefre, the final set f viewpints was mapped in retrspect t tw existing viewpint libraries; the ArchiMate framewrk [The Open Grup, 2009] and the viewpint library f Rzanski and Wds [2005]. This sectin presents the existing viewpints frm the viewpint libraries n which the viewpint was mapped. Nte that this mapping is purely cnceptual (ntatins differ significantly) and t a great extent nly partial. Ratinale fr selectin f viewpint Fr each viewpint a ratinale shuld be given fr its selectin. Page 23 f 90

24 4.3 Viewpints fr PinkRccade Lcal Gvernment The first sectin presents a mapping f all the viewpints nt the NORA 2.0 metamdel and cntains a general nte with regard t the viewpints. The remaining sectins (4.3.2 up t ) cntain the definitin f the individual viewpints Overview f viewpints In figure 4.2 the selected set f viewpints is mapped n the NORA 2.0 metamdel. The NORA 2.0 metamdel is ne f the elements within the NORA 2.0 guidelines [NORA 2.0, 2007] and is a framewrk fr architecture design which defines nine viewpints. The metamdel is presented in appendix C. Since the technical infrastructure f the sftware prduct line is ut f the scpe, the technical layer f the NORA 2.0 metamdel des nt cntain any viewpints. Figure 4.2 The viewpints mapped nt the NORA 2.0 metamdel Befre the elabratin f the individual viewpints is presented, the fllwing pint shuld nt pass unnticed. The viewpints were defined in a platfrm-independent way. This means that n specific architectural platfrm was taken int accunt when mdeling the viewpints. In the present situatin f PinkRccade Lcal Gvernment, tw architectural mdeling platfrms are used within the rganizatin: Brland Suite and Aris 7.0. In this thesis, the viewpints were defined thrugh standard mdeling languages (i.e. UML) such that it is pssible t create the mdels in bth platfrms r t mdify them int a supprted ntatin. The mdeling tk place in the Micrsft Visi envirnment, which can be used t create standalne mdels. This way applicatin f a certain platfrm is nt frced upn the rganizatin and the chice f platfrm rests with PinkRccade Lcal Gvernment. Page 24 f 90

25 The viewpints are elabrated in the fllwing rder in the upcming sectins: Functinal viewpint Interface viewpint Custmer rganizatinal viewpint Custmer services viewpint Business prcess viewpint Applicatin prcess viewpint Cmmunicatin viewpint Data viewpint NORA viewpint Functinal viewpint Name: Functinal viewpint Stakehlders addressed by the viewpint: Master Architect (1) Dmain architects (2) Business Managers (3) Requirements/cncerns addressed by viewpint: N. Requirement/Cncern 1.1 Dcumentatin fr new emplyees t familiarize with system and prcess 1.2, 2.2 Gain detailed insight int hw sftware cmpnents are intercnnected 3.1 Gain high-level insight n cnnectins between sftware cmpnents Language and mdeling techniques: The ntatin used in this viewpint is the bxes-and-lines diagram. This ntatin type shws the functinal elements (bxes) which are cnnected t each ther by cnnectrs (lines). In essence, the ntatin cntains the fllwing elements: Functinal elements A functinal element is (a part f) a system with interfaces which make it pssible t interact with ther functinal elements. External entities External entities are entities within the cntext f the sftware system, fr example ther gvernmental systems r frnt-ffice elements frm partners. Cnnectrs The elements within the functinal viewpint which link the elements (functinal elements and/r external entities) tgether s that interactin is pssible. These three elements are elabrated in the fllwing sectins. Functinal elements PinkRccade Lcal Gvernment has a specific terminlgy cncerning the naming f system elements, which is adpted in this viewpint. The system elements which are distinguished by PinkRccade Lcal Gvernment are listed belw. The system element ffice is n the highest Page 25 f 90

26 aggregatin level. In ther wrds, the ffice element is cmpsed f ther system elements n a lwer aggregatin level, e.g. slutins and prducts. On the ther side f the spectrum, the cde element is n the lwest aggregatin level and cannt be decmpsed int ther system elements. Mre infrmatin n aggregatin levels is available in appendix F. Office Slutin Prduct Mdule Functin Cde In this viewpint the system is mdeled in ffices, slutins, prducts and mdules and is nt decmpsed int functins and cde. This level f mdeling is t detailed fr the scpe f this study. The ntatin f the system elements is visualized in figure 4.3. Figure 4.3 Ntatin f system elements Furthermre, the standard NORA 2.0 clr scheme is used in this viewpint t distinguish the system elements belnging t the fllwing categries: Frnt-ffice Mid-ffice Back-ffice Synchrnizatin and rutering In the standard NORA 2.0 clr scheme n specific clr has been assigned t external entities. Furthermre, the sftware PinkRccade Lcal Gvernment depends internally n a basic layer named Basisvrzieningen. This layer des nt fit in ne f the categries mentined abve. Therefre, the clr scheme is extended with tw clrs fr external entities and the basic layer. Figure 4.4 shws the extended clr scheme. Figure 4.4 Extended clr scheme If an architectural mdel is fcused n the direct relatins f ne specific functinal element, this element is shaded. Figure 4.5 shws an example f such a functinal element. Page 26 f 90

27 Figure 4.5 An example f a shaded element External entities The scpe f the research is the sftware system f PinkRccade Lcal Gvernment and its cntextual envirnment. Whether functinal elements within the sftware system interact with external entities is relevant fr this viewpint. The structure f the external entity, hwever, is nt relevant and the elements will nt be decmpsed in this viewpint. An external entity can be recgnized in the mdel by a pink hexagn. The external entities are classified in three categries: Landelijke Basisregistraties, Verwijsindexen and Ketenpartners. Figure 4.6 shws the ntatin f an external entity and its categrizatin. Figure 4.6 Ntatin f external entities Cnnectrs The cnnectrs make it pssible t link elements (functinal elements and/r external entities), thrugh which interactin is pssible. Cnnectrs are nted as arrws. In case f a single-headed arrw, the directin f the arrwhead determines in which directin the unilateral interactin takes place. In case f a tw-headed arrw, the cmmunicatin is bilateral. The arrw can depict the textual descriptin f the relatinship (anntatin) depending n the level f abstractin f the mdel. If an arrw is cnnected t a hierarchical element which cnsists f multiple sub-elements, all sub-elements can play a rle in the interactin. The reasn fr nt elabrating all the pssible cnnectins is readability f the mdel. If all pssible cnnectins were visualized, the mdel will becme almst impssible t read and understand. Therefre, ptential interactin between subelements is abstracted t ne single arrw. See figure 4.7 fr an example. Ketenpartners IB Grep CiVisin Maatschappelijke Ondersteuning CAK Zrgaanbieders Indicatiestellingsrgaan Figure 4.7 Ptential interactin between sub-elements abstracted t ne single arrw Page 27 f 90

28 Mdel technique In the functinal viewpint three different types f mdels can be distinguished, each type f mdel having a different aggregatin level. Each mdel belngs t ne f the fllwing mdeling types: Prduct verview In this single mdel the whle sftware system and its cntext are visualized up t prduct level. All pssible cnnectrs between elements (functinal elements r external entities) are depicted, but nt textually described due t the readability f the mdel. Prduct fcus In this type f mdel the fcus is n the direct relatins f ne individual prduct with ther prducts r external entities. The mdel zms in n an individual prduct and visualizes nly the ther prducts r external entities with which it is cnnected, including the crrespnding cnnectrs. All ther elements are suppressed. Mdule fcus - In this type f mdel the fcus is n the direct relatins f ne individual mdule with ther mdules r external entities. The mdel zms in n ne individual mdule and visualizes nly the ther mdules r external entities with which it is cnnected, including the crrespnding cnnectrs. The interactin between the elements is textually described. All ther elements are suppressed. Library viewpint: Functinal viewpint [Rzanski and Wds, 2005], Applicatin c-peratin viewpint [The Open Grup, 2009] Ratinale fr selectin f viewpint: The viewpint is selected t visualize all pssible direct relatinships between system elements and its cntextual envirnment. The prduct verview mdel is a single mdel which gives an verview f the system. The prduct/mdule fcus mdels cncentrate n the direct relatinships f specific functinal elements. Up t this pint in time, this kind f visualizatin f relatinships was nt available at PinkRccade Lcal Gvernment. This viewpint makes familiarizatin with the system mre straightfrward fr new emplyees. Furthermre, stakehlders can gain high-level insight n the relatinships between cmpnents n the higher aggregatin level. If necessary, it is pssible t fcus n a specific system element and see its direct cnnectins t ther elements. By fcusing n specific system elements the mdel suppresses unnecessary detail (e.g. system elements which are nt directly related t the element at hand). Page 28 f 90

29 4.3.3 Interface viewpint Name: Interface viewpint Stakehlders addressed by the viewpint: Dmain Architects (2) Designer (4) Requirements/cncerns addressed by viewpint: N. Requirement/Cncern 2.1, 4.3 Gain insight int interfaces f a sftware cmpnent Language and mdeling techniques: The ntatin used in this viewpint is partly a bxes-and-lines diagram (similar t the functinal viewpint) and partly adpted frm UML 2.0 [Rumbaugh et al., 2005]. This ntatin type shws functinal elements and their prvided and required interfaces. The mdeling f functinal elements is similar t the functinal viewpint (sectin 4.3.3). The same ntatin and clr scheme is used fr system elements. T visualize the interfaces f a system element the lllipp ntatin is adpted frm UML 2.0. A small circle attached t an element represents a prvided interface. A prvided interface is a set f services made available by the functinal element. A small semicircle attached t an element represents a required interface. A required interface visualizes a need t btain a service frm anther element. An anntatin is added t the interface t describe the prvided/required service. Figure 4.8 shws the ntatin f prvided and required interfaces. Figure 4.8 Ntatin f prvided and required interfaces In this viewpint the fcus is n all interfaces f a specific functinal element in the system. (The interfaces f) system elements t which the specific element cnnects are suppressed in the ntatin t supprt readability. If necessary, a table culd be added where the interfaces are elabrated, see table 4.1 fr an example. Func. Element P(rvided)/ R(equired) Interface descr. Related funct. element MO- Klantkaart R Inzage zaakgegevens Werk - Basis MO- Zrg P AZR berichten Zrgaanbieder Table 4.1 Elabratin f the interfaces f an element Page 29 f 90

30 Mdel technique In the interface viewpint tw different types f mdels can be distinguished. Each mdel belngs t ne f the fllwing mdeling types: Black bx mdel The external interfaces f a specific functinal element are visualized including the element itself. The internal structure f the element is a black bx and is nt shwn. Glass bx mdel The external interfaces f a specific functinal element are visualized including the internal structure f the element itself. The internal structure f the element is cnstructed by sub-elements and internal interfaces. Library viewpint: Functinal viewpint [Rzanski and Wds, 2005], Applicatin structure viewpint [The Open Grup, 2009] Ratinale fr selectin f viewpint: Tw selected stakehlders indicate that there is a lack f insight int the interfaces f functinal cmpnents. There is n exhaustive dcumentatin n interfaces which are prvided r required by functinal elements. This viewpint makes visualizatin f functinal elements and their external interfaces pssible in an rderly manner. Furthermre, this viewpint shws the internal structure f the functinal elements in the glass bx mdels. Where the mdule fcus mdels in the functinal viewpint nly shw direct relatinships between a specific mdule and its directly related mdules, the interface viewpint visualizes the cmplete internal structure f a prduct. Page 30 f 90

31 4.3.4 Custmer rganizatinal viewpint Name: Custmer rganizatinal viewpint Stakehlders addressed by the viewpint: Business Managers (3) Sales Representative (5) Requirements/cncerns addressed by viewpint: N. Requirement/Cncern Language and mdeling techniques: The rganizatin chart is used t visualize the departments and rles within the rganizatin. The main gal f this viewpint is t present the lcal gvernmental rles. An example f an rganizatin chart is shwn in figure 4.9. Figure 4.9 Example f an rganizatin chart Library viewpint: Organizatin viewpint [The Open Grup, 2009] Page 31 f 90

32 Ratinale fr selectin f viewpint: Initially, during the stakehlder interviews, nne f the stakehlders required insight int the custmer rganizatin and its rganizatinal rles. That is the reasn why n requirement/cncern is listed abve. Hwever, during the evaluatin sessins, tw stakehlders (business manager and sales representative) indicated that they are interested in the rganizatinal psitin f the actrs in the custmer s business prcesses. The Business prcess viewpint, which is elabrated in sectin 4.3.7, describes the business prcesses at the custmer. These prcesses are executed by individuals emplyed by the lcal gvernment. These actrs in the business prcesses are fund in the swimming lanes f the UML activity diagram. In essence, the stakehlders require an rganizatinal verview f each actr that is invlved in ne f the business prcesses f the custmer. Fr example, in the business prcess Zrgaanvraag Huishudelijke hulp via E-frmulier there are tw lcal gvernmental rles invlved in the prcess; WMO-cnsulent and fiatteur. These tw rles shuld be psitined in the rganizatin chart. With the use f this viewpint, the rganizatinal psitin f each actr in the business prcesses can be determined. On the ther hand, ne can determine fr each rganizatinal rle in which business prcesses it is actively invlved. In case f rganizatinal change (e.g. remval f the rle WMO-cnsulent), it can easily be determined n which business prcesses this has an impact Custmer services viewpint Name: Custmer services viewpint Stakehlders addressed by the viewpint: Sales Representative (5) Requirements/cncerns addressed by viewpint: N. Requirement/Cncern 5.1 Which custmer prcesses are supprted by the system f PRLG Language and mdeling techniques: This viewpint lists all the gvernmental services which are prvided by the lcal gvernment and supprted by PinkRccade Lcal Gvernment s sftware system. The services are categrized per gvernmental dmain. Library viewpint: Business functin viewpint [The Open Grup, 2009] Ratinale fr selectin f viewpint: One f the requirements f the stakehlders is t gain insight in the custmer prcesses which are supprted by the sftware system f PinkRccade Lcal Gvernment (req. 5.1). This viewpint lists all gvernmental services where the sftware system f PRLG plays a rle and categrized them per dmain. Each f these gvernmental services is supprted by a specific business prcess which is elabrated in the Business prcess viewpint (sectin 4.3.7). The ratinale fr selecting this viewpint is twfld. First, this viewpint makes it pssible t determine per gvernmental dmain which prcesses are supprted by PinkRccade Lcal Gvernment. Page 32 f 90

33 Secndly, if these viewpints wuld be elabrated in an architectural platfrm like Aris 7.0, it wuld be pssible use this view as an verview f all supprted services, and it wuld be pssible fr the stakehlder t select the custmer service f interest and be directly referred t the business prcess mdel f that particular custmer service Business prcess viewpint Name: Business prcess viewpint Stakehlders addressed by viewpint: Master Architect (1) Dmain Architects (2) Business Managers (3) Sales Representative (5) Requirements/cncerns addressed by viewpint: N. Requirement/Cncern 1.1 Dcumentatin fr new emplyees t familiarize with system and prcess 2.3 Descriptin f dmain specific prcesses at custmer 3.2 Dcumentatin f prcess wrkflw at custmer 3.3 Overview f cntributin f system t prcesses at custmer 5.1 Which custmer prcesses are supprted by the system f PRLG 5.2 Dcumentatin n hw the prcesses are supprted by the system Language and mdeling techniques: The mdeling methd applied in this viewpint is UML Activity Diagrams. UML Activity Diagrams are cmmnly used fr business prcess mdeling. Refer t the UML Ntatin Guide [1997] fr the ntatin. System activity verlay Besides the UML Activity diagrams t mdel the business prcess a system activity verlay is applied. This verlay is used t underline the prcess steps (activity ndes) in the UML activity diagram in which the sftware system f PinkRccade Lcal Gvernment plays an active rle. These prcesses are called active subprcesses. Per activity diagram the active subprcesses are cded with capital letters in a chrnlgical way. The first active subprcess in chrnlgical rder is cded with capital letter A, the secnd subprcess with capital letter B, etc. Library viewpint: Business prcess viewpint and Applicatin usage viewpint [The Open Grup, 2009] Page 33 f 90

34 Ratinale fr selectin f viewpint: This viewpint makes it pssible fr stakehlders t gain insight in the custmers business prcess. Up t this pint in time PinkRccade Lcal Gvernment have made sme attempts t mdel the business prcesses f their custmers in UML Activity diagrams, but the mdels have nly been finished fr a few prcesses. Within this viewpint all business prcesses which supprt the gvernmental services (elabrated in the Sales view (sectin 4.3.6)) and are supprted by the sftware system shuld be mdeled. This way the prcess wrkflw at lcal gvernments is dcumented (req. 5.1). UML Activity diagrams were chsen as the mdeling language because f recent experience within PinkRccade Lcal Gvernment with this language. The system activity verlay helps t see in which steps the sftware system f PinkRccade Lcal Gvernment plays an active rle (req. 3.3 and 5.2). The dcumentatin can als be used t familiarize new emplyees f PinkRccade Lcal Gvernment with the existent prcesses at the custmer (req. 1.1) Applicatin prcess viewpint Name: Applicatin prcess viewpint Stakehlders addressed by the viewpint: Dmain Architects (2) Designer (4) Requirements/cncerns addressed by viewpint: N. Requirement/Cncern 2.3 Descriptin f dmain specific prcesses at custmer 4.1 Insight int the runtime behavir f the system (in time) Language and mdeling techniques: The mdeling methd applied in this viewpint is UML Sequence Diagrams. UML Sequence Diagrams are cmmnly used fr visualizing the sequencing f events and messages between system elements. Refer t the UML Ntatin Guide [1997] fr the ntatin. On tp f each lifeline the invlved system element is shwn. The name f the prduct is mentined first, fllwed by the name f the mdule (in italic) if applicable. The standard clr scheme f NORA 2.0 is used t clr these system elements. See figure 4.10 fr an example lifeline. Figure 4.10 An example f a lifeline Library viewpint: Applicatin usage viewpint and Applicatin behavir viewpint [The Open Grup, 2009], Cncurrency viewpint [Rzanski and Wds, 2005] Page 34 f 90

35 Ratinale fr selectin f viewpint: In the Business prcess viewpint active subprcesses are distinguished. These subprcesses are supprted by the sftware system f PinkRccade Lcal Gvernment. In this viewpint the active subprcesses are elabrated by using UML Sequence diagrams. This methd is used fr visualizing the sequencing f messages and events, and prvides distinct infrmatin regarding the time sequences f the messages. Therefre this mdeling language is useful t gain insight int the runtime behavir f the system (req. 4.1) Cmmunicatin viewpint Name: Cmmunicatin viewpint Stakehlders addressed by the viewpint: Master architect (1) Sales Representative (5) Requirements/cncerns addressed by viewpint: N. Requirement/Cncern 1.1 Dcumentatin fr new emplyees t familiarize with system and prcess 5.2 Dcumentatin n hw the prcesses are supprted by the system Language and mdeling techniques: The mdeling methd in this viewpint is adpted frm UML Cmmunicatin Diagrams. UML Cmmunicatin Diagrams are cmmnly used fr visualizing the sequencing f events and messages between system elements. In essence, these diagrams prvide the same infrmatin as UML Sequence diagrams, but they emphasize different aspects. UML Sequence diagrams prvide distinct visual infrmatin regarding the time sequences f the messages, where UML Cmmunicatin diagrams fcus n the relatinship amng the elements that exchange the message. Messages are shwn as labeled arrws. Each message has a sequence number which makes the time sequence f the messages readable. The sequence number starts with a capital letter indicating the active subprcess where this message is part f. This way it is pssible t mdel multiple active subprcesses in a single mdel while having the ability t distinguish the surce f the messages. The functinal elements are mdeled in the same way as in the Functinal viewpint (sectin 6.3.3). The standard clr scheme f NORA 2.0 is used t clr these system elements. Mdel technique In the cmmunicatin viewpint three different types f mdels can be distinguished. Each mdel belngs t ne f the fllwing mdeling types: Active subprcess This type f mdel shws the messages between system elements f ne specific active subprcess. Multiple active subprcesses This type f mdel shws the messages between system elements f multiple active subprcesses in ne single mdel. By using a capital letter t indicate which message belngs t which active subprcess, it is pssible t mdel multiple active subprcesses in a single mdel while having the ability t distinguish the surce f the messages. Page 35 f 90

36 Business prcess verview This type f mdel shws the messages between system elements f all active subprcesses within a certain business prcess (defined in Business prcess view, 6.3.7) This verview shws all the system elements which are actively invlved in the business prcess. Fr the sake f readability the labels n the arrws are suppressed. Library viewpint: Applicatin behavir viewpint [The Open Grup, 2009], Cncurrency viewpint [Rzanski and Wds, 2005] Ratinale fr selectin f viewpint: This viewpint visualizes the sequencing f messages and events while fcusing n the relatinships amng the elements. Cntrary t UML Sequence diagrams, the functinal elements are visualized using the same building blcks as in the Functinal viewpint. This imprves the readability f the mdels fr new emplyees wh want t get acquainted with the system behavir during prcess (req. 1.1). Furthermre, this mdeling technique is better suited fr stakehlder with a nn-technical backgrund, since it is mre understandable and easier t read than UML Sequence diagrams (req. 5.2) Data viewpint Name: Data viewpint Stakehlders addressed by the viewpint: Dmain architects (2) Designer (4) Requirements/cncerns addressed by viewpint: N. Requirement/Cncern 2.4 Overview f underlying data elements (per dmain) 4.2 Overview f underlying data elements/classes Language and mdeling techniques: The mdeling methd applied in this viewpint is UML Class Diagrams. UML Class Diagrams are used t visualize the data structure f a system by shwing the system s classes, their attributes, and the relatinship between the classes. Refer t the UML Ntatin Guide [1997] fr the ntatin. Library viewpint: Infrmatin structure viewpint [The Open Grup, 2009] Ratinale fr selectin f viewpint: Tw stakehlders at PinkRccade Lcal Gvernment indicated that a mdel was required which gives insight int the underlying data elements per dmain (req. 4.2). This requirement is addressed by this viewpint by mdeling the system s classes and their relatinships in a UML Class Diagram. Page 36 f 90

37 NORA viewpint Name: NORA viewpint Stakehlders addressed by viewpint: Sales Representative (5) Requirements/cncerns addressed by viewpint: N. Requirement/Cncern 5.3 Mapping f system elements int NORA system ntatin Language and mdeling techniques: Within PinkRccade Lcal Gvernment there is ne diagram which is widely used fr architectural purpses: Referentie architectuur egemeente. In essence, it is a simplificatin and an abstractin f the structure f a lcal gvernmental system and its envirnmental cntext. The elements within the diagram are named in a descriptive manner, and the specific prduct names f PinkRccade Lcal Gvernment are nt mentined. The diagram uses the NORA 2.0 clr scheme. Refer t appendix C fr mre infrmatin n this diagram. This diagram is included in the viewpint and the diagram s ntatin is used as the standard ntatin fr this viewpint. Besides this diagram, anther mdel is intrduced which replaces the element s descriptive names with cncrete prduct names f PinkRccade Lcal Gvernment. The ntatin remains unchanged. Library viewpint: Intrductry viewpint [The Open Grup, 2009] Ratinale fr selectin f viewpint: The mdeling methd used in this viewpint is widely accepted by emplyees f PinkRccade Lcal Gvernment. It is a diagram which is mstly used fr bth internal and external cmmunicatin abut the sftware architecture f gvernmental systems. In essence, it visualizes the functinal elements and the external entities f the sftware system similar t the Functinal viewpint, but it des nt include the relatinships between the elements. The viewpint is well suited fr cmmunicatinal purpses since the diagram shws nly the essential functinal elements and is therefre well-rganized and readable. One f the stakehlders requested the creatin f anther diagram where the descriptive names in the diagram are replaced by the prduct names f the sftware prduct line f PinkRccade Lcal Gvernment (req. 5.3). This mdel is included in this viewpint. Page 37 f 90

38 Chapter 5 Views Sectin 5.1 cntains an intrductin t this chapter. Sectin 5.2 intrduces the terms aggregatin and abstractin level as a way f structuring the mdels. Sectin 5.3 will intrduce the individual views f the architectural descriptin. The (in)cnsistencies amng the views are elabrated in sectin Intrductin The definitin by IEEE f a view states that it cnsists f ne r mre architectural mdels, which are elabrated using the methds established by its assciated architectural viewpint. Mre infrmatin regarding architectural mdels can be fund in appendix E. In this chapter the architectural views are elabrated. Hwever, the views d nt include all architectural mdels f the system f PinkRccade Lcal Gvernment. The final set f nine viewpints required elabratin f a substantial amunt f views (sme f them at several aggregatin levels). This was nt feasible within the prject scpe and as a result, nly high-level and intermediate views were elabrated fr a number f viewpints. These architectural mdels, which were created in cnfrmance with their assciated viewpint s cnventins, are presented in this chapter. Within mst views ne element f the dmain f Maatschappelijke Ondersteuning is elabrated and is mdeled using the viewpint s cnventins. 5.2 Aggregatin and abstractin level Fr the Functinal, Applicatin Prcess, Interface and Cmmunicatin view, the terms aggregatin level and abstractin level are included as a way f structuring the architectural mdels. Backgrund infrmatin regarding the aggregatin and abstractin level can be fund in appendix F. When using the aggregatin and abstractin levels, the reader can see at what level the mdel is situated. In many empirical cases a numbering methd is used t define the level f abstractin/aggregatin (level 1 is the highest level f aggregatin, etc.) Hwever, this methd can cause prblems [Bratthall and Runesn, 1999]. The rganizatin shuld define a set f literals which reflect the different aggregatin and abstractin levels. These sets f literals are called literal plug-ins [Bratthall and Runesn, 1999] Aggregatin level The aggregatin level refers t the degree in which an element in a mdel is cmpsed frm ther elements. The aggregatin level f the whle architectural mdel is determined by the mdeling element with the lwest aggregatin level in the mdel. Fr the architectural mdels f the views mentined abve the fllwing literal plug-in is used t determine the aggregatin level: <System, Slutin, Prduct, Mdule, Functin, Cde> Page 38 f 90

39 5.2.2 Abstractin level The abstractin level f a mdel refers t the degree in which the attributes f the elements and its relatinships are cncretized. In case f the views f PinkRccade Lcal Gvernment the cncreteness f the attributes f the elements is similar in all the mdels. Hwever, the cncreteness f the relatinships f the elements differs; the cnnectrs d r d nt have anntatins. Fr the architectural mdels f the views mentined abve the fllwing literal plug-in is used t determine the abstractin level f the relatinships (cnnectrs): <N anntatin, Anntatin> With regard t this thesis, it can be argued that the abstractin levels d nt really add value since the difference in abstractin per mdel is very limited. Hwever, this definitin is recrded in this thesis, since it des add value when the differences in abstractin becme mre apparent. Fr example, if a mdel shws data classes as an attribute f the relatinships between system elements, the literal plug-in culd becme: <N anntatin, Descriptive, Data classes>. Figure 5.1 shws hw the level f aggregatin and abstractin are added t the mdels. Figure 5.1 Visualizatin f aggregatin and abstractin level 5.3 Views f PinkRccade Lcal Gvernment The next sectins (5.3.1 up t 5.3.9) cntain the elabratin f the individual views. The views are presented in the same rder as the viewpints in chapter 4. As mentined in the preceding sectin nt all architectural mdels f the system f PinkRccade Lcal Gvernment are elabrated due t the limited time span f the prject. Table 5.1 shws which viewpints are elabrated int views, and t what extent. The table presents the views, the underlying mdeling types (if applicable), and the extent f elabratin f the view (cmplete elabratin, elabratin f example, partial elabratin f example, n elabratin). Page 39 f 90

40 Viewpint Functinal viewpint Interface viewpint Custmer rganizatinal viewpint Custmer services viewpint Business prcess viewpint Mdeling type Cmplete elabratin Elabratin f example Prduct verview X Prduct fcus X 1 Mdule fcus X 1 Black bx X 1 Glass bx X 1 Activity diagram X 2 System activity verlay X 2 Applicatin prcess viewpint X 2 Cmmunicatin viewpint Partial elabratin f example Active subprcess X 2 Multiple active subprcesses X 2 Business prcess verview X 2 Data viewpint X 3 NORA viewpint 1 CiVisin Maatschappelijke Ondersteuning (Prduct) 2 Zrgaanvraag via E-frmulier Huishudelijke hulp (Business prcess) 3 Zrg & Welzijn (Gvernmental dmain) Table 5.1 Extent f elabratin f viewpints X X N elabratin X Functinal view As defined in the Functinal viewpint (sectin 4.3.2), there are three types f mdels in this view: Prduct verview Prduct fcus Mdule fcus In this thesis the fllwing mdels are elabrated: Prduct verview mdel Prduct fcus mdel fr CiVisin Maatschappelijke ndersteuning Mdule fcus mdel fr CiVisin Maatschappelijke ndersteuning Fr each type f mdel an example is presented in this sectin. Please refer t appendix G fr all elabrated mdels f this architectural view. Figure 5.2 shws a prduct verview mdel, figure 5.3 shws a prduct fcus mdel f the CiVisin Maatschappelijke Ondersteuning prduct, and figure 5.4 shws a mdule fcus mdel f the Zrg mdule. Page 40 f 90

41 Figure Prduct verview mdel Figure Prduct fcus mdel Page 41 f 90

42 Figure Mdule fcus mdel Page 42 f 90

43 5.3.2 Interface view As defined in the Interface viewpint (sectin 4.3.3), there are tw types f mdels available in this view: Black bx mdel Glass bx mdel In this thesis the black bx mdel and the glass bx mdel f the Civisin Maatschappelijke Ondersteuning prduct are elabrated. Figure 5.5 shws a black bx mdel f the Civisin Maatschappelijke Ondersteuning prduct, and figure 5.6 shws a glass bx mdel f the same prduct. Figure 5.5 Black bx mdel f Civisin Maatschappelijke Ondersteuning Page 43 f 90

44 Figure 5.6 Glass bx mdel f Civisin Maatschappelijke Ondersteuning Custmer rganizatinal view N mdels fr this viewpint have been elabrated due t time limitatin f the prject and lack f availability f the necessary infrmatin Custmer services view This view lists the gvernmental services which are prvided by the lcal gvernment and supprted by PinkRccade Lcal Gvernment s sftware system. The services are categrized per gvernmental dmain. Figure 5.7 shws this listing f gvernmental services. Nte: The presented listings in nt exhaustive; nly the business prcesses which were knwn at the pint f time when the mdeling tk place, are listed. The ther remaining business prcesses are nt presented due t a lack f availability f the necessary infrmatin. Page 44 f 90

45 Figure Listing f gvernmental services Business prcess view As defined in the Business prcess viewpint (sectin 4.3.6), the custmer s business prcesses are mdeled using UML Activity diagrams. Furthermre a system activity verlay was intrduced t underline the prcess steps (activity ndes) in the UML activity diagram in which the sftware system f PinkRccade Lcal Gvernment plays an active rle. In this thesis the business prcess mdels fr the business prcess Zrgaanvraag huishudelijke hulp via E-frmulier are elabrated. Figure 5.8 shws the business prcess mdel and figure 5.9 presents the same mdel including the system activity verlay. Page 45 f 90

46 Figure 5.8 Business prcess mdel f Huishudelijke hulp via E-frmulier Page 46 f 90

47 Figure 5.9 Business prcess mdel f Huishudelijke hulp via E-frmulier with system activity verlay Page 47 f 90

48 5.3.6 Applicatin prcess view As defined in the Applicatin prcess viewpint (sectin 4.3.7), the message sequencing is mdeled using UML Sequence diagrams. In this thesis all active subprcesses frm the business prcess Zrgaanvraag - huishudelijke hulp via E-frmulier are elabrated. Figure 5.10 shws the applicatin prcess mdel f ne f the active subprcesses ( Intake zrgaanvraag ). Please refer t appendix H fr all elabrated mdels f this architectural view. Figure 5.10 Applicatin prcess mdel f active subprcess Intake zrgaanvraag Cmmunicatin view As defined in the Cmmunicatin viewpint (sectin 4.3.8), there are three types f mdels in this view: Active subprcess Multiple active subprcesses Business prcess verview In this thesis the active subprcesses f the business prcess Zrgaanvraag - huishudelijke hulp via E-frmulier are elabrated. Fr each f the three types f mdels an example is presented in this sectin. Figure 5.11 shws an active subprcess mdel, figure 5.12 shws a multiple active subprcess mdel, and figure 5.13 shws a business prcess verview mdel. Please refer t appendix I fr all elabrated mdels f this architectural view. Page 48 f 90

49 Figure Active subprcess mdel f subprcess Intake zrgaanvraag Figure Multiple active subprcess mdel f subprcess A, B and C Page 49 f 90

50 CiVisin Zaakafhandeling DigiD Basis CiVisin Makelaar Services Basis CiVisin Maatschappelijke Ondersteuning Zrg Ketenpartners Indicatiestellingsrgaan CAK Zrgaanbieder Basis PIP DMS Circle BCT Decs SAP CiVisin Middelen Basis Basis CiVisin Basis DMS TDI Frnt-Office Kppeling Mid-Office Back-Office Externe partij Mdule MO Basislaag View: Cmmunicatin view Name: Business prces verview Huishudelijke hulp via E-frmulier Figure Business prcess verview mdel f Huishudelijke hulp via E-frmulier Agg. level: Mdule Abs. level: N anntatin Data view As defined in the Data viewpint (sectin 4.3.9), the data structure f the system (the system s classes, their attributes, and the relatinship between the classes) is mdeled using UML Class diagrams. In this thesis the data structure f the dmain Zrg & Welzijn (Health care & Welfare) is partially elabrated based n the limited infrmatin available. Due t the limited time span f the prject it was nt pssible t elabrate the mdel exhaustively. The simplified data structure f the dmain Zrg & Welzijn is shwn in figure Page 50 f 90

51 Figure 5.14 Data structure f the dmain f Zrg & Welzijn NORA view As defined in the NORA viewpint (sectin ), there are tw types f mdels in this view. Bth share the same ntatin, which is adpted frm the Referentie architectuur egemeente diagram. The difference between bth types f mdels is that ne mdel has elements with descriptive names, and the ther has elements with cncrete prduct names. Due t the limited time span f the prject the NORA mdels have nt been exhaustively elabrated. Instead, tw mdels frm the Referentie Architectuur egemeente presentatin [Schijvenaars, 2008] have been used as an example. These mdels d nt represent all the prducts f PinkRccade Lcal Gvernment, which is advisable fr the final versin f these mdels. Figure 5.15 shws the mdel with descriptive names, and the mdel with cncrete prduct names f the sftware prduct line is presented in figure Page 51 f 90

52 Figure 5.15 Prduct view mdel with descriptive names [Schijvenaars, 2008] Figure 5.16 Prduct view mdel with cncrete prduct names [Schijvenaars, 2008] Page 52 f 90

53 5.4 Cnsistencies and incnsistencies amng views The IEEE standard states that an architectural descriptin shuld cntain an analysis f cnsistency acrss all f its architectural views. Furthermre, any knwn incnsistencies amng its architectural views shuld be recrded. Hwever, the standard des nt recmmend hw t cdify r express cnsistency [Emery and Hilliard, 2008]. These authrs therefre prpse the use f viewpint crrespndence rules t recrd a relatin between tw architectural viewpints. Fr the architectural descriptin f PinkRccade Lcal Gvernment, the fllwing viewpint crrespndence rules are frmulated (see als figure 5.17): Rule 1 Every gvernmental rle which is in the swim lanes f the UML activity diagram in the Business prcess view must be defined as a gvernmental rle in the Organizatinal view Rule 2 Every gvernmental service listed in the Sales view must be elabrated in the Business prcess view, and vice versa Rule 3 Every active subprcess defined in the Business prcess view must be elabrated in the Cmmunicatin view and the Applicatin prcess view Rule 4 Every relatinship which is mdeled in the Cmmunicatin view and the Applicatin prcess view must be mdeled in the Functinal view Rule 5 Every interface which is mdeled in the Interface view must be traceable t a crrespnding relatinship in the Functinal view Rule 6 Every prduct element mdeled in the Prduct view must crrespnd t a prduct element in the Functinal view despite the difference in ntatin Rule 7 The message sequence f every active subprcess must be mdeled in exactly the same sequence fr bth the Cmmunicatin as the Applicatin prcess view despite the difference in ntatin Rule 8 Every element in the Prduct view, Functinal view, Cmmunicatin view, Applicatin prcess view and Interface view is clred by using the NORA 2.0 clr scheme Rule 9 Every element in the Functinal view, Cmmunicatin view, Applicatin prcess view and Interface view uses the same system elements ntatin (as defined in sectin 4.3.2) Page 53 f 90

54 Figure 5.17 Viewpint crrespndence rules n architectural viewpints f PinkRccade Lcal Gvernment (rules 8 and 9 are nt mdeled) There are tw incnsistencies amng the views fr PinkRccade Lcal Gvernment that are recrded: The ntatin used in the Interface view t visualize relatinships (prvided/required interfaces) is different frm the ntatin used in the Functinal view and the Cmmunicatin view (cnnectrs). In essence, the prvided/required interfaces ntatin prvides mre infrmatin than cnnectrs since it determines which element prvides the service and which element requires the service. The justificatin fr this incnsistency is that in the Interface view the use f interface ntatin emphasizes which required interfaces and which prvided interfaces a certain element has. On the ther hand, this infrmatin was assumed t be less relevant fr the Functinal view and the Cmmunicatin view, and the use f the cnnectr ntatin makes the mdels mre readable. The Data view has n crrespndence t ther views at this stage. The reasn fr this is that the abstractin levels f the views besides the Data view are t high. The anntatins n the cnnectrs in the Functinal and Cmmunicatin view are nw purely descriptive. If, hwever, the anntatins f the cnnectrs becme less abstract, and the mdels in the Functinal and Cmmunicatin view shw data classes as an attribute f the relatinship between system elements, then there is a crrespndence rule t these views: Every data class which is used as an attribute f a relatinship between system elements in the Functinal and Cmmunicatin view must crrespnd t a data class in the Data view. Page 54 f 90

55 Chapter 6 Summary and recmmendatins This last chapter first presents a summary f the perfrmed study in sectin 6.1. Secndly, the recmmendatins fr PinkRccade Lcal Gvernment resulting frm this prject are presented in sectin Summary The architectural maturity f PinkRccade Lcal Gvernment was examined in the preliminary stages f the prject. The NASCIO Enterprise Architecture Maturity Mdel was used t quantify the quality f the current architectural prcesses and the underlying architectural prducts. As a result f the assessment PinkRccade Lcal Gvernment was placed in maturity level 1, which is a maturity level where rganizatins are characterized by architectural prcesses which are primarily ad hc and infrmal. Furthermre, the need fr mre frmal, cmplete and cnsistent architectural dcumentatin f the sftware prduct line was identified, and there was a general cnsensus that steps twards architectural maturity needed t be cnsidered. Therefre, a master thesis prject was defined by PinkRccade Lcal Gvernment. The gal f this thesis was defined as the elabratin f the cre f the architectural descriptin fr the sftware prduct line f PinkRccade Lcal Gvernment. PRLG pursues a threefld purpse with this prject: Identificatin and definitin f architectural viewpints by taking the requirements and cncerns f a selected grup f internal stakehlders int accunt Elabratin f these architectural viewpints int views with cncrete architectural mdels Descriptin f the research apprach twards selectin f the architectural viewpints and the creatin f the views. The prject was limited by fcusing n internal stakehlders nly. Furthermre, the fcus f the architectural descriptin was primarily n dcumenting the business and cnceptual architecture aspects f the sftware system. A prerequisite f the prject was that architectural descriptin had t be cmpliant with the NORA 2.0 standards. The first prject step was t select a grup f internal stakehlders which wuld actively cperate in the creatin f the architectural viewpints and mdels. The amunt f stakehlders was determined by making a trade-ff between a larger grup f stakehlders which wuld imprve the chances f delivering a successful architectural prduct, and a smaller grup f stakehlders, since a larger stakehlder grup implies that mre time is needed t actively invlve all individuals. Finally, a grup f seven stakehlders was selected. These stakehlders were individually interviewed t recrd the requirements and the cncerns f the stakehlders regarding the architectural descriptin. Based n these stakehlder cncerns the first set f viewpints was selected and first versin f the views was created in parallel. During the selectin f the architectural viewpints the fllwing elements were taken int accunt: requirements and cncerns f the stakehlders, the NORA 2.0 standards and literature. After the first selectin f viewpints and cmpletin f the first versin f the views a frmal evaluatin tk place. The frmal evaluatin cnsisted f tw parts: a frmal presentatin t the Architectuur vakgrep and stakehlder evaluatin meetings. The insights gathered during the evaluatin were used t select the final set f viewpints and t shape the Page 55 f 90

56 assciated views int their final versin. The final architectural descriptin f PinkRccade Lcal Gvernment cntains nine viewpints: Functinal viewpint Interface viewpint Custmer rganizatinal viewpint Custmer services viewpint Business prcess viewpint Applicatin prcess viewpint Cmmunicatin viewpint Data viewpint NORA viewpint The viewpints have been defined in a platfrm-independent way. This means that n specific architectural platfrm has been taken int accunt when mdeling the viewpints. The viewpints are defined thrugh standard mdeling languages (i.e. UML) such that it is pssible t create the mdels in every architectural platfrm available. Furthermre, certain elements and techniques applied in the NORA 2.0 framewrk are adpted in the creatin f the viewpints. The views d nt include all architectural mdels f the system f PinkRccade Lcal Gvernment, due t the limited time span f this thesis prject. The final set f nine viewpints required elabratin f a substantial amunt f views (sme f them at several aggregatin levels). This was nt feasible within the prject scpe and as a result, nly high-level and intermediate views were elabrated fr a number f viewpints. These architectural mdels were created in cnfrmance with their assciated viewpint s cnventins. This prject has resulted in the elabratin f the cre f the architectural descriptin fr the sftware prduct line f PinkRccade Lcal Gvernment. This dcument recrds the research apprach that was applied t select and define the viewpints and t create the architectural mdels. The viewpints were selected t address the stakehlder s requirements and cncerns, and views were created which are cnfrmant t the assciated viewpint s cnventins. This architectural descriptin can be seen as a first step twards imprving the architectural maturity f PinkRccade Lcal Gvernment. Page 56 f 90

57 6.2 Recmmendatins As mentined in the preceding sectin, the result f this study can be seen as a first step twards imprving the architectural maturity f PinkRccade Lcal Gvernment. Hwever, the prject was limited in its set-up mainly due t the limited time span f the prject. Therefre, mre effrt frm the side f PinkRccade Lcal Gvernment is necessary t extend the elabrated cre f the architectural descriptin int cmplete and cnsistent architectural dcumentatin. This sectin recrds the recmmendatins fr PinkRccade Lcal Gvernment resulting frm this prject. The fcus f the prject was n internal stakehlders nly. The viewpints that have been selected fr internal use are prbably nt directly applicable fr external use and cmmunicatin t custmers, since they will have different requirements and cncerns. Hwever, the custmers and ther external stakehlders are als a very imprtant grup f stakehlders f the sftware system. The selectin f specific viewpints fr external stakehlders culd be really helpful. It culd, fr example, imprve the cmmunicatin abut the sftware system twards custmers. The prcess f selecting and defining these viewpints is essentially the same as the prcess steps described in this prject. Hwever, cmpliance with the NORA 2.0 standards becmes even mre imprtant when selecting and defining viewpints fr external stakehlders. In the set-up f this study there was nly time fr ne frmal evaluatin mment with the stakehlders where the selected viewpints culd be assessed. When PinkRccade decides t imprve the current architectural descriptin and wants t invlve stakehlders in the prcess, the stakehlders shuld preferably be invlved mre intensively in the prcess and mre frmal evaluatins shuld be planned. This imprves the chances f delivering a successful dcumentatin which fits the requirements and the cncerns f the stakehlders. Due t the limited time span f the prject, the grup f actively invlved stakehlders was restricted t seven. If PinkRccade Lcal Gvernment wants t be certain that the architectural dcumentatin addresses the requirements and cncerns f all system stakehlders, the grup f invlved stakehlders shuld prbably be expanded in a future prject. The dcumentatin f the technical infrastructure f the system was, due t time limitatins, nt in the scpe f this prject. In a future versin f the architectural descriptin this part f the architecture culd be mdeled as well. Creating an architectural descriptin is an iterative prcess. It is nt a prject with an enddate. A sftware develpment prject is cntinuusly subject t change; requirements, pririties, mdules, restrictins. It is imprtant t keep the viewpints and mdels up t date and change them when necessary. Furthermre, the rganizatin shuld reserve resurces t manage the architectural prcess. The architectural prcess des nt stp when the first versin f architectural dcumentatin is delivered, it shuld be an n-ging prcess. Page 57 f 90

58 The IEEE standard recmmends that the architectural ratinale fr key architectural decisins shuld be included in the architectural descriptin. The ratinale recrds why certain imprtant architectural decisins were made, which alternatives were cnsidered r what analysis led t the current chice. This infrmatin is lst when the creatrs f the system leave the rganizatin. As stated by Bsch [2004], a sftware architecture shuld nt be seen as a set f cmpnents and cnnectrs, but rather as the cmpsitin f a set f architectural design decisins. S the tacit knwledge which is nw in the architects minds shuld be made explicit and dcumented in the architectural descriptin. The architectural ratinale was nt included in this prject due t the limited time span f the prblem and the lack f knwledge n key architectural decisins. This task is best executed by the current architects f the system. The definitin f sftware architecture by the IEEE standard is: The fundamental rganizatin f a system embdied in its cmpnents, their relatinships t each ther, and t the envirnment, and the principles guiding its design and evlutin. The fundamental rganizatin f a system is embdied in the viewpints and mdels which have been created in this prject. Hwever, the principles guiding the design and evlutin f the sftware system have nt been dcumented. An architectural principle can be defined as a fundamental statement that guides the definitin f an architecture. It may crrespnd t the current state f the architecture r t a desired future state. In the case f PinkRccade there are principles that are externally enfrced by gvernmental laws and regulatins and the rganizatin might have set basic principles which ffer guidance fr the design f the system. The fundamental principles included in the NORA 2.0 standard are an example f externally enfrced principles: Services thrugh the Internet: Organizatins in the public dmain prvide their services t citizens, cmpanies and scial rganizatins thrugh the internet (electrnic cunter) and they stimulate the use f this specific channel [NORA 2.0, 2007]. Rzanski and Wds [2005] recmmend including the architectural principles in the architectural descriptin. Page 58 f 90

59 References Bachmann, F., Bass, L., Carriere, J., Clements, P., Garlan, D., Ivers, J., Nrd, R. and Liitle, R., Sftware architecture dcumentatin in practice: Dcumenting architectural layers, CMU/SEI-2000-SR-004, Carnegie Melln Sftware Engineering Institute, March 2000 Bratthall, L., Runesn, P., A taxnmy f Orthgnal Prperties f Sftware Architecture, Prc. Secnd Nrdic Sftware Architecture Wrkshp (NOSA '99), 1999 Bsch, Sftware Architecture: The Next Step, Prc. 1 st Eurpean Wrkshp Sftware Architecture (EWSA 04), LNCS 3047, Springer, 2004, pag Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nrd, R., and Staffrd, J. Dcumenting Sftware Architectures: Views and Beynd, Bstn, Addisn-Wesley, 2002 Dl, van den F., Keller & Wagenaar, Architectuur Elektrnische Overheid, versie 2.0, 2002 Emery, D., Hilliard, R., Updating IEEE1471: architecture framewrks and ther tpics, Seventh Wrking IEEE/IFIP Cnference n Sftware Architecture, IEEE, 2008 Grefen, P., Slides f ICTA curse 2007, Eindhven University f Technlgy Hislp, D., Knwledge management in rganizatins: A critical intrductin, Oxfrd University Press Lndn, 2005 IEEE std , IEEE Recmmended Practice fr Architectural Descriptin f Sftware-Intensive Systems, Sftware Engineering Standards Cmmittee f the IEEE Cmputer Sciety, 2000 Kazman, R., Bass, L., Webb, M., Abwd, G., SAAM: A Methd fr Analyzing the Prperties f Sftware Architectures, Prc. 16th Int l Cnf. Sftware Eng. (ICSE 94), IEEE CS Press, 1994, pag Kazman, R., Klein, M., Clements, P., ATAM: Methd fr architecture evaluatin, CMU/SEI-2000-TR- 004, Carnegie Melln Sftware Engineering Institute, August 2000 Klinkenberg, N., Rietveld, E., De knikkers en het spel; Ondernemerschap vr manager (Dutch), 2002, Uitgeverij Thema Kmen, T., Pl, M., Test Prcess Imprvement, a practical step-by-step guide t structured testing, Addisn-Wesley, 1999, Bstn Kruchten, P., Obbink, H., Staffrd, J., The past, present, and future f Sftware Architecture, IEEE Sftware March/April 2006, pag Kruchten, P., The 4+1 View Mdel f Architecture, IEEE Sftware, vl. 12, n. 6, 1995, pag Kruchten, P., Capilla, R., Duenas, J.C., The Decisin view s rle in sftware architecture practice, IEEE Sftware, March/April 2009, pag Page 59 f 90

60 Maier, M.W., Emery, D., Hilliard, R., Sftware Architecture: Intrducing IEEE Standard 1471, IEEE Cmputer, April 2001 Nanka, I., A dynamic thery f rganizatinal knwledge creating, Organizatin Science, 1994 NASCIO, NASCIO Enterprise Architecture Maturity Mdel, Natinal Assciatin f State Chief Infrmatin Officers (NASCIO), December 2003 NORA 2.0, Nederlandse Overheid Referentie Architectuur, 2007 Rumbaugh, J., Jacbsn, I., Bch, G., The Unified Mdeling Language Reference Manual secnd editin, Addisn-Wesley, 2005, Bstn Rzanski, N., Wds, E., Sftware Systems Architecture, Addisn-Wesley Prfessinal, 2005 Schijvenaars, T., Referentie Architectuur egemeente v2.0 (Presentatin), PinkRccade Lcal Gvernment, 2008 Sftware Engineering Institute (SEI) Carnegie Melln, website n sftware prduct lines, Spender, J.C., Making Knwledge the Basis f a Dynamic Thery f the Firm, Strategic Management Jurnal, Vl. 17, Special Issue: Knwledge and the Firm (Winter, 1996), pag Steenbergen, M. van, Berg, M. van den, Brinkkemper, S., A Balanced Apprach t Develping the Enterprise Architecture Practice, Lecture Ntes in Business Infrmatin Prcessing, Vlume 12, Enterprise Infrmatin Systems, Springer Berlin Heidelberg, 2007 The Open Grup, ArchiMate 1.0 Specificatin, C091, 2009 UML Ntatin Guide, Unified Mdeling Language, Ratinal Sftware Crpratin, 1997 Page 60 f 90

61 Appendix A Architectural Maturity Mdel A.1 Intrductin t AMM cncept The underlying cncept behind the Architecture Maturity Mdel (abbreviated as AMM) is the Capability Maturity Mdel. The cncept f the mdel was develped by the Sftware Engineering Institute in It has becme a wrldwide apprach fr assessing maturity f the sftware develpment prcess. Fr the specific prcess f sftware develpment the CMM has defined five maturity levels with underlying characteristics. The main idea behind the cncept f the Capability Maturity Mdel is als applicable t ther business prcesses. Fr the sftware architecture prcess it is called the Architecture Maturity Mdel, where maturity levels are used t categrize the maturity f architectural prcesses within rganizatins. [Klinkenberg and Rietveld, 2002] Van Steenbergen et al. [2007] state that tw variants n the mdel can be distinguished: 1. Staged 5-level Mdels: These mdels distinguish five levels f maturity. Fr each level a number f fcus areas are defined specific t that level. These fcus areas have t be implemented satisfactrily fr the rganizatin t achieve that particular level. 2. Cntinuus 5-level Mdels: These mdels als distinguish five general maturity levels and a number f fcus areas. The difference with the first kind f mdels is that the fcus areas are nt attributed t a level, but within each fcus areas the 5 levels are distinguished. The NASCIO Enterprise Architecture Maturity Mdel is an example f this type [NASCIO, 2003]. As the basis fr a new third apprach twards assessing maturity, Steenbergen et al. adpted a methd frm the field f test prcess imprvement by Kmen and Pl [1999]: 3. Fcus Area Oriented Mdels: These mdels depart frm the idea that there are five generic maturity levels. Instead each fcus area has its wn number f specific maturity levels. The verall maturity f an rganizatin is expressed as a cmbinatin f the maturity levels f these fcus areas. The current maturity f the architectural prcess at PRLG was assessed by using a cntinuus 5-level mdel. The main reasn fr chsing a cntinuus 5-level mdel, instead f a mre extensive fcus area riented mdel is because the maturity assessment is nly executed t btain a rugh idea f the current quality f the architectural prcesses. Departing frm the five fixed maturity levels makes the fcus area riented mdel mre flexible in defining bth fcus areas and interdependencies between fcus areas. [van Steenbergen et al., 2007]. Fr this study hwever, there is n need t g int detail n every fcus area. At the start f the research PinkRccade Lcal Gvernment already indicated that there was a need fr structuring the architectural prcess. By using the architecture maturity mdel the current situatin at PRLG can be assessed and frmally psitined within ne f the five maturity levels. Page 61 f 90

62 The specific cntinuus 5-level mdel which was applied during this research is the NASCIO Enterprise Architecture Maturity Mdel [NASCIO, 2003]. The mdel fllws the path f an rganizatin as their enterprise architecture prgram matures. Each level cntains statements that are indicative f an enterprise architecture prgram at that level. These statements have been rganized int categries. Table A.1 shws an verview f all the levels, the categries and sme keywrds cncerning the statements per level. Categries Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Administratin Nthing in place Need fr cmmittees Planning Framewrk Blueprint N plans in place N prcesses and templates N dcumentatin Cmmunicatin N awareness f EA Cmpliance Integratin Invlvement N cmpliance in rganizatin N integratin prgram N awareness prgram Need fr EA identified Prcesses are ad hc and nt unified Dcumentatin infrmal and incnsistent Need f awareness identified Need cmpliance t standards identified Need t integrate identified Awareness prgram infrmal and incnsistent Cmmittees starting t frm Identifying EA tasks and requirements Basic EA prgram is dcumented Business drivers identified Emergence f EA awareness activities Cmpliance prcess start up Need t integrate identified EA cncepts are being intrduced in rganizatin Table A.1 Overview f all the maturity levels f the NASCIO mdel Defined rles and respnsibilities Structured timeline fr EA develpment Architecture prcesses defined and dcumented Dcumentatin n standards is cnsistent Architecture is well cmmunicated Frmal EA cmpliance prcess EA integrated with strategic planning Senir management is invlved Rles cnstantly reviewed and updated EA plans are reviewed and updated Regular meetings t review EA framewrk Dcumentatin is standard practice Frmal cmmunicatin plan is in place Cmpliance t EA standards cmmn practice Integratin prcedures are reviewed and updated Organizatin has gd understanding f EA Cmmittees practively review activities Actin plans practively implemented Lifecycle prcesses are secnd nature Business drivers are reviewed and mnitred Identify pprtunities t imprve cmmunicatin Practively updating EA standards Cntinual reinventin thrughut enterprise All departments cntribute t EA and prcess Page 62 f 90

63 A.2 Results f NASCIO maturity assessment During the interviews with the system stakehlders in the preliminary stages f the study, the architectural maturity f PinkRccade Lcal Gvernment was assessed by using the NASCIO methd described in sectin A.1. The stakehlders were asked t assess the current status f PinkRccade Lcal Gvernment fr the fllwing elements: 1. Invlvement thrughut cmpany What is the degree f invlvement in the architecture prcess acrss the cmpany 2. Invlvement senir management T what extent is senir management invlved in the architectural prgram 3. Gvernance rles T what extent are clear rles and respnsibilities defined related t architecture 4. Architectural planning In what phase is the architectural prcess currently situated and what imprvements are planned? 5. Overall maturity level Which maturity level wuld best fit the current architectural situatin f PRLG? Fr each element the stakehlders had t assess what the apprpriate NASCIO maturity level fr PRLG was. Each maturity level in NASCIO cntains statements fr each f the elements mentined abve that are indicative f that level (see [NASCIO, 2003]), and stakehlders were asked which statements best fit the situatin f PRLG. The results f the assessment can be fund in table A.2. Maturity indicatrs Stakehlder Invlvement f cmpany Invlvement f senir manag. Gvernance rles Architectural planning Overall maturity level Master architect X X X X X Dmain architect 1 X X X X X Dmain architect 2 X X X X X Business manager 1 X X X X X Business manager 2 X X X X X Develper X X X X X Sales representative X X X X X Next t the results f the interviews, the architectural dcument was als assessed. The utcme f this assessment was that the architectural dcumentatin at this pint in time is incnsistent, incmplete and needs t be frmalized. Based n these results, the verall maturity level f PinkRccade was determined n level 1. Page 63 f 90

64 Appendix B Architectural descriptins Architectural descriptin (als called architectural dcumentatin [Clements et al., 2003]) is defined as a cllectin f prducts t dcument a sftware architecture [IEEE ]. Therefre, there is a clear distinctin between an architecture f a system and its architectural descriptin. The recmmended practice [IEEE ] distinguishes the architecture f a system, which is cnceptual, frm particular descriptins f that architecture, which are cncrete prducts r artifacts. In ther wrds, an architectural descriptin can be seen as a set f tangible prducts which describe the sftware architecture at hand. B.1 Purpses f architectural dcumentatin Architectural dcumentatin can serve several purpses during a sftware prject s lifetime. Fr each rle the architectural dcumentatin will lk different. Architecting is best understd in a lifecycle cntext, nt simply as a single activity at ne pint in that life cycle. [IEEE ]. Bachmann et al. [2000] have defined several uses f architectural dcumentatin during the lifecycle f a prject: A vehicle fr cmmunicating the system s design t interested stakehlders at each stage f its evlutin This perspective n architecture is frward-lking, invlving steps f creatin and refinement. The architecture establishes invilable cnstraints (and explitable freedms) n dwnstream develpment activities. A basis fr perfrming up-frnt analysis t validate architectural design decisins and refine r alter thse decisins where necessary This perspective n architecture is, in sme sense, inward-lking. It invlves making prspective architectural decisins and then prjecting the effect n thse decisins n the system that the architecture is driving. One f these architectural evaluatin methds is the Architecture Tradeff Analysis Methd (ATAM). The purpse f the ATAM is t assess the cnsequences f architectural decisins in the light f quality attribute requirements. [Kazman et al., 2000]. The first artifact used t achieve system understanding This perspective n architecture is reverse-lking. It refers t cases in which the system has been built and deplyed, and nw the time has cme t make a change t it r t extract resurces frm it fr use elsewhere. Fr new prject members the architecture is usually the first artifact fr familiarizatin with a system s design. Accrding t Clements et al. [2003] an architectural descriptin can serve three different fundamental purpses: 1. Architecture serves as a means f educatin. The educatinal use cnsists f intrducing peple t the system. The peple may be new members f the team, external analysts, r even a new architect. 2. Architecture serves as a primary vehicle fr cmmunicatin amng stakehlders. A stakehlder is smene wh has a vested interest in the architecture. The architecture s precise use as a cmmunicatin vehicle depends n the need f the stakehlder, and his pint f view. Page 64 f 90

65 3. Architecture serves as the basis fr system analysis. T supprt analysis, the architecture dcumentatin must cntain the infrmatin necessary fr the particular analyses being perfrmed. B.2 IEEE Standard The Cmputer Sciety apprved IEEE Standard 1471 in It dcuments a cnsensus n gd architectural descriptin practices. IEEE 1471 fcuses n bth sftware-intense systems and mre general systems, such as infrmatin systems, embedded systems, systems-f-systems, prduct lines, and prduct families in which sftware plays a substantial rle in develpment, peratin, r evlutin [Maier et al., 2001]. The purpse f the recmmended practice is t facilitate the expressin and cmmunicatin f architectures and thereby lay a fundatin fr quality and cst gains thrugh standardizatin f elements and practices fr architectural descriptin. Hwever, befre the apprval f IEEE Standard 1471 there had nt yet emerged any reliable cnsensus n a precise definitin f a system s architecture and its architectural descriptin, i.e. hw it shuld be described, what uses such a descriptin may serve, r where and when it shuld be defined. Reaching cnsensus abut these definitins is ne f the gals f the standard. B Cnceptual framewrk f IEEE One f the chapters in the standard cntains a cnceptual framewrk, which establishes terms and cncepts pertaining t the cntent and use f architectural descriptins. The cnceptual framewrk is visualized in figure B.1, and shws the relatinships between the varius cncepts and terms. A system inhabits an envirnment. A system s envirnment can influence that system. The envirnment, r cntext, determines the setting and circumstances f develpmental, peratinal, plitical, and ther influences upn that system. The envirnment can include ther systems that interact with the system f interest, either directly via interfaces r indirectly in ther ways. The envirnment determines the bundaries that define the scpe f the system f interest relative t ther systems. A system has ne r mre stakehlders. Each stakehlder typically has interests in, r cncerns relative t, that system. Cncerns are thse interests which pertain t the system s develpment, its peratin r any ther aspects that are critical r therwise imprtant t ne r mre stakehlders. Cncerns include system cnsideratins such as perfrmance, reliability, security, distributin, and evlvability. Furthermre, a system exists t fulfill ne r mre missins in its envirnment. A missin is a use r peratin fr which a system is intended by ne r mre stakehlders t meet sme set f bjectives. Page 65 f 90

66 Figure B.1 Visualizatin f cnceptual framewrk IEEE (adpted frm IEEE standard 1471) Every system has an architecture, in the terms f the recmmended practice. An architecture can be recrded by an architectural descriptin. The IEEE standard distinguishes the architecture f a system, which is cnceptual, frm particular descriptins f that architecture, which are cncrete prducts r artifacts. In the cnceptual framewrk an architectural descriptin is rganized int ne r mre cnstituents called (architectural) views. Each view addresses ne r mre f the cncerns f the system stakehlders. The term view is used t refer t the expressin f a system s architecture with respect t a particular viewpint. A viewpint establishes the cnventins by which a view is created, depicted and analyzed. In this way, a view cnfrms t a viewpint. The viewpint determines the languages (including ntatins, mdel, r prduct types) t be used t describe the view, and any assciated mdeling methds r analysis techniques t be applied t these representatins f the view. These languages and techniques are used t yield results relevant t the cncerns addressed by the viewpint. A viewpint definitin may riginate with an AD, r it may have been defined elsewhere. A viewpint that is defined elsewhere is referred t as a library viewpint. An architectural descriptin selects ne r mre viewpints fr use. The selectin f viewpints typically will be based n cnsideratin f the stakehlders t whm the AD is addressed and their cncerns. A view may cnsist f ne r mre architectural mdels. Each such architectural mdel is develped using the methds established by its assciated architectural viewpint. An architectural mdel may participate in mre than ne view. Page 66 f 90

67 B.2.2 Cntent f architectural descriptin The IEEE Standard recmmends t include the fllwing five elements in the architectural descriptin: 1. Identificatin f stakehlders and cncerns: The architectural descriptin must identify the stakehlders and their cncerns. Examples f cncerns are purpse, apprpriateness, feasibility and risks. 2. Selectin f architectural viewpints: The descriptin must identify the viewpints which are used. Furthermre the ratinale fr their selectin must be explained and each viewpint must be linked t the apprpriate cncerns f the stakehlders. The mdeling language is als defined in the viewpint. 3. Architectural views: The architectural descriptin must include multiple views, where each view crrespnds t nly ne viewpint. Each view cntains a single r multiple architectural mdels. 4. Cnsistency amng architectural views: The descriptin must cntain an analysis f cnsistency acrss all f its architectural views, and any incnsistencies must be recrded. 5. Architectural ratinale: The descriptin must include the ratinale fr the architectural cncepts and decisins selected. Furthermre it must prvide evidence f the cnsideratin f alternative architectural cncepts and the ratinale fr the chices made. Kruchten et al. [2009] state that there are several benefits f using design ratinales in architecture. One f the advantages is aviding the architecture-recvering prcess when an architecture design, dcumentatin r even the creatrs are n lnger available. B.3 Architectural descriptin as rganizatinal knwledge One f the purpses f a architectural descriptin is t preserve the knwledge f a system s architecture. The knwledge regarding the sftware architecture can be primarily in the head f the experts. T be sure t preserve this knwledge, it shuld be dcumented in an architectural descriptin and stred as rganizatinal knwledge. Spender [1996] has cnstructed a tw-by-tw matrix which categrizes the fur different generic knwledge types fr rganizatins. (Table B.1) On the vertical dimensin Spender differentiates between explicit and implicit/tacit knwledge. The tacit r implicit dimensin f knwledge is rted in actin, experience, and invlvement in a specific cntext. An example is the ability t juggle, r t d mental arithmetic. It represents knwledge that peple pssess, but which is inexpressible [Hislp, 2005]. Explicit knwledge, n the ther hand, can be expressed in frmal and systematic language and can be shared in the frm f specificatins, manuals r mdels. On the ther dimensin, Spender differentiates between individual and grup/scial knwledge. Individual knwledge is created by and exists in the individual, while grup knwledge is created by and is inherent in the cllective actins and interactins f individuals acting as a grup [Nnaka, 1994]. Page 67 f 90

68 In the terminlgy f Spender, PinkRccade Lcal Gvernmet wants t transfer knwledge frm the cnscius quadrant (which is explicit and n an individual level) t the bjectified quadrant (which is explicit and n a grup/rganizatinal level). The bjectified quadrant is a strage f explicit rganizatinal knwledge. The bjectified quadrant is clearly strng n memry: libraries, data banks, standard perating prcedures, rule-based prductin systems, and s frth. The knwledge stred cmes frm elsewhere. [Spender, 2006] Architectural knwledge, which is nw mainly available n an individual level, needs t be explicitly stred in an rganizatinal cntext. An architectural descriptin in the definitin f IEEE is a cllectin f cncrete prducts t dcument the architecture f a sftware system. S an architectural descriptin is explicit knwledge which can be shared n an rganizatinal level, and can therefre be classified as bjectified rganizatinal knwledge. Individual Scial Explicit Cnscius Objectified Tacit Autmatic Cllective Table B.1: The different types f rganizatinal knwledge [Spender, 1996] Page 68 f 90

69 Appendix C NORA 2.0 NORA 2.0 is an abbreviatin fr Nederlandse Overheid Referentie Architectuur 2.0 ( Dutch gvernmental reference architecture ). It signifies a dcument which cntains principles, mdels and standards fr the design and the rganizatin f the e-gvernment. The fcus f NORA 2.0 is supprting cllabratin between gvernmental institutins. C.1 Reference mdel NORA 2.0 includes a reference architecture f a gvernmental institutin. Figure C.1 visualizes a simplified mdel f the way gvernmental rganizatins prvide services t citizens and businesses. This mdel is cnstructed by PinkRccade Lcal Gvernment but embdies the reference architecture as defined by NORA 2.0. The generic structure f the gvernment departs frm the idea that citizens and businesses request a gvernmental service r prduct frm ne f the gvernmental institutins in the public dmain. The services can be prvided thrugh multiple channels (frnt ffice). Examples f these channels are the gvernmental website, the call centre, e- mail, and the physical cunter at the lcal gvernment. The prvided services are the result f wrking prcesses which are executed within the gvernmental institutins (mid-ffice and backffice). T successfully execute the wrking prcesses there is als a need fr data strage and retrieval (back-ffice). Figure C.1 - Simplified mdel f prviding gvernmental services Page 69 f 90