Verslag NAF-rondetafel ‘Architectuur van het Applicatielandschap’ Daan Rijsenbrij1 en Huub Bakker2 (mei 2014)
Inhoud 1. Inleiding 2. Key note 3. Moderne applicaties en het moderne applicatielandschap 4. Architectuurvisie 5. Architectuurmodellen van applicatielandschappen 6. Het managen van de applicatieportfolio onder architectuur 7. Slotopmerkingen rondetafel 8. Deelnemers
1. Inleiding Om de state-of-the-art in Nederland en Vlaanderen over de architectuur van het applicatielandschap in kaart te brengen, heeft het NAF Daan Rijsenbrij en Huub Bakker gevraagd een eerste inventarisatie uit te voeren. Op woensdagmiddag 28 mei 2014 hebben zij daartoe namens het NAF een rondetafel-bijeenkomst gefaciliteerd, ingericht als kenniscafé. Er waren vier tafels met elk een duidelijk gespreksonderwerp. Roulerend gingen uitgebalanceerde subgroepen van ongeveer 6 deskundigen langs de tafels om gedurende 40 minuten concreet te discussiëren bij elke tafel. Via een uitgebreide interactieve digitale brainstorming met een aantal vooraanstaande bedrijven en overheidsorganisaties is eerst een ‘long list’ gemaakt van mogelijke onderwerpen. Vervolgens zijn de vier tafelvoorzitters aangezocht. Zij hebben met elkaar die ‘long list’ terug gebracht tot vier tafelonderwerpen. Tafel 1: ‘Moderne applicaties en het moderne applicatielandschap’ applicatietypologieën, met elk type zijn eigen specifieke architectuur. veranderende architectuurstijlen: o van systemen naar services (SOA); o van productoriëntatie naar klantoriëntatie; o van procesgericht naar zaakgericht; o van ‘built to last’ naar ‘built to change’: data-driven, rules-driven en eventdriven; o van bulkverwerking (transactioneel) naar solowerking (individueel). generieke applicatie-infrastructuren: o platformen voor het verbinden met derden en data-uitwisseling van / naar de eigen andere omgevingen; o clouds; o configureerbare applicaties als landingsplek voor bedrijfskennis en data; 1 2
Daan Rijsenbrij is zelfstandig, onafhankelijk architect in de Digitale Wereld. Huub Bakker is Manager Architectuur bij de Belastingdienst.
1
o o o
configureerbare middlewarecomponenten; gebruikerinteractie via multi-channel, BYOD, apps; app stores.
Tafel 2: ‘Architectuurvisie’ strategische uitgangspunten en architectuurprincipes, waaronder complexiteitsreductie en adaptiviteit; relaties met andere architectuurgebieden en compliancy vereisten; compartimenteren met gestandaardiseerde communicatie / relatie tussen compartimenten (componenten); (product)modulariteit en componentenmodel; integratiefilosofie tussen de modulen / componenten, maar ook tussen externe (SaaS) providers; ontwikkeling naar API’s; een flexibele front laag; (open) standaards. Tafel 3: ‘Architectuurmodellen van applicatielandschappen’ welke modellen en voor wie (categorieën); notatiewijze (ArchiMate etc.) en visualisatie voor verschillende doelgroepen; inzicht in bestaande spaghetti, analyse van applicatielandschappen (bijv. voor applicatieportfoliomanagement) met behulp van architectuurmodellen; het beheersen van complexiteit en redundantie met behulp van modellering; architectuur versus transformatie (road maps), de rol van architectuurmodellen bij projectportfoliomanagement. Tafel 4: ‘Het managen van de applicatieportfolio onder architectuur’ behouden van overzicht en consistentie tijdens veranderingen; managen van (de complexiteit in) hybride applicatielandschappen (cloud, on premise, apps); managen van de snelheid waarmee je applicatielandschappen kunt / moet veranderen (agile, devops); managen van de cruciale relatie tussen data en applicaties (managementinfo); managen van de legacy in de applicaties (technical debt, functionele fit, kosten) inclusief het voorkomen van nieuwe legacy; managen van de relatie tussen generieke en specifieke applicaties en applicatiecomponenten. In de volgende paragraaf staat een korte weergave van de key note van Johan Krebbers. In de paragrafen 3 tot en met 6 staan de door de deelnemers geaccordeerde eindverslagen van de vier tafels. In paragraaf 7 wordt aandacht besteed aan het werk dat nog gedaan moet worden. Ten slotte worden in paragraaf 8 de deelnemers aan deze NAF-rondetafel opgesomd. Mede door hun vakbekwaamheid en open instelling is deze rondetafel een succes geworden.
2
2. Key note Johan Krebbers (Group IT Architect van Shell) heeft in vogelvlucht een inspirerend inzicht gegeven over de wijze waarop Shell met haar applicaties, haar applicatielandschap en haar data infrastructuur omgaat. Leerzaam was het waarom achter een groot aantal essentiële architectuurkeuzes. Zijn duidelijke stellingnamen klonken door in de brainstormingen aan de discussietafels. Shell heeft een zeer groot aantal regels code ontwikkeld. Vroeger werden deze all over the world decentraal bewaard en beheerd. Nu heeft Shell daar centraal de regie over genomen. Shell heeft slechts vijf ERP-systemen: upstream, downstream, trading, hrm en finance. Er is de laatste tien jaar ruim een miljard geïnvesteerd in het creëren van deze ERP-systemen. De volgende uitdaging is hoe Shell de waarde uit die ERPsystemen krijgt in termen van business-relevante data. De belangrijkste uitspraken en keuzes die bij Shell zijn gemaakt voor haar applicaties, haar applicatielandschap en de data zijn: 1. Elke applicatie dient in principe client onafhankelijk te zijn, en dus benaderbaar via de vier belangrijkste web browsers. 2. Elke applicatie dient te bestaan uit simpele kleine componenten. 3. Applicaties zijn data driven, vanuit een gegarandeerde data kwaliteit. 4. Data bestaat uit structuur (architectuur) en content. De business is de data owner, dus accountable voor de content. 5. Belangrijker dan de omvang van de data verzameling (zogenaamde ‘big data’) zijn de analytics die kunnen worden toegepast op die data verzameling. In feite horen data en data analytics bij elkaar. 6. Zet ‘data out’ (de data die uit de data hub komt ten behoeve van de eindgebruiker) centraal in de data-beschouwing. 7. Externe clouds (public of hybride) dienen uitsluitend te worden gebruikt op SaaSniveau (platformen en technische infrastructuur zijn en blijven de uitdagingen van de SaaS-provider). 8. Shell blijft ten alle tijden baas over zijn eigen data, dus geen eigen, vertrouwelijke data in de public cloud. Vermijd data op een personal device. 9. Single sign on wordt strikt doorgevoerd, ook voor de cloud toepassingen. 10. Single version of truth is een absolute noodzaak. ad 1: Shell forceert via haar motto ‘mobile first’ het maken van een eenvoudige user interface. Applicaties worden eerst voor de mobile omgeving ontwikkeld en kunnen daarna eventueel lichtelijk worden aangepast aan de desktop omgeving. Elke applicatie, gemaakt of gekocht, moet in principe HTML5 compliant zijn. Dat is belangrijk voor de support van de IT consumerisation. Ook levert dat de nodige flexibiliteit in de client-cloud strategie van Shell. Tevens is het dan mogelijk eenvoudig aan te sluiten op de door Shell gekozen graphic applicaties. ad 2: Shell gaat uit van een legoblokken benadering, waarbij snel kan worden ontwikkeld door vanuit die legoblokken (componenten of desktop services) middels een factory benadering applicaties te bouwen. De legoblokken dienen zodanig te worden 3
gekozen dat er minimale onderlinge afhankelijkheden zijn. Dus bij kleine verandering hoeft slechts een of een klein aantal gerelateerde legoblokken te worden aangepast. Dit is belangrijk voor een eenvoudig onderhoud en een soepele, grotendeels geautomatiseerde deployment. De Shell filosofie over component based development, agile en DevOps bouwen voort op die legoblokken benadering. ad 3: Het is belangrijk om de data laag en de client laag strikt gescheiden te houden. Te meer omdat de client laag steeds diverser wordt door het fenomeen BYOD en de snelle ontwikkeling in personal devices. Shell beschermt haar back office laag van de invloeden van de client laag. ad 4: De investeringen bij Shell in data zijn erg groot, zowel gestructureerde als ongestructureerde data. Johan vindt de hype rond Big Data een beetje overdreven. Shell heeft altijd al met Big Data gewerkt. De hoeveelheid data voor een seismisch onderzoek waar je moet gaan boren heeft de grootte van een paar petabytes. Real time data (streaming data) wordt steeds belangrijker in het tijdperk van data driven business. ad 5: Analytics betekent het gebruik van data om het maken van beslissingen te voeden, in plaats van het nemen van business keuzes vanuit een goed gevoel of intuïtie. Data om inzicht te krijgen om businessactiviteiten te ontplooien leiden tot profitabele businessresultaten. Er zijn drie gebieden van analytics: descriptive (What happened? Why did it happen?) predictive (What will happen?) prescriptive (What should happen?) ad 6: ‘Data In’ zijn de applicaties die de data verzamelen. ‘Data Out’ is de behoefte van de eindgebruiker om zijn werkzaamheden te kunnen doen. Voor die eindgebruiker zijn er twee paden om data te benaderen: E-DSL (enterprise data service layer) voor directe en real time toegang en E-DWH (enterprise data warehouse) voor non real time toegang tot data bronnen. Achter dit alles zit EDAM (enterprise data model) als een soort gemeenschappelijke taal. OData wordt gebruikt als toegangsprotocol. ad 7: De data exchange tussen externe providers dient expliciet te worden geregeld. ad 10: EDAM is een single logisch datamodel voor heel Shell, nodig voor de ‘single version of truth’. Er is ook een enterpise process model, waarbij elk proces expliciet een proces owner heeft in de business.
4
Hoog op de agenda Nieuwe technologieën zorgen dat nieuwe architecturen kunnen ontstaan. Door het internet bijvoorbeeld werden gedistribueerde werkteams mogelijk gemaakt. Shell verwacht dat de combinatie van de technologieën ‘mobile’ en ‘cloud (met name SaaS)’ de katalysator zal zijn voor de volgende stap in architecturen. Collaboratie binnen en met buiten Shell staat hoog op de agenda om het bedrijf slagvaardiger te maken, binnen de benodigde security en privacy. Tenslotte schenkt Shell extra aandacht aan customerization om te borgen dat haar medewerkers effectief, efficiënt en met plezier met hun IT devices werken.
3. Moderne applicaties en het moderne applicatielandschap gefaciliteerd door Art Ligthart en Marco Brattinga 3.1. Inleiding Wat zijn moderne applicaties en wat is een modern applicatielandschap? Is het mogelijk om een trend te herkennen in de ontwikkeling van moderne applicaties? Of is ‘modern’ afhankelijk van ‘type’ organisatie of ‘type’ applicatielandschap? Deze vragen zijn behandeld tijdens de NAF rondetafel ‘de architectuur van het applicatielandschap’ met een brede groep van architecten uit zowel commerciële als overheidsorganisaties. Opvallend is dat daarbij eigenlijk weinig wordt gesproken over de architectuur zelf. Elementen als ‘van systemen naar services’, ‘van productoriëntatie naar klantoriëntatie’ of ‘van procesgericht naar zaakgericht’ worden niet genoemd. Het meest genoemd tijdens de rondetafel als ‘modern’3 zijn: 1. Cloud & mobile ready applications een applicatie die geheel ingericht is om vanaf het internet gebruikt te worden en gebruik maakt van internetvoorzieningen, mobile wordt daarbij gezien als een belangrijke drijfveer; 2. Trusted IT een applicatielandschap dat 7 x 24 beschikbaar is en voldoet aan de verwachtingen, IT die geen bottleneck is voor de organisatie maar waarop kan worden vertrouwd; 3. Agile architecting de moderne architect is onderdeel van het agile ontwikkelteam; 4. Civil digital rights met de digitalisering van onze samenleving komt ook de roep naar de ‘digitale rechtstaat’ in het moderne applicatielandschap wordt rekening gehouden met de consequentie die IT heeft voor de rechten en plichten van burgers, bedrijven en overheid; 5. Data driven applications & analytics het moderne applicatielandschap kan omgaan met grote hoeveelheden data die worden omgezet in op-maat-gesneden beschikbare informatie applicaties zijn in hoge mate configureerbaar;
3
‘modern’ zowel in de zin van ‘dit is nieuw en heb ik binnenkort nodig voor mijn organisatie’, als ‘zaken waar ik nu mee bezig ben, en in de toekomst ook nog nodig heb’.
5
6. CaaS (capability as a service) applicaties die zijn toegespitst op één enkele ‘business capability’ (een ingerichte bedrijfsfunctie); 7. Standaardisatie standaardisatie van dataopslag en –uitwisseling, onafhankelijk van applicaties complexiteitsreductie en rationalisatie modelgebaseerd werken. 3.2. Wat is daarin ‘modern’? 3.2.1 Cloud & mobile ready applications In het moderne applicatielandschap zijn applicaties ingericht om vanaf het internet gebruikt te worden. Dit zorgt ervoor dat dergelijke applicaties eenvoudiger locatieonafhankelijk te gebruiken zijn. Ook zijn deze applicaties eenvoudiger te gebruiken vanaf verschillende devices. Samen met capability as a service geeft dit bovendien de mogelijkheid om applicaties los van hun organisatie-context te gebruiken, waarmee integratie van bedrijfsprocessen over organisaties heen eenvoudiger wordt. Applicaties die gebruik maken van het internet, kunnen ook gebruik maken van internetvoorzieningen, bijvoorbeeld het gebruik van internettechnologie voor authenticatie of het gebruik van de domain name registry om de authenticiteit van applicaties te kunnen controleren. 3.2.2 Trusted IT Naast alle innovaties, wordt een betrouwbare IT gezien als modern. Natuurlijk is een betrouwbare IT geen modern verschijnsel, maar wel het feit dat een betrouwbare IT van levensbelang is voor organisaties, en dat applicaties steeds meer worden ingericht op een manier waarop betrouwbaarheid is ingebakken in de architectuur. Overigens wordt door de deelnemers expliciet vermeld, dat een betrouwbare IT niet alleen bestaat uit betrouwbare applicaties of een betrouwbaar applicatielandschap, maar ook betrekking heeft op een IT-organisatie die in staat is om dergelijke applicaties te ontwikkelen, te onderhouden en te beheren. 3.2.3 Agile architecting Het toepassen van agile ontwikkelmethoden (Scrum, Agile, DevOps) heeft ook invloed op het werk van de architect: van enterprise architect tot infrastructuur architect. ‘In een sprint van 2 weken, heb ik geen tijd om 2 maanden over mijn PSA te doen’ is een gehoord citaat. Dit vergt aanpassingsvermogen van de architect. Enerzijds doordat de (enterprise) architect bezig is met het formuleren van ‘guiding principes’. Anderzijds doordat diezelfde architect meedraait in het ontwikkelteam, en zo gedurende de ontwikkeling zijn architectuur bijslijpt en zijn architectuurbeschrijving vorm krijgt. 3.2.4 Civil digital rights Het moderne applicatielandschap is verweven met het internet en daarmee met de (dienstverlening aan) burgers en klanten van de instellingen en bedrijven. Met de voortdurende aanwezigheid op het internet, de beschikbaarheid van grote hoeveelheden informatie over klanten en burgers, is de macht van deze organisaties groot. De roep wordt dan ook steeds luider om ‘digitale rechten’, zoals ‘het recht om 6
vergeten te worden’ en ‘het recht op anonimiteit’. Steeds meer zullen applicatielandschappen van organisaties hier rekening mee moeten houden. 3.2.5 Data driven applications & analytics De hoeveelheid data die we met elkaar delen op het internet verdubbeld per jaar (vergelijk: de capaciteit van processors verdubbeld ‘slechts’ eens per 1,5 jaar). De hoeveelheid data is inmiddels zo groot, dat het niet meer mogelijk is om deze data zonder meer ‘goed’ te kunnen gebruiken. Specifieke aandacht voor analytics is nodig om van deze brei begrijpelijke op-maat-gesneden informatie te maken. Traditionele oplossingen werken daarbij niet meer. Het is niet meer mogelijk om vooraf een goede analyse te maken van het datamodel om de beschikbare data op te slaan en te gebruiken. Alternatieven zijn nodig, zoals het simpelweg opslaan van alle data, en deze – achteraf – ‘vertalen’ naar een juiste vorm voor de juiste toepassing. Om dit mogelijk te maken is het van belang dat applicaties steeds meer ‘data driven’ zijn, dat wil zeggen op basis van configuraties reageren op de beschikbare data. Dit kunnen specifieke ‘filters’ zijn om data te filteren op fraude of terrorisme. Maar het betreft ook applicaties die middels bedrijfsregels worden gestuurd. 3.2.6 CaaS (capability as a service) De oorspronkelijke ‘stove pipe’-architectuur uit de jaren 80 heeft in de afgelopen tijd plaats gemaakt voor een lappendeken van geïntegreerde applicaties: infrastructurele componenten, verticale pakketoplossingen en specifieke maatwerkprogrammatuur. Als geheel vaak een zeer moeilijk te beheren applicatielandschap waarbij het vaak ook nog moeilijk is om de juiste business owner te vinden. Het moderne applicatielandschap bestaat uit ‘capabilities-as-a-service’. Dit betekent dat relatief kleine applicaties worden aangeboden die specifiek afgestemd zijn op het gebruik binnen één ingerichte bedrijfsfunctie. De analogie met een ‘app’ is hierbij niet misplaatst. Deze ‘capabilities-as-a-service’ maken daarbij grotendeels gebruik van de bestaande betrouwbare voorzieningen. Optimaal is het gebruik van data driven applications om het gehele landschap toekomstvast te houden. 3.2.7 Standaardisatie Ter ondersteuning van bovengenoemde zaken, wordt het belang van standaardisatie genoemd. Complexiteitsreductie en rationalisatie van het IT-landschap om te komen tot een landschap dat kleiner is, maar ook minder complex. Standaardisatie op enkele goed begrepen technieken, waarvan de kennis in voldoende mate binnen de organisatie aanwezig is. Ter ondersteuning van data driven applications & analytics wordt gekeken naar het standaardiseren van dataopslag en –uitwisseling, bijvoorbeeld technologieën als ‘linked data’ en NoSQL, met als doel dat de opslag en uitwisseling van data onafhankelijk kan worden van de applicaties die hiervan gebruik maken. Applicaties veranderen, de data blijft. Ook op het gebied van de architectuur en de applicatiebeschrijvingen zelf, wordt gewerkt aan standaardisatie. Dit maakt het mogelijk om modelgericht te werken. Met modelgericht werken kan documentatie sneller beschikbaar worden gemaakt, en 7
biedt het de architect de mogelijkheid om in het tempo mee te lopen van de agile ontwikkelteams. Bovendien is de traceerbaarheid tussen de diverse architectuuronderdelen goed te bewaken. 3.3. Alle genoemde punten op een rij applicatielandschap compartimentering van het applicatielandschap; van functiegericht naar horizontale ketengedachte, verminderen van de functionele specialisatie; meer ontkoppelen: er zit nog heel veel onnodige verwevenheid in het applicatielandschap (normalized systems); integratiefilosofie en maximaal gebruik van api’s, mede in relatie met complexiteitreductie; omnichannel; consolidated user interface; self-service en STP als combinatie; ERP (eigenlijk jaren-tachtig-technologie), maar dan nu met Open Group standaarden. applicatie klantgerichte applicatiearchitectuur (met transparantie); applicatie framework en applicatie-sjablonen; platformonafhankelijke applicaties en mobile ready; data driven applicaties, waarbij de betekenis van de data niet ‘in’ de applicatie is versleuteld, maar zich ook als ‘data’ gedraagt en gebruik kan worden; de invloed van beheer op de applicatiearchitectuur; zaakgericht werken; runnable rules; applicatiearchitectuur voor analytics; ruimte in de architectuur van de applicatie voor innovaties. applicatieontwikkeling vanuit de business het services-model naar de IT vertalen, in plaats van probleem-/projectgedreven applicatieontwikkeling; UXD (user experince design) gedreven ontwikkelen; cloud-ready applicatieontwikkeling; REST-applicaties; applicatiearchitectuur versus Scrum en DevOps; architectuur opstellen voor het IT bedrijf zelf. overigen alles als een service (PaaS, SaaS, AaaS); app’s als moderne interface; internet-centric architectuur die puur op de standaarden van het internet is gebaseerd; 4GL en dan de volgende generatie; compliancy en transparantie in applicaties inbouwen; 8
security en privacy geïntegreerd in de applicatiearchitectuur en de architectuur van het applicatielandschap; goed kunnen combineren van gestructureerde en ongestructureerde data; centralisatie / decentralisatie van enterprise architectuur naar solution architectuur; waarde van architectuur / valorisatie / technical debt / ontwerpbeslissingen belangrijker.
4. Architectuurvisie gefaciliteerd door Huub Bakker en Bert Veldkamp Het applicatielandschap van vrijwel alle organisaties is ontstaan vanuit verschillende bewegingen en ontwikkelingen die een organisatie heeft doorgemaakt. Veel van de noodzakelijke ingrepen in het applicatielandschap hebben een hoge urgentie en vragen een snelle implementatie. Het lijkt voor veel organisaties moeilijk om hierbij te (blijven) ontwikkelen in lijn van een vooropgezette architectuurvisie. In drie rondetafelsessie is het onderwerp ‘architectuurvisie’ behandeld. Er is hierbij ingegaan op de onderwerpen: 1. Strategische vereisten, uitgangspunten en hun rationale in de visie (=droom) 2. Architectuurprincipes en strategieën (=plan) 3. Praktische hobbels In de gesprekken zijn deze onderwerpen besproken en verder uitgediept. Er is door de deelnemers aangegeven dat met het uitwerken van deze onderwerpen een goede weergave van de levende ‘architectuurvisie’ van organisaties kan worden verkregen. 4.1 Strategische vereisten, uitgangspunten en hun rationale in de visie (=droom) Om inzicht te krijgen in de positie die de architectuurvisie heeft binnen organisaties, wordt een inventarisatie onder de aanwezigen gedaan om een beeld te krijgen van de heersende strategische vereisten en uitgangspunten. Wat hierbij opvalt is een flink aantal overeenkomsten in de genoemde vereisten. Het lijkt dat heel veel organisaties op zoek zijn naar oplossingen voor vergelijkbare problemen en op een groot aantal vlakken dezelfde strategische vereisten hebben om tot een werkbaar applicatielandschap te komen. De vaak genoemde strategische vereisten zijn: Businessconnectiviteit en connected products (bij Philips hebben veel producten een IP-adres). Ontwikkelingen hebben de beweging om te focussen op verbinden. Dit betreft samenwerkingsverbanden, interactie met klanten, leveranciers, overheden en andere maatschappelijke organisaties maar ook het gebruiken van ‘cloud’ dienstverlening. Dus moet connectiviteit in alle strategische vereisten zijn verankerd. Waarde en herkenbaarheid. Naast de genericiteit is er behoefte aan voor de organisatie expliciet benoemde waarde en herkenbaarheid. Dit betekent dat er met name in de rationale gezocht wordt naar expliciet benoemde waarde, herkenbaarheid in vocabulaire, 9
verbinding met producten en/of processen, concrete relaties met de overige architectuurgebieden. Differentiatie zit in data, niet zozeer in applicaties. Beschikbare data en het vermogen om data te combineren en interpreteren, maken het verschil. Dit betekent dat zowel het onderkennen van mogelijkheden om data te verkrijgen als het kunnen combineren en interpreteren een strategische vereiste zijn. Adaptiviteit. ‘Business verandert over night’. Doordat gevraagde aanpassingen in de huidige situaties vaak moeizaam en tijdrovend zijn, streven veel organisaties naar een betere flexibiliteit. Uitdagingen bij het definiëren van gevraagde flexibiliteit zijn om vast te stellen welke delen stabiel moeten zijn en welke delen veranderlijk moeten zijn. Dit betekent vaak dat er gestreefd wordt naar configureerbare oplossingen. Dit punt werd geïllustreerd door een voorbeeld bij Shell waar door politieke verschuivingen een olieproject van de ene op de andere dag een andere context qua zeggenschap kreeg. Systemen voor rechten en toegangsbeheer moesten hier ‘over night’ op kunnen reageren. Rationalisatie. De huidige situatie kenmerkt zich vaak door ‘overlap’, ‘dubbelen’, ‘hoge technologische diversiteit’ en ‘tijdelijke oplossingen’, waarbij vrijwel alle organisaties aangeven geen volledig inzicht te hebben. De architectuurvisie op het applicatielandschap moet bijdragen aan een betere doelmatigheid en moet oplossingen genereren die bijdragen aan een betere fit met de bedrijfs- en ITprocessen. Complexiteitsreductie. De huidige situatie is vaak dusdanig complex dat er veel specifieke kennis nodig is. Wijzigingen kosten veel werk en kennen een hoog afbreukrisico. Er zijn (te) veel afhankelijkheden die implementaties tijdrovend en ingewikkeld maken. Ook overwegingen over welke kennis essentieel is om zelf in huis te hebben en welke kennis als commodity kan worden aangemerkt, zijn hierbij van belang.
Een aantal meer specifieke strategische vereisten: Klantgericht werken. In alle te maken keuzes staat het gezichtspunt vanuit het klantperspectief centraal. Dit betekent bijvoorbeeld een keus voor direct contact met een klantmedewerker en geen callcenter. Productgericht werken. In alle te maken keuzes staat een product of de impact op het productportfolio centraal. Schiphol: Focus op ‘ruimte’ en ‘oppervlak’. Bij iedere beslissing over bedrijfsprocessen wordt gekeken naar het beslag op ruimte, verruiming van ruimte en het effect op de beschikbaarheid van de bestaande ruimte. ABN AMRO: BIAN-standaardisatie van de architectuur van banken is met name gericht op de IT-leveranciers en het afdwingen van standaardisatie. Het beoogde resultaat is hierbij vooral een kosten- en risicoreductie. Als verklaring van bovenstaand verkregen inzicht worden een aantal vaststellingen gedaan: 10
1. De huidige situatie met het bijbehorende landschap is ontstaan in een tijdperk met technische mogelijkheden en onmogelijkheden, waarin met schaarse resources aan oplossingen is gebouwd. Deze beperkingen hebben geleid tot vergelijkbare landschappen met vergelijkbare problematiek die vergelijkbare strategische vereisten heeft voor noodzakelijke veranderingen. 2. Elke organisatie is in concurrentie en dit is door een aantal ontwikkelingen zoals de globalisering alleen nog maar heftiger geworden. Dit betekent dat organisaties met elkaar in dezelfde markt met vergelijkbare concurrentiemodellen acteren en derhalve op dezelfde high level topics uitkomen. Accenten kunnen het verschil maken. Het is opmerkelijk te constateren dat nieuwe toetreders tot bestaande markten, zoals de KNAB-bank, toch weer met dezelfde beperkingen geconfronteerd worden en derhalve nu al vergelijkbare strategische vereisten hebben. 4.2 Architectuurprincipes en strategieën (=plan) Vervolgens zijn de voor de architectuurvisie geldende principes en strategieën geïnventariseerd. Ook hier worden weer door een groot aantal organisaties steeds de zelfde principes gehanteerd. Het grote verschil zit in de manier waarop de governance is ingericht. Hierbij is als meest belangrijke factor de executiekracht benoemd. Voor heel veel organisaties geldt dat 80% of meer van het beschikbare budget aan het onderhoud op de legacy wordt besteed. Een aangedragen voorbeeldstrategie ‘besteed maximaal 20% van het beschikbare budget aan legacy’, heeft bijgedragen aan een verbeterde innovatiekracht. Implementatie van architectuuraudits en de bijbehorende handhaving dat bevindingen binnen 6 maanden opgelost moeten worden, is ook een werkende strategie gebleken. Er wordt geconstateerd dat heel veel principes getuigen van ‘Hollandse nuchterheid’. Het gaat vooral over vakmanschap. Een veelgenoemd belangrijk principe is: ‘Opruimen hoort erbij’. Het is bij veel bedrijven zo dat de innovaties na implementatie worden overgedragen aan de beheerafdeling. Het bijbehorende opruimen van oude omgevingen, proefimplementaties en bijbehorende hardware-omgevingen wordt dan overgelaten aan de operatie, die daar vaak niet aan toe komen. Voordeel van een ‘sandbox’ omgeving in de cloud is dat hij zich vanzelf opruimt. 4.3 Praktische hobbels (=uitvoering) Welke praktische hobbels komen organisaties tegen waardoor het moeilijk is de strategische vereisten te implementeren? Ook hier zien we weer veel overlap. Als belangrijke hobbels worden de volgende issues genoemd: Legacy. Het is een groot probleem om de legacy op te ruimen. Hiervoor worden grote programma’s met implementaties van ERP suites doorgevoerd. Maar ook ERP wordt weer vervangen middels grootschalige programma’s. Zelfs bedrijven die ‘green field’ starten (denk aan BINCK en Alex), hebben binnen ‘no-time’ een legacy opgebouwd. Muiderslot kan niet voldoen aan bouwbesluit 2014. Met andere woorden: je kunt niet verwachten dat oude applicaties aan de moderne eisen voldoen en dat moet je ook niet met alle geweld willen nastreven. Legacy vraagt een eigen aanpak en werkwijze. 11
Het oplossen van de huidige problematiek is onmogelijk met de huidige governance-modellen. Er is een substantiële verandering nodig op het gebied van governance. Het komen tot innovatie en implementatie is onderhevig aan het vigerende bedrijfspolitieke systeem, is ook gebonden aan coalitievorming en het doen van concessies waardoor niet wenselijke situaties worden gecreëerd. Dit maakt het vaak lastig om strategische kantelingen door te voeren, zoals van ‘productgericht’ naar ‘distributiegericht’. De praktijk is veel modderiger dan de discussie van vanmiddag. Er is heel veel kennis nodig die vaak ontbreekt, het is gewoon heel veel werk en het bij het nodige ‘tussendoor’ worden geregeld.
4.4 Samenvattend Organisaties hanteren voor een groot deel een vergelijkbare architectuurvisie om tot een applicatielandschap te komen. De essentie zit echter niet in de gedefinieerde architectuurvisie, maar in een drietal zaken: 1. Governance en executiekracht. De manier waarop een organisatie in staat is de implementatie te managen, bepaalt de mate waarin de strategische vereisten met succes kunnen worden geïmplementeerd. 2. Differentiatie zit in de data en in de business capabilities. Eigenlijk maakt het applicatielandschap en de keuze van de ERP en / of applicaties die worden gebruikt, niet zoveel uit. Het essentiële is de data waarover beschikt kan worden en het vermogen om daar iets mee te doen. Daarnaast zijn bedrijven (noodzakelijk!) anders, omdat ze zich richten op hun specifieke core capabilities, waarmee ze zich van hun concurrentie willen onderscheiden. Er is op dit punt geen generiek industriemodel te maken waar ieder bedrijf op past. 3. Legacy is beperking. In veel organisaties is op vergelijkbare wijze legacy en onnodige complexiteit opgebouwd die beperkend is voor het realiseren van de visie op het applicatielandschap. Rationalisatie is bij al die organisaties een belangrijk aandachtspunt.
5. Architectuurmodellen van applicatielandschappen gefaciliteerd door Marc Lankhorst en Jesper Taal Architecten zijn vaak bezig met het maken van architectuurmodellen. In deze modellen wordt op een gestructureerde manier data weergegeven die vervolgens communiceerbaar moet zijn. Een model is daarom ook meer dan alleen een plaatje. Het dient een bepaald doel en toont alleen de relevante, gestructureerde data voor een bepaalde stakeholder. Maar welke informatie toon je voor bepaalde vraagstukken? En tegen welke barrières loop je aan als architect? In deze sessies zijn drie thema’s behandeld die alle te maken hebben met applicatielandschappen: (1) analyse van bestaande landschappen, (2) roadmapping en portfoliomanagement en (3) complexiteitsreductie.
12
5.1 Analyse van bestaande landschappen Het is belangrijk om inzicht te hebben in de huidige situatie. Dat geldt natuurlijk ook voor het applicatielandschap. Veel bedrijven schieten echter door in het in kaart brengen van deze huidige situatie. De deelnemers van de ronde tafel erkennen dat het voor architecten de voorkeur heeft om de toekomstige situatie te schetsen en van daaruit te bekijken wat de huidige situatie is (in plaats van andersom), om je niet te verliezen in een al te uitgebreide ‘boekhouding’ van de as-is en je in het denken over de toekomst niet teveel te laten inperken door het heden. Ook is de gewenste informatie en de weergave van as-is en to-be verschillend (as-is: feiten, to-be: beelden). Maar welke informatie gebruik je? En welke vorm van visualisatie / notatiewijze wordt dan gebruikt? Aan de rondetafelsessie werd gebrainstormd welke informatie benodigd is bij het in kaart brengen van de bestaande applicatielandschappen. De brainstorm leidde tot de volgende clusters van informatie: Lifecycle-management Welke software-versies zijn momenteel in beheer? Wat is de legacy? Welke applicaties worden momenteel uitgefaseerd? Applicaties en de functionaliteiten Welke applicaties hebben we? Welke bouwblokken per applicatie? Welke bedrijfsfuncties worden ondersteund? Wat zijn de non-functional requirements (performance, reliability, changeability)? Huidige situatie Hoe ziet de systemenlijst eruit? En zitten die ook in het CMDB? Eigenaarschap Wie zijn de eigenaren van de applicaties? En wie beheert de applicaties? Kosten Wat zijn de huidige kosten, zoals beheerkosten, onderhoudskosten, licentiekosten en ontwikkelkosten? Data Welke data wordt door welke applicatie ontsloten? En wat zijn de gegevensdefinities? Processen en functies Welke bedrijfsfuncties en / of bedrijfsprocessen ondersteunen de applicaties in het huidige landschap? Services en afhankelijkheden Welke services worden gebruikt (catalogus)? En wat zijn de relaties tussen applicaties onderling? Helikopterview Waar bevindt een applicatie zich in het geheel? In welk domein / business unit wordt deze gebruikt? En wat zijn de relaties tussen de applicatie en business en tussen applicatie en infrastructuur? Besturing Wat zijn de bedrijfsprincipes, indien aanwezig? En wat zijn best practices voor het in kaart brengen van het landschap? Bovenstaande clustering geeft weer welke informatie gemoeid is met het in kaart brengen van het huidige applicatielandschap. Maar hoe geef je deze informatie weer? De deelnemers aan de rondetafel erkennen dat het weergegeven van alle clusters in één enkel model niet mogelijk is. Het is dus afhankelijk van de 13
stakeholders die je wilt bedienen maar ook het doel dat je wilt bereiken met het model. In de markt zijn diverse tools beschikbaar voor het in kaart brengen van bovenstaande clusteringen. Dat is fijn maar tegelijkertijd ook een gevaar. De crux van het verhaal zit juist in de samenhang van deze informatieclusters. Enkele deelnemers geven aan dat ze dat doen door middel van een koppelmodel, zoals bijvoorbeeld een domeinarchitectuur. Wat het analyseren van bestaande landschappen lastig maakt, is dat er veel disciplines betrokken zijn. Terwijl die in het dagelijkse werk weinig tot geen relatie met elkaar hebben. Dit heeft als gevolg dat er verschillend naar vraagstukken wordt gekeken. Door een deelnemer werd het volgende voorbeeld aangedragen: Ten behoeve van het in kaart brengen van het huidige applicatielandschap werken architecten samen met beheerders om een inventarisatie te doen van de huidige applicaties. Hierbij was de term ‘applicatie’ niet eenduidig waardoor meerdere interpretaties ontstonden van het huidige applicatielandschap. Daarnaast komt het voor dat modellen niet geactualiseerd zijn waardoor er geen correct beeld is van de huidige situatie. Hierdoor dient de huidige situatie opnieuw in kaart te worden gebracht waarmee tijd, geld en kosten gepaard gaan. Als laatste werd genoemd dat de doelen van analyses vaak verschillen. De manier van communiceren is afhankelijk van het doel waardoor er vrijwel nooit één model te maken is voor een bepaald vraagstuk. 5.2 Roadmapping en portfoliomanagement Net als het in kaart brengen van het huidige applicatielandschap, zijn organisaties bezig met het inrichtingen van portfolio’s en sturen door middel van roadmapping. Ook hiervoor geldt dat je bepaalde informatie nodig hebt om tot deze producten te komen. Aan de deelnemers van de rondetafel is gevraagd om aan te geven welke informatie ze hiervoor gebruiken. Hieruit kwamen de volgende informatie clusters: Link met businessstrategie Waar wil de organisatie naar toe? En welke doelen zijn daarin geformuleerd? Is er een businessinformatieplan (BIP) aanwezig? En wat is de strategische positionering van diverse applicaties? Huidig applicatielandschap (As-Is) Welke applicaties hebben we nu? Welke functionaliteiten bieden deze applicaties? Welke legacy hebben we nu? En hoe toekomstbestendig zijn al deze applicaties? Samenhang van applicaties Hoe zijn de verschillende applicaties met elkaar verbonden? Waar zitten die afhankelijkheden? En hoe zijn deze applicaties verbonden met ketenpartners en klanten? Kosten en baten Wat zijn de huidige kosten? Zoals beheerkosten, onderhoudskosten, licentiekosten en ontwikkelkosten? Data Welke data wordt waar gebruikt? En door welke applicaties wordt deze ontsloten? Hoe ziet het datalandschap eruit? 14
Toekomstige situatie (To-Be) Wat is de toekomstschets met betrekking tot de applicaties? Is daar een duidelijke visie op? Hoe relateert deze aan de roadmaps van vendors? Verandercapaciteit Zijn we in staat om al deze verandering ook daadwerkelijk uit te voeren, niet alleen in mankracht maar ook in geld en tijd? Is de business hier klaar voor? En is de IT-afdeling hier ook klaar voor? Relatie met product en proces Welke applicaties ondersteunen welke (kritische) processen? En hoe verhoudt dit zich tot de producten en diensten die de organisatie levert? Eigenaarschap en beheer Wie is eigenaar voor een applicatie? Wie en waar wordt de applicatie beheerd?
Tijdens de sessie kwam de volgende vraag naar voren: Hoe ver wordt vooruit gepland in de verschillende aanwezige organisaties? Uit de rondetafelsessie bleek dat veel organisaties tussen de 2 à 3 jaar vooruit proberen te plannen. Er wordt echter wel rekening gehouden met de planbaarheid van verschillende architectuurcomponenten. Interessant hierbij is dat sommige componenten zich minder goed lenen voor meerjarige plannen. Voorbeelden hiervan zijn websites en social media. Deze worden dan ook ad hoc gepland. Diverse deelnemers gaven aan dat bijvoorbeeld ERP-systemen zich wel lenen voor meerjarenplannen. Een andere deelnemer gaf aan dat er in zijn organisatie agile wordt gewerkt om de kortetermijndoelen te behalen. Op portfolioniveau wordt echter niet agile gewerkt. De rest van de deelnemers herkende dit beeld. Verschillende delen van de informatievoorziening kennen hun eigen ritme, wat Gartner ‘pace layering’ noemt. Om portfolio’s te koppelen speelt architectuur een belangrijke rol. Maar wat voor modellen, en met name welke informatie gebruik je daarvoor? Afhankelijkheden die daarvoor in kaart gebracht moeten worden lijken daarbij essentieel. Dit wordt vaak gedaan door het gebruiken van verschillende kleuren en het schetsen van diverse scenario’s. Hierdoor worden de koppelvlakken duidelijk. Gesprekken met de ‘business’ moeten uitwijzen welke zaken als urgent en minder urgent kunnen worden beschouwd. Afhankelijkheden worden vaak in kaart gebracht door architecten en portfoliomanagers. Deze laatste focussen zich vooral op planning en kosten. Data om deze koppelvlakken in kaart te brengen worden verschillend bijgehouden door organisaties. Enkele organisaties gaven aan hier veel tijd in te steken. Als voorbeelden werden genoemd dat er 10 tot 30 attributen per applicatie worden bijgehouden en dat een dergelijke lijst eenmaal per jaar wordt bijgewerkt. Hiervoor is diverse tooling beschikbaar. Andere organisaties gaven aan dit niet te doen en tevens niet beschikken over een CMDB om dit bij te houden. Een van de deelnemers gaf aan dat hij geïnteresseerd was in de toepasbaarheid van ArchiMate modellen om roadmaps te maken. In ArchiMate zijn daarvoor de ‘Motivation’ en ‘Implementation and Migration’ extensies beschikbaar die het mogelijk maken om enerzijds business doelen / requirements te modelleren en anderzijds plateaus (transities) te bepalen. Deze beide extensies vormen een goed uitgangspunt om met ArchiMate roadmapping toe te passen binnen een organisatie.
15
5.3 Complexiteitsreductie Het reduceren van de complexiteit van het gehele IT-landschap is in veel organisaties aan de orde van de dag. Dat geldt ook voor het reduceren van het aantal applicaties. Uit het voorstelrondje bleek dat veel deelnemers van de rondetafel onderkennen dat dit speelt in de aanwezige organisaties. Ook bij dit thema is gevraagd om op te schrijven welke informatie de architecten gebruiken om complexiteit in kaart te brengen en uiteindelijk te reduceren. Dit gaf de volgende informatie clusters: Eigenaarschap Zijn er eigenaren toegewezen aan de huidige applicaties? En wie zijn die eigenaren? Wie beheert de applicatie? Waar vind dit beheer plaats? Ketens en koppelingen Hoe zijn de verschillende applicaties met elkaar verbonden? Waar zitten die afhankelijkheden? Welke services zijn met elkaar verbonden? Welke applicatieketens zijn er per klant en / of bedrijfsproces? En wat is de relatie met de procesketens? Organisatie / business Hoe is de organisatie georganiseerd? Zijn er recente gebeurtenissen die voor complexiteit zorgen (bijv. overnamen)? Zijn er meerdere ‘bedrijven’ binnen het concern? Wat zijn de (kritische) bedrijfsprocessen? Toekomstige situatie (To-Be) Hoe ziet het toekomstige applicatielandschap eruit? Welke keuzen zijn hierin gemaakt die de complexiteit beïnvloeden? Is er een roadmap beschikbaar? Functionaliteit en kwaliteit Welke functies worden door welke applicatie aangeboden? En wat is de kwaliteit van deze functies? Wat is per applicatie de functionele en technische kwaliteit (APM)? Uitgangsinformatie Wat is het te beschouwen gebied voor de complexiteitsreductie? Welke informatie kan eruit het CMDB worden gehaald? Worden er complexiteitsmetrieken toegepast? Kosten en baten Wat zijn de huidige kosten, zoals beheerkosten, onderhoudskosten, licentiekosten en ontwikkelkosten? En wat wijst een kosten/baten-analyse van de applicaties uit? Infrastructuur Welke platformen zijn er? Welke applicatie draait op welk platform? Hoeveel leveranciers zijn er? Aan tafel kwam ter sprake dat complexiteitsreductie vaak samenhangt met het reduceren van kosten. Een logisch gevolg is dat de allocatie van verschillende soorten kosten per applicatie noodzakelijk is. Een van de deelnemers gaf aan dat er gewerkt wordt met een gedetailleerd kostenmodel binnen zijn organisatie. Deze kosten worden gecommuniceerd door middel van grafieken. Deze deelnemer gaf aan dat dit goed wordt ontvangen bij stakeholders, met name op directie niveau. De deelnemers bespraken tevens de definitie van complexiteit. In deze discussie werd verwezen naar werk van Roger Sessions, die bepaalde metrieken heeft ontwikkelt om complexiteit van architecturen te meten aan de hand van business functions, services en data. Diverse deelnemers toonde interesse in het werk van 16
Sessions. Ook de verwante aanpak van ‘normalized systems’ werd genoemd, die hetzelfde beoogt: opdelen van architecturen in de ‘juiste’ blokken. Om complexiteit te communiceren wordt er vaak gewerkt met zogenaamde ‘heat maps’. Deze vorm van visualisatie is volgens de deelnemers erg geschikt om de data te presenteren aan diverse stakeholders omdat het inzichtelijk maakt waar de knelpunten zitten. 5.4 Samenvattend In de drie sessie-rondes komen een hoop gemeenschappelijkheden terug, zoals in de voorgaande beschrijving te zien valt. Modellen kunnen op verschillende gebieden een belangrijke rol spelen bij het managen van het applicatielandschap. In elk geval de volgende hoofdgroepen van toepassingen springen eruit: Inzicht geven in de complexiteit van de bestaande situatie, voor architecten maar ook voor andere doelgroepen. Rekenen aan / analyseren van de huidige situatie, in termen van bijvoorbeeld kosten maar ook rond complexiteit en (functionele en technische) kwaliteit. Gericht op het opleveren van managementinformatie om beslissingen te ondersteunen. Plannen van veranderingen, rekening houdend met afhankelijkheden in het landschap. Wat opviel in de discussie, is dat er grote verschillen in volwassenheid zijn tussen de deelnemende organisaties. Wel was men het er in het algemeen over eens dat voor grotere organisaties het gebruik van modellen en aanverwante middelen onontbeerlijk is om greep te krijgen / houden op de complexiteit van applicatielandschappen. Het gebruik van bijv. excel-lijsten om applicaties te beheren stoot al snel op grenzen, vooral omdat het daarin bijna ondoenlijk is om de diverse afhankelijkheden in het landschap goed te beschrijven of analyseren. De inspanning die nodig is om de benodigde inputgegevens te verzamelen en modellen actueel te houden, wordt gezien als het belangrijkste obstakel. Gezien de omvang van de investeringsbeslissingen in applicatielandschappen is goede managementinformatie over die investeringen cruciaal.
6. Het managen van de applicatieportfolio onder architectuur gefaciliteerd door Martin van den Berg en Gert Eijkelboom Greep houden op de kwaliteit en ontwikkeling van het applicatielandschap – de applicatieportfolio – is een vraagstuk waar vrijwel iedere organisatie mee worstelt. Hoe valt het overzicht en de consistentie van de portfolio te behouden bij verandering, hoe kan veroudering van applicaties (legacyvorming) worden voorkomen, hoe kan het landschap sneller en beter worden gerationaliseerd, hoe kunnen de kosten in de hand worden gehouden en welke invloed heeft cloud computing, met bijvoorbeeld software-as-a-service (SaaS), hoe beheers je de cruciale relatie tussen de applicaties en de gegevens die je daarmee onderhoudt en ontsluit, en wat zijn de gevolgen voor het beheer van de applicatieportfolio. Dit soort vragen vormen onderdeel van het managen van de applicatieportfolio. Het roept ook de vraag op welke rol de (enterprise) architectuurfunctie van een organisatie kan en zou moeten spelen bij het applicatieportfoliomanagement. 17
In papers over applicatieportfoliomanagement staan veelal aspecten als het beheersen van de complexiteit en het tegengaan van legacyvorming centraal. Naast het achterhalen van de oorzaken van de groeiende complexiteit van de applicatieportfolio reiken ze handvatten aan om de complexiteit van de portfolio objectief meetbaar en daarmee objectief inzichtelijk te maken: meten is weten. De volgende lijst toont een aantal voorbeelden van papers over applicatieportfoliomanagement onder architectuur. Motto
Inzichten
Wie
Waar
Slopen onder Architectuur
Legacy is niet louter een technisch probleem, maar ook een managementvraagstuk. Een applicatie staat niet op zichzelf, maar heeft horizontaal (interfaces) en verticaal (stack) relaties, veroudering kan van alle kanten komen.
Martin vd Berg, Jan Truijens (2003)
http://imwww.fee.uva.nl/~p v/PDFdocs/2003-14.pdf
Er is geen systematische aanpak waarbij alle viewpoints worden geïntegreerd die van belang zijn bij applicatieportfolio-management. EA-viewpoints schieten tekort om een applicatieportfolio te managen op het gebied van integratie en aggregatie.
Gerold Riempp, Stephan GieffersAnkel (2007)
http://link.springer.com/arti cle/10.1007/s10257-0070052-2
Application portfolio management
Application Complexity
Vier typen complexiteit in de applicatie-architectuur: Onderlinge afhankelijkheden, Diversiteit van technologieën, Afwijking van technologiestandaards, Overlap en redundantie.
Martin Mocker (2009)
http://www.researchgate.n et/profile/Martin_Mocker/p ublications
IT Complexity
Het meten en beheersen van IT-complexiteit is mogelijk, maar kost de nodige inspanning. De structurele complexiteit van een systeem wordt bepaald door aantal en diversiteit van zowel de samenstellende componenten als het aantal en diversiteit van de relaties tussen die componenten.
Capco en Commerzbank (2011-2012)
http://www.capco.com/cap co-institute/researchthoughts/it-complexitymodel-measure-andmaster
Het applicatieportfoliomanagementproces geeft een holistische blik op het applicatielandschap en is van essentieel belang om weloverwogen beslissingen te nemen over de applicatie-
Lianne Bodenstaff, Dick Quartel, BiZZdesign (2013)
http://www.bizzdesign.com /blog/tag/Application+Portf olio+Management
Application Portfolio Management
18
Application Landscape Report 2014
portfolio. EA levert het fundament voor het APM-proces. Het is niet langer de vraag of je je applicatielandschap moet rationaliseren, maar wanneer en hoe: de kloof tussen de ambities en de staat van het landschap wordt meer dan ooit gevoeld. Niet alleen is wederzijds begrip tussen business en IT noodzakelijk, maar ook meer radicale scenario’s en industrialiseren en standaardiseren.
Ron Tolido, Capgemini (2014)
http://www.nl.capgemini.co m/bronnen/applicationlandscape-report-2014
6.1 Wat is een applicatieportfolio? Het geheel aan businessapplicaties dat een organisatie geïmplementeerd heeft is de applicatieportfolio of applicatielandschap. Een applicatieportfolio is in functionele zin ook op te vatten als een register van applicaties met informatieattributen over relevante aspecten van de individuele applicaties en hun eventuele onderlinge samenhang. De landschapbenadering leeft steeds meer, onder meer doordat applicaties steeds meer onderdeel vormen van ketens die zich ook buiten de perimeter van een organisatie kunnen uitstrekken. Overigens is het van belang te realiseren dat beheer en kwaliteit van data zoveel mogelijk los moeten worden beschouwd van de applicaties waarmee deze data worden onderhouden. Deze scheiding tussen data en applicaties is evident. Data is het enige echt relevante, applicaties komen en gaan. Een deelnemer definieerde een applicatie als ‘iets dat data door de war haalt’. 6.2 Samenstelling van de applicatieportfolio Uit een korte inventarisatieronde bij de deelnemers blijkt dat het aantal applicaties uiteenloopt van enkele tientallen tot meer dan 6000. Hoewel de absolute aantallen per organisatie op zich weinig zeggen, is wel duidelijk dat de bedrijfsomvang zeker niet de enige bepalende factor is. Het aantal applicaties en de samenstelling van de portfolio weerspiegelen niet alleen de aard en het type, maar ook de organisatiestijl en cultuur van een organisatie. Daarnaast geldt dat de IT-functie van een organisatie zelden een compleet beeld heeft: naast de bekende en beheerde applicaties zijn er ook de (persoonlijke) applicaties die zich aan de waarneming van de IT-functie onttrekken. Hoe de verhouding tussen de bekende en ‘onbekende’ applicaties is, verschilt uiteraard per organisatie. Sommigen spreken over de eerste categorie als het ‘topje van de ijsberg’. Met de introductie van (public) cloud computing, in feite een vorm van outsourcing met bijvoorbeeld software-as-a-service (SaaS), is het eigenlijk niet meer zo relevant om over aantallen applicaties te spreken en krijgt portfoliomanagement ook andere accenten. Services komen in de plaats van applicaties en het is de verantwoordelijkheid van de cloud-serviceprovider hoe de services in elkaar steken. Voor de interne organisatie komt de focus dan te liggen op het managen van de ketenprocessen of portalen waarin deze services gebruikt worden. Uiteraard dient 19
het beheer van services adequaat ingericht te zijn, met nadruk op contract- en SLAbewaking. 6.3 Laat een applicatieportfolio zich managen? Een overgrote meerderheid van de deelnemers is er van overtuigd dat een applicatieportfolio zich laat managen. Tegelijkertijd blijkt de praktijk weerbarstig. Externe en interne factoren, zoals wet- en regelgeving, technology-push, versiebeleid van leveranciers, reorganisaties en kostenbeheersingsprogramma’s, bepalen in hoge mate de ontwikkeling van de portfolio en beperken aldus de beslissingsruimte van een organisatie. Tussen applicatie- en projectportfolio bestaat een evidente relatie: de verandering van de eerste wordt gedreven door de tweede. Gekochte applicaties (‘commercial-off-the-shelf’ software) laten zich het meest eenvoudig beheren. Voor services (uit de cloud) is dat al wat lastiger, maar nog steeds goed te doen. Zelf ontwikkelde applicaties zijn het lastigst en van die categorie vooral het deel dat zich in feite aan de waarneming, beheer en invloed van de IT-functie onttrekt. Tot de meest cruciale indicatoren van portfoliomanagement behoort informatie over de levenscyclus van de applicaties: in welke fase bevinden ze zich, met kwalificaties als nieuw, mainstream en uit te faseren (legacy). Een essentiële randvoorwaarde voor applicatieportfoliomanagement is een goede applicatieregistratie. Goed applicatieportfoliomanagement vergt een samenspel tussen business en IT: de IT manager krijgt het niet alleen voor elkaar. De belangen van de business en de IT-functie lopen voor de korte termijn niet altijd parallel: waar de business hecht aan zaken als een korte time-to-market en gebruiksgemak, heeft de IT-manager bijvoorbeeld belang bij een reductie van de complexiteit en kosten. Uiteindelijk hebben alle partijen echter baat bij een blijvend gerationaliseerd landschap, dat in ieder geval snel genoeg mee moet kunnen bewegen met veranderingen en die het liefst vergemakkelijken in plaats van te hinderen. Het actueel houden van het portfolio moet een geborgde activiteit zijn, het moet niet zo zijn dat het wiel weer telkens opnieuw moet worden uitgevonden. 6.4 Instrumenten Zijn er instrumenten om het applicatieportfoliomanagement te ondersteunen en verbeteren? Zoals enkele papers aangeven, zijn kwantitatieve indicatoren te bedenken die een goede aanvulling vormen op een intuïtieve of ervaringsbenadering. Kwantitatieve indicatoren zijn nodig om een objectieve scoring te geven van bijvoorbeeld de mate van complexiteit. Informatie vanuit zoveel mogelijk invalshoeken is nodig om tot het juiste inzicht in de gezondheid van de applicatieportfolio te komen: architectuur, business drivers, integrale eigendomskosten (TCO), levenscyclus (life cycle management) en opgebouwde ‘technical debt’. Uit een van de papers (Mocker) blijkt dat alleen op de dimensie ‘onderlinge afhankelijkheid’ (interdependency) een causaal verband valt te leggen tussen oorzaak en impact van complexiteit van de applicatieportfolio. De meeste deelnemers herkennen dit beeld. Dat neemt niet weg dat de overige dimensies diversiteit van technologieën, afwijking van de technologiestandaards van de organisatie, overlap en redundantie - ook zorgpunten zijn.
20
Rationalisatie en consolidatie van een applicatieportfolio zijn in de praktijk taaie trajecten. Een van de deelnemers heeft ervaring met een complexiteitsmonitor van de portfolio. Hoewel die zeker waardevolle inzichten verschafte, werden de consequenties niet echt onderkend (selectieve ontkenning), waardoor een aanpak van de te hoge complexiteit uiteindelijk nauwelijks van de grond kwam. Kortom, een goede analyse alleen is niet zaligmakend: het vereist actief programmamanagement en commitment om de portfolio ook daadwerkelijk te verbeteren. Voldoende ‘sense of urgency’ in de gehele organisatie is essentieel. Dat gevoel van urgentie ontstaat onder meer als je als architect kunt onderbouwen dat de samenstelling van het applicatielandschap de realisatie van de organisatiedoelstellingen hindert. 6.5 Besluitvorming over de ontwikkeling van de applicatieportfolio en de rol van de (enterprise) architect daarbij Het is uiteindelijk de business en niet de IT-functie die besluit over de ontwikkeling van de applicatieportfolio: ‘wie betaalt, bepaalt’. Hoewel de rol, belang, (in)formele invloed en verlangde inbreng van de enterprise architect per organisatie verschilt, beslist een enterprise architect nergens over de ontwikkeling van het applicatielandschap. Van de architect wordt vooral verwacht dat die alles aan elkaar weet te knopen en relevante inzichten inbrengt voor de besluitvorming. Bij de besluitvorming over applicaties overheerst doorgaans een silo-blik, dat wil zeggen een min of meer geïsoleerde verticale benadering. Een horizontale blik over domeinen en applicaties heen is zelden de dominante view. Vervult de (enterprise) architect de rol van consultant of is hij verantwoordelijk voor de oplossing? Architecten bewegen zich tussen deze twee uitersten. De rol van de architect in het applicatieportfoliomanagementproces is bij uitstek het in kaart brengen van mogelijke keuzen en hun consequenties en daarmee te zorgen voor transparantie. Een architect is daarbij niet de vrijblijvende consultant. Op basis van een organisatorische en technologische visie beïnvloedt en verbindt de architect de betrokken belanghebbenden, zoals beslissers, gebruikers, ontwikkelaars, beheerders en leveranciers. Een visieloze architect heeft geen toegevoegde waarde voor de organisatie. Uiteraard varieert de inbreng van de architect per fase van het besluitvormingsproces over de ontwikkeling van de applicatieportfolio. Elke fase heeft eigen accenten waar de architect zijn inbreng op af moet stemmen. Soms is het een kwestie van ‘choose your battle’. Als enterprise architect kun je niet betrokken zijn bij iedere individuele aanschaf of bouwbesluit voor een applicatie. Aan filtering valt niet te ontkomen. Een architectuurtoetsingsproces, formeel of informeel, is een belangrijk middel, Nieuwe applicaties en ontwikkelingen worden onder meer beoordeeld op de mate waarin ze passen in de architectuurkaders, afhankelijkheden met andere applicaties en mogelijk overlap. Van een architect mag worden verwacht dat hij, al dan niet via het informele circuit, weet wat er speelt. Voorbeelden van concrete bijdragen van enterprise architecten bij applicatieportfoliomanagement: Segmenteren van de applicatieportfolio, bijvoorbeeld per businessdomein. De bijdrage en daarmee de waarde van de applicatieportfolio aan het realiseren van de bedrijfsdoelen en bedrijfsstrategie duidelijk maken.
21
Inzicht verschaffen in de staat van het applicatielandschap, zoals de relatie tussen procesarchitectuur en applicaties, de onderlinge afhankelijkheden tussen applicaties en de eigendomskosten. Bijhouden en bewaken van de architectuur-compliance van applicaties. Bijdragen aan het formuleren van een visie: in welke richting en met welk tempo moet de portfolio zich ontwikkelen. Input en advies bij investeringsbeslissingen. Uitspraken doen over de mate waarin een applicatie past in de architectuur: ‘architect labeled compliance’.
6.6 Best practices bij applictieportfolio-management Een inventarisatie bij de deelnemers leverde een groot aantal best practices op. De belangrijkste zijn: Bijhouden van een centraal (‘single point of truth’) register waarin de relevante attributen over de applicaties worden bijgehouden. Koppelingen met een configuratiemanagement-database (CMDB) en de enterprisearchitectuurmodellen zijn maximaal aan te bevelen. Tot de attributen van het applicatieregister behoren: afhankelijkheden tussen applicaties, eigendomskosten (direct en indirect), ondersteunde processen en diensten van de organisatie, relatie met data, levenscyclus, leveranciers en contactpersonen. Zorg voor een heldere bedrijfsstrategie die het mogelijk maakt aan te geven in hoeverre de applicatieportfolio voldoende dienstbaar is aan deze strategie. Zorg voor duidelijk belegde verantwoordelijkheden, inclusief functiescheiding en ‘checks & balances’ voor applicatie life cycle management en data. Regel in ieder geval de verantwoordelijkheden en eigenaarschap van de applicaties. Grote bedrijfsveranderingen, zoals fusies, zijn een goed moment voor rationalisatie van de portfolio. Schokeffecten, zoals incidenten, kunnen ertoe leiden dat een momentum ontstaat voor een rationalisatie van de applicatieportfolio. Consolidatie van applicaties heeft pas zin na een rationalisatieslag. Als bij een applicatie onduidelijk is wie de eigenaar ervan is of het vermoeden bestaat dat hij niet tot nauwelijks gebruikt wordt, kan het ‘piepsysteem’ een probaat middel zijn: ‘zet de applicatie uit’ en wacht af of iemand aan de bel trekt. Maak de consequenties van keuzes op het gebied van de portfolio inzichtelijk. Neem zoveel mogelijk invalshoeken mee bij de afwegingen en blijf altijd je gezond verstand gebruiken. Bedenk dat een applicatie vrijwel nooit geheel op zich zelf staat. Er is vrijwel altijd een samenhang met andere applicaties en processen. Geef per applicatie(functie) in het applicatieportfolioregister aan wat de status ervan is in de levenscyclus: nieuw – mainstream – genomineerd om uit te faseren. Voer applicatie life cycle management studies uit per applicatie. Zorg voor een goede relatie met de leveranciers, opdat goed inzicht bestaat in de ontwikkelingsrichting van een applicatie. Kweek kostenbewustzijn: stel de businesseigenaren van de applicaties rechtstreeks financieel verantwoordelijk en zorg voor een duidelijk inzicht in de directe en indirecte kosten van een applicatie. Voorkom wildgroei en overlap door het principe ‘één erbij is één eraf’ te hanteren. Neem in IT-(meer)jarenplannen expliciet een IT-perspectief op, onder meer door aandacht te besteden aan het voorkomen van legacy. De business zal dit niet snel op eigen initiatief doen. 22
Zorg dat de landplaats (targetapplicatie) ook financieel aantrekkelijk is om de legacy-applicatie daadwerkelijk te ‘decommisionen’. Vaak gaat dit niet vanzelf en het werkt tegen als er geen positieve business case is om de legacy-applicatie daadwerkelijk uit te zetten.
6.7 Worst practices voor het managen van een applicatieportfolio Wat werkt niet? Portfoliomanagement zonder actieve betrokkenheid van de business is kansloos. Pragmatiek moet evenwel voorop staan. Een totaalbeeld over de volledige diepte en breedte van de portfolio is onmogelijk te verkrijgen. Een essentiële randvoorwaarde is de beschikbaarheid van een doelarchitectuur en visie: zonder een bestemming is het onmogelijk de ontwikkelingsrichting van de portfolio scherp te krijgen. Het missen van signalen van bijvoorbeeld beheerders over het bereiken van het einde van de levensduur van applicaties is een serieuze bedreiging voor een goed beheer van de portfolio. Onvoldoende sturingsmechanismen, zoals een gebrekkig configuratiemanagementproces als onderdeel van het wijzigingsbeheer, en een (afgedwongen) ‘u-vraagt-wij-draaien-opstelling’ van de ITfunctie, zijn funest voor een goed portfolio management. 6.8 Slotconclusie Iedere organisatie doet in meer of mindere mate aan applicatieportfoliomanagement, waarmee nut en noodzaak vast staan. Een belangrijke rol hierin is weggelegd voor de architect, vooral door inzicht en visie in te brengen. Net zomin als de architect een vrijblijvende rol als consultant kan spelen, kan hij ook niet exclusief verantwoordelijk voor de oplossing zijn. Hoe volwassen het applicatieportfoliomanagement in een organisatie is, hangt af van veel factoren. Niet verbazingwekkend zijn onder andere organisatiecultuur, structuur, bedrijfsomvang en type van de organisatie. Portfoliomanagement staat of valt bij inzicht in de portfolio en een ingericht en nageleefd proces voor het bijhouden van de portfolio. Tijdig inzicht moet bestaan wanneer een applicatie het einde van de levensduur bereikt. De inbreng van de business is essentieel, die moet hierin betrokken zijn. Een visie op de toekomst – bijvoorbeeld in de vorm van een ‘Future State Architectuur’ – is een voorwaarde om beslissingen te kunnen nemen. Het management is gebaat bij het beschikbaar hebben van meetbare indicatoren over de kwaliteit en ontwikkeling van de portfolio, bijvoorbeeld over de mate van complexiteit. In de praktijk kost het verzamelen en bijhouden van deze informatie echter veel tijd en moeite, wat een afweging tussen methode en ‘gevoel’ noodzakelijk maakt.
7. Slotopmerkingen rondetafel Bij de mondelinge evaluatie aan het einde van de rondetafelbijeenkomst bleken er nog wat zaken die ook aandacht hadden mogen krijgen: Sourcing: pakket versus maatwerk / zelfbouw versus outsourcing / cloud De rol van de architectuur en de architect bij ‘agile’ systeemontwikkeling. In het bijzonder de architectrollen binnen het framework SAFe (Scaled Agile Framework at enterprise level) en in scrum teams. De relatie van architectuur en ‘Shadow IT’. ‘Shadow IT’ omvat de IT solutions die zonder officiële toestemming worden gebouwd en / of gebruikt, dus buiten de ITgovernance en niet compliant aan de architectuur. Maar vaak blijkt ‘Shadow IT’ een bron voor businsinnovatie te zijn. 23
De accountability van de architect, of is hij slechts een consultant. De invloed van bedrijfscultuur op de architectuur van applicaties, zowel het bruikbaarheidaspect als het belevingaspect. De rolverdeling en het krachtenspel in de driehoek ‘architect, programmamanager en de business’. De samenstelling van een architectuurteam. Welke specialisten zijn er naast de architecten nog allemaal nodig om een bruikbare architectuur te formuleren Hoe om te gaan met ‘legacy’. Legacy is vaak geen probleem, maar een gegeven waarmee nuchter en zakelijk dient te worden om gegaan.
Hoewel het architectuurdenken op applicatieniveau al relatief lang bestaat, dient er nog erg veel te worden uitgezocht op het gebied van de applicatiearchitectuur en de architectuur van het applicatielandschap. Dat blijkt ook uit het verschil van het progamma van de verschillende tafels (zie paragraaf 1 van dit verslag) en wat er bij de tafels is behandeld (zie paragraaf 3 tot en met 6). Deze NAF-rondetafel werd als bijzonder nuttig ervaren om met elkaar af te stemmen, maar een volgende bijeenkomst van het NAF dient nog veel meer de diepte in te gaan.
8. Deelnemers Aaldert Hofman (Luchthaven Schiphol), Arjan Bulthuis (DICTU), Art Ligthart (Art Ligthart Services), Bert Veldkamp (Atos), Brano Condic (UWV), Debbie Tarenskeen (Hogeschool Arnhem Nijmegen), Dolf Moonen (AkzoNobel), Egon Willemsz (UWV), Evert de Vos (Tatasteel), Gert Eijkelboom (DNB), Hans Hoogerhuis (iBridge / Randstad), Huub Bakker (Belastingdienst), Hidde Andriessen (KPMG), Jaap van der Velde (CAK), Jan Miedema (Nationale Nederlanden), Jesper Taal (BiZZdesign), Johan Krebbers (Shell), Marc Lankhorst (BiZZdesign), Marco Brattinga (Ordina), Martin van den Berg (DNB), Martin Lohmeier (Philips), Menno Gmelig Meijling (SVB), Michiel van de Sande (Ministerie van Economische Zaken), Robert van der Toorn (KPN), Sjaak Gondelach (UMC Utrecht), Stephan Hendriks (DSM), Therry van der Burgt (Rijkswaterstaat), Tinus de Gouw (Rabobank), Wiebe Wiersema (RDW), Wilko Visser (Valueblue), Wim Piksen (SNS Reaal), Wouter Schmitz (ABN AMRO).
24
