Het ontwerpen en integreren van ICT-systemen moet bij tijd en stond zichzelf eens heruitvinden en opnieuw verpakt worden. Dat kan niet anders. Er wordt zo veel onderzoek gedaan, we hebben zo veel ervaring opgedaan. Wees eerlijk, de sector wordt slimmer! Laat er dan nog eens wat marketeers en strategisten mee aan de slag en de buzz-woorden veranderen cyclisch.

Begrijp de taal van de business

Laat het nu de periode van de CBD, EAI, BI, MDM, SOA, ... zijn. Ondanks deze veranderingen ben ik gedurende jaren nog steeds 80% van mijn tijd bezig met nadenken, praten, discussiëren, instrueren over en structureren van informatie. Niet alleen bij het ontwerpen van systemen of services, maar ook en zeker bij ontwarren van businessproblemen.

Dat wil zeggen dat de essentie dezelfde is gebleven: begrijp de taal van je business!

Belang van juist modelleren

Waarom staat er in de meeste boeken over SOA niets over het belang van het juist modelleren van de informatie die je service beheert? Wat heb je aan technisch juist geïmplementeerde services als het domeinmodel niet strookt met de echte wereld?

Wanneer je services bouwt ter vervanging of afscherming van legacy (maakt niet uit of die legacy een pakket of zelfbouw is): kom los van de heersende applicatietaal. Een moeilijkheid is dat de businesstaal vaak ‘biased’ is doordat ze jarenlang terminologie van bijvoorbeeld het gebruikte ERP systeem overgenomen heeft. Het is dan nodig even het vogelperspectief aan te nemen en terug te gaan naar de kern van waar je mee bezig bent. Dit is dus business-stuff en geen IT-stuff!

Wat gaat er fout?

Twee departementen praten met dezelfde term over een concept, maar bedoelen er eigenlijk iets anders mee. En dat zonder het te beseffen! Nog pijnlijker wordt het als die 2 gegevens in hetzelfde veld in een applicatie belanden, of als 2 applicaties op basis van dit duaal geïnterpreteerd veld gelinkt worden. De gevolgen laten zich voelen: onverwachte data, workaround procedures, waardeloze rapportering.

Niets is wat het lijkt

• het ‘tarief’ voor inzet van een resource is niet zomaar tarief. Is het een catalogustarief, tarief toegepast in een specifiek project, voor een specifieke markt? Als je 1 tariefnotie zonder context hanteert, en geen explicitering maakt, ga je slechte software bouwen, gaat de business geen zicht hebben op haar cijfers, en heeft die software dus geen business-waarde.

• de ‘waarde’ van materieel is niet zomaar waarde. Is het de aankoopwaarde, huidige waarde in context van afschrijvingen, verzekering of transport/douane?

• hoe kan je het aantal werkvloerincidenten opvolgen wanneer je bij het registeren van een incident maar 1 slachtoffer kan ingeven en als gevolg daarvan het incident dan maar gedupliceerd en getripleerd wordt indien er een tweede en derde slachtoffer is.

Als je het zo stelt, lijkt het allemaal triviaal. Soms krijg je als reactie dat we onze business wel kennen en dat we die informatie niet hoeven te modelleren. Tijdverlies! Agile is het buzz-woord!

Mijn dagdagelijkse realiteit bewijst het tegendeel...

Geert Sprengers, Principal Consultant AE