From the Mist

Het is een gezonde trend in moderne bedrijven om zich voortdurend te bezinnen op wat nu eigenlijk de core business is van het bedrijf.

Een telecom operator heeft als core business het exploiteren van telecommunicatie faciliteiten. Een schoonmaakbedrijf heeft als core business het schoonmaken van gebouwen en ruimtes.

In dat kader is het heroverwegen van ICT investeringen een onderdeel van deze bezinning. Welke aspecten van de ICT kosten zijn onderdeel van de core business, en welke niet?

Elk onderdeel van een bedrijf dient zijn bijdrage aan het bedrijfsresultaat te onderbouwen. Geen enkel onderdeel kan in dat proces buiten schot blijven. Het zijn slechts de beschikbare resources die dit proces van bezinning onderwerpen aan restricties. Het wijzigen van de bedrijfsstructuur, door sommige delen af te stoten of juist uit te bouwen door er extra in te investeren, kost tijd en geld. In zekere zin is dit proces zelf ook een bedrijfsonderdeel dat voortdurend meegenomen dient te worden in dit bezinningsproces.

Het bezinningsproces leidt bijvoorbeeld tot het outsourcen van sommige ICT-activiteiten. Dit kan succesvol zijn, of niet. Er zijn in de onderzoeken naar de effectiviteit van outsourcen elkaar (schijnbaar) tegensprekende resultaten. In het algemeen lijkt het belangrijk om te letten op een aantal eigenschappen van die onderdelen die kandidaat voor outsourcen zijn. Ik noem er een aantal ter illustratie, het is zeker niet bedoeld als een uitputtende lijst:

• Zijn er voldoende (concurrerende) aanbieders op de markt?
• Is het onderdeel voldoende volwassen (bijvoorbeeld in CMM zin)?

De relatie tussen ICT en business is niet een uitzonderlijke, maar kenmerkt zich natuurlijk wel door een aantal aspecten. Zo is ICT te vergelijken met bijvoorbeeld een ander essentieel bedrijfsonderdeel, bijvoorbeeld de catering. Zonder mogelijkheden tot voedselopname zullen weinig werknemers tot productiviteit in staat blijken te zijn. Catering valt zeker niet onder de core business. Toch onderscheidt ICT zich van bedrijfsonderdelen als catering doordat het veel meer verweven is met de core business dan welk ander bedrijfsonderdeel ook. Dit is juist dat aspect waardoor het veel moeilijker te beoordelen valt op welke wijze ICT met de business dient samen te werken, en tevens de oorzaak van de gespannen voet waarop de verhouding tussen ICT en business leeft.

Wat nodig is in dit dilemma is een duidelijke markering van de grenzen tussen business en ICT. Het is een simpele constatering, en het is uiterst belangrijk deze constatering te maken. We kunnen veel woorden vuil maken aan wat er allemaal aan problematiek speelt, maar in essentie komt het hierop neer, en het formuleren van het probleem in zo eenvoudig mogelijke termen kan ons helpen grip op de situatie te krijgen en maatregelen te nemen om de problemen te verminderen en eventueel zelfs op te lossen.

De fout die eigenlijk alle ICT producten maken, en intrinsiek de fout die gemaakt wordt door de leveranciers/bouwers van die producten, is dat in die producten het onderscheid tussen business en ICT juist veel te veel verweven is. Misschien zit hier een doelbewust beleid achter teneinde de gebruiker afhankelijk te maken van het product, maar dat is te betwijfelen. De oorzaak zal veel meer te vinden zijn in de onvolwassenheid van ICT in het algemeen. Het is nog een primitieve technologie en de vuistregels van het werken ermee zijn nog niet uitgekristalliseerd.

De oplossing valt dus te vinden in het uit elkaar trekken, in de software oplossingen die wij bouwen, van business en ICT.

Hoe dit gerealiseerd kan worden is geen eenvoudig verhaal. Het is echter wel degelijk zo dat er wat aan gedaan kan worden, en dat wij geen willoos slachtoffer zijn van leveranciers, of dat de tijd er nog niet rijp voor is – kortom er zijn geen excuses om de aanpak van dit probleem nu we het onder woorden hebben gebracht en onderkent uit te stellen. Het is een stap in de verdere volwassenwording van de ICT dat we hiermee beginnen, en voortdurend werken aan de verdere implementatie van deze oplossing.

Dat er wat aan gedaan kan worden is een opening voor veel business managers. Momenteel is de situatie teveel die van een willoos slachtoffer: de ICT mensen kunnen van alles beweren, er zijn immers veel te weinig criteria om te kunnen toetsen of datgene wat ze beweren ook daadwerkelijk hout snijdt. Is er weer eens een project mislukt? Moet er weer een product aangeschaft worden? Moet de business weer eens aangepast worden omdat de ICT anders niet de voordelen kan bieden die het belooft?

In deze vrije-jongens-cultuur wordt het tijd dat werktuigen in handen komen van de niet-IT’ers onder ons waardoor we in staat worden gesteld de beweringen van de IT onder de loep te leggen en te beoordelen op hun mérites.

Kort samengevat is dus wat wij graag willen het uit elkaar trekken van:

1. technische componenten die gebouwd kunnen worden door mensen die technisch gericht zijn en niet noodzakelijkerwijs de vaardigheden hoeven te bezitten die hierboven beschreven zijn
2. business componenten die deze eigenschappen noodzakelijkerwijs wél dienen te bezitten

Referentie model

Ik wil graag een referentiemodel introduceren dat zal dienen als een illustratief voorbeeld van de toepassing van business-centered architecturen. Het voorbeeld is gebaseeerd op:

1. Toepassing van J2EE voor de technische architectuur en de technische componenten
2. Geïsoleerd business component gebouwd in een andere taal, Smalltalk

Een aantal redeneringen liggen ten grondslag aan deze keuzes. Ten eerste is er sprake van een referentiearchitectuur, waar andere eisen gesteld worden aan een aantal keuzes omdat hier het belangrijkste doel is een didactisch effect te bereiken.

Ten tweede is het belangrijk om niet alleen een Java implementatie te kiezen omdat dit ons dreigt te binden aan bepaalde leveranciers en oplossingen. Bijvoorbeeld een .NET implementatie van het referentiemodel zou ook mogelijk moeten zijn. Oplossingen in de praktijk zijn ook zelden uniform qua programmeertaal.

Ten derde is de keuze van Smalltalk voor de business component niet willekeurig. Programmeertalen zijn niet de alfa en omega van systeemontwikkeling en elke taal heeft zijn voordelen en nadelen. Met name voor de bouw van business componenten heeft Smalltalk een groot aantal eigenschappen die deze taal voor deze toepassing beter geschikt maken dan de meeste andere programmeertalen, inclusief Java.

Geïnteresseerd? Lees mijn artikelen over Business-Centred Architecturen.