Juli/Augustus 2001: Applicatie architectuur en Applicatie integratie

Deze maand een stelling rond het inrichten van de informatie infrastructuur. Applicaties zijn daar een onderdeel van en worden vaak gezien als “waar het om draait”. Zij bieden immers de functionaliteit, ze worden “gezien en gebruikt”. Organisatie hebben vaak erg veel applicaties die niet of nauwelijks op elkaar aansluiten. Dit wordt als een probleem ervaren. Het integreren van applicaties wordt wel als een doel op zich gezien. In dat kader de volgende stelling:

---
“Een goede applicatie architectuur is dé voorwaarde om applicaties te kunnen integreren.“
---

Tenzij aan een applicatie architectuur een reeks elementen toegevoegd worden die daar feitelijk niet thuis horen zou dit een simpele manier zijn om dit soort integratieproblemen op te lossen. Jammer genoeg is dat niet zo.

De applicatie architectuur is het beeld dat we van de applicaties hebben die “onze” organisatie ondersteunen. Applicaties moeten de functionaliteit bieden die “gebruikers” nodig hebben om hun taken beter uit te kunnen voeren. Ze maken IT bruikbaar. De applicatie architectuur vormt samen met de gegevens-, systeemsoftware-, hardware- en netwerk-architectuur de kern van de IT architectuur. Omdat IT onderdeel is van de informatie infrastructuur, is de IT-architectuur onderdeel van de archi-tectuur van die informatie infrastructuur.

Deze aan elkaar gerelateerde architecturen vormen samen dus een soort hiërarchie. Het is overigens de vraag of we het hier wel over architecturen hebben. Een architectuur is immers een beeld van een relevant geacht deel van de werkelijkheid. Omdat deze architecturen uitgemodelleerd zouden kunnen worden zouden we ook over systemen, componenten of, het laatste modewoord, artefacten kunnen spreken. Een architectuur is immers altijd veel meer dan je kan modelleren of uit wil schrijven. Pro-beer, in het kader van een architectuur, het algemene idee van een organisatie over de gebruikers-vriendelijkheid van een informatie infrastructuur maar eens uit te schrijven. Dat is een uiterst lastige, soms zelfs onmogelijke klus. Aan de andere kant is het wel te doen om de mate waarin een bepaalde applicatie gebruikersvriendelijk gevonden wordt objectief te beschrijven. De eerste beschrijving past in een architectuur, de tweede vult een model aan.

Om de spraakverwarring niet te groot te maken wordt het begrip applicatie architectuur in het navolgende gebruikt in de betekenis in de stelling: het beeld dat we hebben van de applicatie infrastructuur binnen een informatie infrastructuur.

Op zich is een applicatie architectuur een uitstekend hulpmiddel om in kaart te krijgen welke applicaties er zijn en hoe deze aan elkaar “gerelateerd” zijn. Bij applicaties gaat het daarbij om programmatuur, software. Er zijn vele soorten applicaties die op allerlei manieren gemaakt kunnen zijn. Sommige zijn oud, andere zijn nieuw. Elk van hen is gemaakt met de IT die op een bepaald moment voorhanden was. Applicaties kunnen zich tot systemen combineren. Alle applicaties en systemen samen vormen de applicatie infrastructuur binnen de informatie infrastructuur. Het beeld daarvan noemen we hier dus de applicatie architectuur.

Zoals gezegd is de applicatie het deel van de infrastructuur dat zichtbaar is voor de organisatie. Ze zorgen ervoor dat IT werkt en gebruikt kan worden. Daarom wordt business alignment op dit moment ook zo belangrijk geacht. Immers, als je er voor kunt zorgen dat applicaties beter aansluiten bij je organisatie heb je een “betere” informatie infrastructuur. En dat is een zeer belangrijk doel waar vooral informatie aannemers naar streven.

In kleine organisaties worden meestal niet zoveel verschillende applicaties gebruikt. Een handvol kantoorapplicaties, een internet browser, administratieve software, betalingssoftware, een klantenadministratie en nog wat andere applicaties zijn samen vaak voldoende. Het in kaart brengen van deze applicaties is simpel. Eén tekening met een beschrijving is vaak voldoende.

Grote organisaties geven soms miljarden per jaar uit aan hun informatievoorziening. Niet zelden worden vele duizenden applicaties gebruikt. Daarbij is in veel gevallen niet duidelijk welke applicaties dat zijn en welke relaties ze met elkaar hebben. Ze kunnen gegevens uitwisselen, programmacode delen, samen met andere applicaties gegevens aanleveren zodat, al of niet door tussenkomst van nog andere applicaties, informatie gecreëerd kan worden enz.. Zo op het oog relatief onschuldige zaken. Het wordt lastig als bijvoorbeeld gedeelde programmacode gemodificeerd moet worden. Het is maar de vraag of de aanpassingen ook inderdaad op alle plaatsen relevant zijn. In het nabije en verre verleden is zo een legacy ontstaan waar we enorm veel last van hebben. Met als bijkomend gevolg dat het vormen van een beeld van de bestaande applicaties erg moeilijk tot vrijwel onmogelijk wordt.

Een veelgebruikt spreekwoord luidt: meten is weten. Als je een goed beeld van je applicaties hebt ben je in staat om problemen aan te wijzen en aan te pakken. Op zich geen simpele taak, soms zelfs een uiterst complexe. Tot op zekere hoogte helpt het wel om zo gevoelde problemen op te lossen, maar of dat tot structureel tot integratie kan leiden is sterk de vraag. Dan praten we natuurlijk niet over de kleine organisaties, maar vooral over de grote(re).

Hoe zijn we in deze moeilijke situatie terechtgekomen? In het verleden zijn meestal combinaties van op elkaar aansluitende applicaties gerealiseerd in projecten die volgens methoden als SDM uitgevoerd werden. Het probleem was dat de aansluiting met het bestaande vaak minimaal was. Na oplevering, soms zelfs al daarvoor, zijn vaak allerlei veranderingen bijgeprogrammeerd. Daardoor is de legacy ontstaan die, volgens recente onderzoeken, gemiddeld 78% van het totaalbudget voor informatievoorziening van organisaties kost.

Wat is nu applicatie integratie? En hoe realiseer je zoiets?

Een eerste probleem ligt in de uitwisseling van gegevens. Gegevens kunnen uitgewisseld worden tussen applicaties onderling, tussen applicatie en gegevensopslag, tussen applicatie en de buitenwereld en tussen gebruikers en applicaties. Het probleem ligt in het feit dat deze gegevensstromen vaak los van elkaar bedacht en gerealiseerd zijn. Ergens, bij een gebruiker, een andere applicatie of een externe partij, wordt een behoefte aan informatie onderkend. Men bedenkt dat de informatie aanwezig is en zorgt voor een gegevensstroom die de behoefte indekt. Nog afgezien van het feit dat vaak niet alles overzien wordt en dus mogelijk de verkeerde gegevens als informatie aangewezen worden ontstaat zo een wirwar aan gegevensstromen waar men het overzicht snel over verliest. En als er dan nog één bijgemaakt wordt is het maar de vraag of die nog past bij wat we al hadden.
Als we in termen van oplossingen voor dit probleem denken komen we vrij snel tot de conclusie dat e.e.a. vaak terug te voeren is op verschillen in de “eigen” gegevensopslag van applicaties en door gegevensstromen die gegevens direct overdragen tussen applicaties. Het introduceren van een zelfstandige gegevenslaag blijkt een oplossing te zijn. Wel een revolutionaire, want als je het goed doet is de ervaring dat je vaak nog maar 5 tot 10% van de programmatuur overhoudt. Minder en, vooral, veel simpeler applicaties, dus.

Een tweede probleem is dat een applicatie infrastructuur vaak op diverse manieren en op diverse plaatsen dezelfde functionaliteit aan de organisatie biedt. Als u een grotere applicatie infrastructuur heeft, kijkt u dan bijvoorbeeld eens hoeveel keer workflow functionaliteit geïmplementeerd is. Of document management, klantbeheer functionaliteit en ga zo maar door. Antwoorden als 10, 20 of nog meer keer zijn geen uitzondering.
Stel dat u op 20 verschillende plaatsen klantbeheer functionaliteit geïmplementeerd heeft. Dat betekent vaak ook dat u op 20 verschillende plaatsen informatie over klanten heeft vastgelegd, want waarom zou u 2 keer dezelfde functionaliteit voor dezelfde gegevens implementeren. Integratie betekent hier dat we zoveel mogelijk dezelfde implementaties gaan gebruiken. Daarmee verminderen we dus het aantal applicaties.

Er zijn nog vele andere manieren van integratie te bedenken, zoals hergebruik van code, samenvoegen van sterk afhankelijke applicaties tot één applicatie enz.. De 2 beschreven problemen hebben echter de grootste impact op de IT-infrastructuur. En geen van beide is goed te realiseren door de applicatie architectuur als leidend te zien. Het eenduidig vaststellen en definiëren van informatie en van functionaliteit is onderdeel van de informatie architectuur. Het is niet of nauwelijks zinnig om dit soort definities aan de applicaties op te hangen omdat daarmee het eenduidig en eenmalig definiëren alleen via omwegen gegarandeerd kan worden.

De informatie architectuur groepeert en unificeert hier omdat daar eenduidig vastgesteld wordt wat in-formatie is en aan welke functionaliteit behoefte is. Voeg deze kennis toe aan ideeën over een toekomstige inrichting van de informatievoorziening en je hebt een goede basis om de veranderingen aan te brengen in de bestaande informatie infrastructuur. Die veranderingen zijn nodig om een goed geïntegreerde en bij de organisatie passende verzameling applicaties te realiseren.

Daarmee is de informatie architectuur bij het integreren van applicaties belangrijker dan de applicatie architectuur. De stelling is dan ook onjuist.