De Midoffice Mythe

Toen de meeste mensen nog gewoon in een fabriek werkten, waren er twee soorten medewerkers – fabrieksarbeiders en kantoorpersoneel. Je droeg al naar gelang je positie of een ranzige overall, of een schoon overhemd – bij voorkeur met een hagelwit boordje. Dat was duidelijk.

Toen de dienstensector opkwam, kwam er behoefte aan een nieuwe tweedeling. De mensen die in de vuurlinie stonden – de medewerkers met klantcontacten, bijvoorbeeld achter het loket van een bankfiliaal – werden ingedeeld bij de frontoffice, en de mensen die op de achtergrond hun werk deden – medewerkers van de administratieve organisatie en de stafdiensten – hoorden even vanzelfsprekend bij de backoffice. In de wandelgangen werd het vaak zo samengevat: de frontoffice verdient het geld, en de backoffice maakt het op.

Wat zou de midoffice hieraan nog kunnen toevoegen?

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 back-office 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: “Today 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 5^de in een reeks flauwekul die op dit weblog gepubliceerd zal worden.