Common Sense
Oorspronkelijk werd IT vooral gebruikt
om taken uit de backoffice te “automatiseren” – niet voor niets
is de term “administratieve automatisering” in zwang geraakt.
Sinds de e-commerce en e-business ontwikkelingen speelt IT steeds
nadrukkelijker ook bij de frontoffice taken een rol. Klanten kunnen
op de website on-line bestellingen doen, problemen melden en met een
beetje geluk ook zelf oplossen. Dankzij straight-through
processing in de geautomatiseerde backoffice is menselijke
tussenkomst soms niet eens meer nodig. Goed, je kunt nog betogen dat
de “content managers” van vandaag op een indirecte manier het
klantcontact verzorgen, dus eigenlijk moderne frontofficers zijn,
maar strikt genomen hebben zelfs zij nu een ondersteunende taak.
De laatste tijd lees je met enige
regelmaat de term midoffice – vooral
in relatie tot de elektronische overheid. Dan gaat het
doorgaans om allerlei IT-systemen die de coördinatie en
afstemming van de overige IT-systemen regelen. Systemen die niet
klant-gericht zijn, en niet administratief van aard zijn, maar die
integreren en orchestreren. In software-engineering termen zou je het
al snel over middleware hebben, wellicht nog wat aangevuld met
typische enterprise services. De “enterprise service bus”, de
“business rules engine” en de “business process management
engine”, dat soort systemen.
Maar hoe vertaalt zich dit in
bedrijfskundige termen? Bestaat er een afdeling, liefst eentje die
nog geautomatiseerd kan worden, die tot taak heeft om de frontoffice
met de backoffice met elkaar samen te laten werken? Of is zo'n
nieuwerwetse term op de keper beschouwd toch weer baarlijke IT-
Flauwekul?
Een klein onderzoekje is meteen
ontluisterend. Er is op internet geen definitie van het begrip
midoffice te vinden. Zelfs Bayens en Lankhorst wagen zich in “De
Midoffice ontrafeld”
(http://www.via-nova-architectura.org/artikelen/tijdschrift/de-midoffice-ontrafeld.html,
2008) niet aan een definitie. Dan maar wat dieper gegraven.
De aloude Webster Dictionary definieert
in de online versie de term backoffice als “of or relating
to the inner workings of a business or institution”. Frontoffice
wordt gedefinieerd als “the policy-making officials of an
organization”. Sic.U leest het goed. De enige echte front-office
wordt volgens deze definitie
gevormd door de beleidsmakers.
Gelukkig
geeft de Business Dictionary een heel andere interpretatie. De
frontoffice is
“Marketing, sales, and service departments that come in direct
contact with the customers, and liaise with the back-office
(administrative) departments to maintain a two-way flow of
information”. Techweb maar eens geraadpleegd. “front
office refers to systems that
deal directly with the customer such as order processing” en “back
office refers to systems that do
not deal directly with the customer”. Gelukkig maar. Webster is
gewoon niet helemaal bij de tijd. Dus kunnen we veilig uitgaan van de
conceptie dat de front-office klantgericht is, en de back-office
intern-gericht.
Maar
hoe zit het dan met de midoffice? Die komt zelfs in de
TechEncyclopedia (met meer dan 20.000 IT termen) niet voor. Volgens
het programmabureau elektronische gemeenten EGEM gaat het bij de
midoffice om de systemen die de frontoffice systemen en de backoffice
systemen aan elkaar knopen:
“Het mid office als architectuurconcept bevindt zich tussen het
front- en back office. Het front office vormt de presentatielaag van
een organisatie naar de buitenwereld; alle interactie daarmee speelt
zich af in het front office. In het front office worden verschillende
kanalen onderscheiden, zoals een callcenter, website en balie. Het
back office daarentegen vormt het hart van de organisatie waar zich
onzichtbaar voor de buitenwereld de primaire (gegevensverwerkende)
processen afspelen. Het mid office fungeert daarbij als koppelvlak
voor de verschillende front- en back office systemen.” (uit:
Marktverkenning mid office systemen, 26 november 2004).
Bayens
en Lankhorst gaan in hun enthousiasme nog een stap verder. Zij zien
naast een ESB ook het BPM-systeem en een Operational Datastore (ODS)
als onderdeel van een midoffice. En dat is dan nog maar de dunne
variant. Want de “dikke midoffice” bevat ook nog een CRM-systeem,
een Document Management Systeem en een Workflow Management Systeem.
Een “totaal-bouwdoos” voor een “moderne SOA”. Slik.
Hier
maken de auteurs naar mijn idee toch echt een denkfout. Omdat een
workflowsysteem een workflowmodel kan executeren is het
workflowsysteem zelf nog geen applicatie geworden – althans geen
gebruikersapplicatie. Dat is op z'n best het workflowmodel zelf. En
die zit normaal gesproken niet in een suite van
een leverancier. Die moet tenslotte op de specifieke omstandigheden
van de organisatie afgestemd worden. Zoals het in bepaalde
architectuurkringen wel heet: “There are two things in life you
cannot buy: love and an SOA”. Met ander woorden: de leverancier van
een workflow-managementsysteem levert technologie – geen
architectuur en geen gebruikersapplicatie. Dat een workflowmodel
misschien niet in een derde-generatie computertaal is geschreven,
maar op een alternatieve manier is gecodeerd, betekent op zichzelf
nog niet dat zo'n workflow-engine niet gewoon een interpreter
zou zijn. Niet veel anders als een webserver die PHP kan
interpreteren.
Wat
een midofficesysteem heet te zijn, zit feitelijk helemaal niet
“tussen” de klantgerichte en de interne, administratieve systemen
in – zoals de naam suggereert. Het is in mijn ogen technologie die
beide soorten systemen faciliteert.
Het zit er als het ware onder. De in Amerika gangbare term 'SOA
platform' met 'enterprise services' is dan ook veel logischer.
Inderdaad, het klopt dat zo'n 'SOA platform' functioneel steeds
rijker wordt. Eerst werd het platform verrijkt met zaken als
“middleware”, applicatieservers en met database management
systemen en nu zijn we zo ver dat we een platform hebben met een
rules engine, een document management systeem, een
orchestratieservice. The rich get richer.
Zo gaat dat nou eenmaal. Maar een platform blijft een platform.
Dat we het platform
of de enterprise services in architectuurplaatjes graag in een
tussenlaag platslaan, omdat dat nou eenmaal makkelijker tekent, soit.
Dat het daarbij op de keper beschouwd niet zo zeer gaat om de
enterprise services, maar de “scripts” die daarop worden
uitgevoerd, dat wil ik ook nog wel voor lief nemen. Maar laten we
toch alsjeblieft stoppen met voor die laag de verwarrende kreet
'midoffice' te gebruiken.
Er speelt nog iets
anders. In enterprise SOA-plaatjes wordt de informatieruimte – met
een knipoog naar het “3-tier model” uit de software architectuur
– vaak opgedeeld in drie lagen:
-
een
applicatielaag – de gebruikers-georiënteerde onderdelen (de
“presentation tier”)
-
een services
cloud – de gegevensverwerkende en beslissingsondersteunende
onderdelen (waarin de “application tier” en de “data tier”
tegenwoordig broederlijk opgaan)
-
een lijmlaag –
de integratiecomponenten, inclusief de 'command and control'
onderdelen
In dit verband
worden ook wel de termen frontofficesystemen en backofficesystemen
gehanteerd (veelal 'gemakshalve' afgekort tot 'frontoffice' en
'backoffice'). Systemen met een gebruikerinteractie zijn
frontofficesystemen en services zonder gebruikerinteractie zijn
backofficesystemen. Een volstrekt begrijpelijke terminologie – de
“gebruiker” van een applicatie neemt in het denken de plaats in
van de “klant” van een organisatie. En ik wil ook nog best wel
toegeven dat de term midofficesysteem in díe context prima op
z'n plaats kan zijn.
Toch blijft het
risico op verwarring onverminderd groot. Een gebruiker die in de
backoffice werkt, gebruikt per definitie een
frontofficesysteem om toegang te krijgen tot de backofficesystemen.
Daar moet je IT-er voor zijn om dat te kunnen begrijpen. En in
enterprise architectuurmodellen betekent de term “backoffice” in
de organisatieview dan iets totaal anders dan in de “softwareview”.
Verwarrende terminologie, daar hebben we wat mij betreft al meer dan
genoeg van.
Misschien is deze
discussie wel een goede aanleiding om een terminologie te ontwikkelen
die nog niet belast is. Wie durft een suggestie te doen? Ter
inspiratie: ik houd het voor mezelf tot nader order op de Podiumzone
(populair: de P-Zone), de
Atriumzone (A-zone) en de Origozone (O-Zone). Maar ik sta natuurlijk
absoluut open voor betere suggesties.
Deze
flauwekul ontzenuwt een actueel architectuurdebat op een pittige en
soms zelfs controversiële manier. Het is de 4de
in een reeks flauwekul. Deze is op 14 juli 2008 gepubliceerd op ArchITectuur Bedrijven.
Only registered users can write comments.
Please login or register.
|
