Taal in bedrijf. Taal en Architectuur. Het creëren van flexibele en strategische systemen

Taal en Architectuur

Taal in bedrijf Het creëren van flexibele en strategische systemen

Auteurs: Bedrijf: Afdeling:

Drs. M. Tromm, J.W. Veldsink MSc Pecoma Groningen BV Business Rules en Systeem innovatie

©2003 Pecoma Groningen b.v.

1

Systeem innovatie


1. Inleiding Een van de bekende problemen van ICT-afdelingen is de zogenaamde application-backlog. Beheerproblemen hebben over het algemeen een hogere prioriteit dan systeemontwikkeling. Vanaf het moment dat er terminals gebruikt werden in bedrijven (ongeveer begin jaren '70) - en er dus gebruikerswensen kwamen - was de applicationbacklog er ook. Derde- en vierdegeneratietalen hebben hier geen verandering gebracht. Ook XML, PHP, ASP en andere server-based languages zullen hier geen oplossing voor zijn. Sterker nog, de diversiteit van programmeertalen hebben het beheerprobleem slechts vergroot. Hoe goed de structuur van een systeem initieel ook is, de snelheid waarmee de business wijzigt is vrijwel niet bij te houden met de gangbare middelen en methoden. Aan de hand van een voorbeeld zal ik betogen dat het toepassen van de Business Rules benadering hier wellicht verbetering in kan brengen. Hierbij zal ik twee oorzaken van de application backlog beschrijven, te weten miscommunicatie op fundamenteel niveau en het gebruik van procedurele talen, en hoe de Business Rules benadering deze wegneemt.


2

Systeem innovatie


2. Bedrijfstaal 2.1. Miscommunicatie binnen bedrijven Een bedrijf is een groep met een doel. Om de activiteiten, die naar dit doel dienen te leiden, van de groep en van ieder van haar leden, op elkaar af te stemmen, zal de visie, het doel en het plan bij ieder lid bekend moeten zijn. Het delen van deze kennis noemen wij communicatie. Het vervoermiddel van de kennis is taal. De taal die binnen een bedrijf gehanteerd wordt is niet alleen belangrijk voor communicatie per sé: de taal bevat zelf een groot deel van de kennis waarmee het bedrijf zijn doelstelling weet te bewerkstelligen. De taal die in een bedrijf gehanteerd wordt, bestaat niet alleen uit de nationale voertaal, maar ook uit vreemde talen, bedrijfsjargon, branchejargon, functioneel jargon (Marketing, BPM, IT, etc) en programmeertalen. Alle strategieën, richtlijnen, ontwerpen, architecturen, protocollen, notulen, etc. zijn uitingen in een of meer van deze talen, verbaal dan wel schriftelijk. In deze uitingen ligt een deel van de bedrijfskennis besloten. Niet alles en meestal niet in formele vorm. De kennis is sterk gedistribueerd, vaag en ambigu. De aandacht voor kennismanagement en de problemen die bedrijven ondervinden bij een hoog verloop van personeel geven het belang van deze kennis aan. Genoemde problemen ontstaan doordat verreweg de meeste kennis niet is vastgelegd, maar aanwezig is in de hoofden van de werknemers. Een deel van deze kennis kan worden verwoord door de werknemer; het deel dat niet kan worden verwoord heet in het engels tacit knowledge. Het is met name deze laatste vorm van kennis die de deskundige onderscheidt van de novice. De kennisdragers in de bedrijfstaal zijn die woorden (naamwoorden, werkwoorden en adjectieven) die verwijzen naar de objecten die van belang zijn voor het bedrijf en de bedrijfsvoering. Deze woorden zijn het die steeds terugkomen in documenten, gesprekken en in geautomatiseerde systemen1. Het is dus van groot belang dat deze woorden of concepten bij alle betrokkenen dezelfde interpretatie teweegbrengen. Zeker als de concepten geformaliseerd dienen te worden: het gedrag van computersystemen is geheel afhankelijk van de formalisatie van deze concepten en dus van de gekozen interpretatie ervan. In de meeste systeemontwikkelingsmethoden is het gangbaar dat er verschillende functionele rollen in de organisatie betrokken zijn:  De opdrachtgever maakt een meestal informele lijst van systeemeisen  De informatie-analist maakt deze lijst idealiter formeel en compleet  De ontwerper vertaalt de systeemeisen naar een systeemontwerp  De programmeur vertaalt het systeemontwerp naar code Dit zijn drie vertaalslagen van de initiële wensenlijst, waarbij het nog maar de vraag is of die eerste wensenlijst überhaubt beschrijft wat men feitelijk nodig heeft. Zelden worden alle concepten zo precies gedefinieerd dat ontwerp en code hier vanzelf uit volgt. Uiteindelijk komt de interpretatie van de programmeur in het systeem terecht. Dit probleem wordt groter als een applicatie meer dan een afdeling raakt, aangezien interpretaties van bedrijfsconcepten duidelijk kunnen verschillen tussen afdelingen.

1

Hierin vormen ze over het algemeen de entiteiten en attributen, resp. tabellen en kolommen. ©2003 Pecoma Groningen b.v.

3

Systeem innovatie


2.2. Bedrijfsregels De graal bij systeemontwikkeling is dat alleen een specificatie gemaakt hoeft te worden van het te ontwikkelen systeem, in onze eigen taal, waarna het systeem gegenereerd wordt zonder elke stap te hoeven uitprogrammeren. Dit is alleen maar mogelijk als de taal waarin de specificatie geschreven is een eenduidige interpretatie heeft en één op één kan worden omgezet in formele logica. Dit laatste is mogelijk: Aristoteles stelde al dat logica slechts een geformaliseerde vorm van verbaal redeneren is. De crux zit hem in het eenduidig maken van de taal. Hier ligt een taak voor de business en niet voor de ICT-afdeling: zij kan namelijk de juiste interpretatie van de gebezigde concepten verschaffen. De business heeft dit altijd overgelaten aan ICT'ers aangezien zij niet uit te voeten konden met formele specificaties. Dit is echter niet nodig. De business dient de concepten die zij hanteren te definieren en te expliciteren gebruik makend van korte zinnen in natuurlijke taal:  een klant heeft een naam  een leverancier heeft een naam  een naam mag maximaal 100 karakters bevatten  een klant plaatst een order  een klant die langer dan vijf jaar niets besteld heeft is geen klant meer  een bedrijf dat meer dan 50 werknemers heeft en in bezit is van een Microsoft netwerk is een potentiële klant  een klant met een jaarlijkse omzet van meer dan 10000 euro is een gouden klant  een gouden klant krijgt 5 procent korting op elke order van meer dan 5000 euro.  Een klant moet een registratienummer hebben.  Als een onderdeel van een product niet op voorraad is moet het besteld worden bij de leverancier van het onderdeel.  Als een onderdeel besteld moet worden bij een leverancier moet er een bestelbon met het onderdeel naar de leverancier gestuurd worden. Dit maakt dat concepten voor iedereen een heldere interpretatie krijgen en deze bij meningsverschillen eenduidig te maken is. De genoemde zinnen zijn voorbeelden van bedrijfsregels (Business Rules). De taak van een informatieanalist hierbij is het dwingen en helpen van de Businessanalist tot het completeren van deze definities. Als de Business Rules goed zijn opgesteld ligt het grootste deel van het gedrag van een computersysteem al vast. Immers, als een klant een registratienummer moet hebben, mag bij het aanmaken van een nieuwe klant in het systeem het veldje 'registratienummer' niet leeg blijven. Het verkrijgen van een eenduidige en heldere interpretatie van concepten kan verstrekkende gevolgen hebben. Er zijn in het verleden al pogingen gedaan hiertoe zoals in entreprise data models. Over het algemeen falen deze modellen omdat ze te snel de diepte ingaan: modelleren van details en van uitzonderingen. Beter is te starten met een generiek model (zie ook column van Rick van der Lans in de Computable van 19 september 2003), onafhankelijk van enige applicaties. Bijvoorbeeld het concept klant kent vele verschijningsvormen, maar hoe men een klant ook definieert, hij zal toch in ieder geval een naam hebben en bestellingen kunnen plaatsen. Ook zal een klant bereikbaar moeten zijn op een of andere manier. Deze eigenschappen kunnen dus aan een generiek concept klant worden toebedeeld. Daarna kunnen er meer specifieke typen van klanten worden toegevoegd die zich differentiëren van het hoofdtype. Niet alleen eigenschappen, maar ook regels kunnen op verschillende niveaus worden gedefinieerd. Een regel van toepassing op het hoogste niveau zal ook van toepassing zijn op lagere niveaus (tenzij deze regel op lager niveau wordt overruled door een specialistische regel).


4

Systeem innovatie


Figuur 1: Onderdeel van de conceptstructuur in AutoMeld (zie hoofdstuk 3)

Het concept van business rules is niet nieuw: database constraints, triggers en attribuutdomeinen bestaan al lang hetgeen ook regels zijn. Echter de directe uitvoerbaarheid (automatische codegeneratie) en het efficient checken van condities van Business Rules wordt niet ondersteund door de gangbare programmeertalen en databasesystemen.


5

Systeem innovatie


2.3. Van natuurlijketaalregels naar implementatie Hoe kunnen natuurlijketaalregels direct worden uitgevoerd door een computersysteem? Zoals eerder genoemd is het mogelijk, mits een beperkte verzameling elementen uit de natuurlijke taal wordt gebruikt, om regels een op een om te zetten in formele regels door grammaticale constructies (phrasings) te koppelen aan logsiche elementen, waarna de logische elementen uit de formele regels kunnen worden gekoppeld aan een implementatie zoals tabellen en kolommen in een database, programma componenten, functies, etc. Al deze fysieke elementen kunnen nu beschouwt worden als een verzameling losse componenten die worden aangeroepen door de regels. De volgorde van programmastappen wordt nu dynamisch opgebouwd afhankelijk van de toepassing van de regels. In het AutoMeld voorbeeld zagen we reeds wat voor logische regels er geschreven werden. Het gebruik van een zogenaamde authoring tool maakte het mogelijk de regels in natuurlijke taal op te stellen en hieruit logische regels te genereren (in Eclipse; een regelgebaseerde taal, nauw verwant aan talen zoals CLIPS, LISP, OPS5, ART-IM) Figuur 2: Voorbeeld van Business Rules in natuurlijke taal

De specificaties waren nu het systeem zelf. Nieuwe regels van NOWM konden vrijwel een op een worden overgenomen in de authoring tool, door opdrachtgever zelf gecontroleerd op juistheid, om vervolgens direct opgenomen te worden in de productieomgeving, runtime. Updates op AutoMeld duren meestal niet langer dan één of twee werkdagen, aangezien het gecodeerde gedeelte veel stabieler blijft en alleen in de regels wijzigingen hoeven te worden aangebracht en dat is een kwestie van herformuleren, verwijderen en toevoegen van regels, zonder dat dat van invloed is op de overige regels.


6

Systeem innovatie


3. Regelgebaseerd programmeren 3.1. AutoMeld® op Internet Als voorbeeld in dit betoog gebruik ik de internetapplicatie AutoMeld® op Internet van NOWM. NOWM is een verzekeraar die uitsluitend bedrijven verzekerd. Eén van haar producten is de garageverzekering. Hierbij worden voertuigen die voor een proefrit of verhuur de weg op moeten vanaf dat moment verzekerd (WA en/of Casco) en bij terugkomst weer afgemeld. Als de voertuigen de weg op gaan dienen ze ook aangemeld te worden bij de RDW. Er gelden allerlei regels voor het aanmelden van een voertuig. Bijvoorbeeld:  Een voertuig met een handelskenteken mag niet casco verzekerd worden.  Afhankelijk van de polis worden er een beperkt aantal gebruiksvormen toegestaan.  Indien het voertuig een vrachtwagen is, zijn er minder gebruiksvormen toegestaan dan bij personenauto's.  Casco is slechts toegestaan wanneer bouwjaar, bouwmaand en cataloguswaarde bekend zijn.  Etc. etc. Omdat er dagelijks honderden voertuigen aan- en afgemeld werden, was automatisering van dit proces noodzakelijk. Hiertoe heeft NOWM een DOS-applicatie en later een Windowsapplicatie geschreven (in Visual Basic). Met deze applicaties konden gebruikers hun aanmeldingen invullen, wegschrijven naar een bestand en deze via een modem verzenden naar NOWM, alwaar het bestand werd verwerkt in de backoffice. Regelmatig leidde dit proces tot problemen:  Aangezien elke gebruiker een clientapplicatie nodig had, kwam de helpdesk van NOWM flink onder druk te staan. Ook problemen buiten de scope van de applicatie werden uitgezocht.  Distribueren van updates was lastig en tijdrovend  Fouten in de invoer werden pas ontdekt in de backoffice, hetgeen een grote vertraging van het proces inhield en het berekenen van premies bemoeilijkte. De stap naar internet was makkelijk gezet, in woord maar niet in daad: een groot deel van de beleidsregels en polisvoorwaarden zat verstopt in de Visual Basic code. Deze waren lastig uit te breiden en nog moeilijker te wijzigen. Elke wijziging in de regels betekende, ondanks redelijke documentatie, dat de code geheel doorlopen moest worden, om te bepalen welke deel van code geraakt zou worden en welke consequenties dit voor de overige code zou hebben. Met de problemen in applicatiebeheer en distributie daarbij opgeteld leidde dit tot een situatie waarbij nieuwe regels in de backoffice via scripts werden geïmplementeerd. Er was geen enkel overzicht op de logica van de applicatie en de backoffice. Het leek er dus op dat de applicatie van de grond af opnieuw gebouwd moest worden. De volgende eisen werden gesteld aan het nieuw te bouwen systeem (niet uitputtend):  Het moest binnen enkele maanden gerealiseerd zijn  Benaderbaar via het web met een centrale database  Wijzigingen in beleid mochten niet meer leiden tot langdurig redesign of vele workarounds.


7

Systeem innovatie


3.2. Ontwikkeling met regels De kennis van de richtlijnen en de regels dienden uiteindelijk rechtstreeks te komen van de mensen die betrokken waren bij het proces. De complexiteit was echter dermate groot dat een tradiotionele watervalmethode niet het resultaat zou opleveren binnen de gestelde termijn. Het systeem zou incrementeel ontwikkeld moeten kunnen worden. Dit vormt echter een probleem voor procedurele en object georienteerde talen (zie ook bijlage). De regels, die onderlinge afhankelijkheden hebben, die andere regels ongeldig kunnen maken zouden een zeer ingewikkelde flowchart hebben en in code vele geneste if…then…else.. of select case.. constructies. Bij incrementele ontwikkeling betekent dit dat de flowchart meerdere malen geheel veranderd moet worden aangezien niet elke regel zomaar kan worden ingepast in de bestaande flowchart. Als dit niet al in ontwerpfase gedaan wordt dan ben je nog vele malen meer tijd kwijt met het herschrijven van code. Er was echter geen tijd voor een lange ontwerpfase. Het aantal regels was op zich niet schrikbarend groot: vele overheidsdiensten en andere beleidmakende of – uitvoerende instanties kennen systemen waarin het aantal regels een orde groter is. De complexiteit in bedrijfslogica wordt echter snel groot aangezien bedrijfslogica zich niet netjes volgens een stel natuurwetten gedraagt maar onregelmatig is en sterk conditioneel. Zelfs in simpele workflowsystemen kunnen al uitgebreide flowcharts te vinden zijn. In het onderhavige geval was de complexiteit voldoende groot om te zoeken naar een andere oplossing dan de gebruikelijke. Zo kwamen we op de toepassing van de Business Rules benadering met tooling van the Haley Enterprise uit de Verenigde Staten. Hiermee was het mogelijk om alle business logic uit de programmacode te halen en buiten het programma te beschrijven in de vorm van logische regels. Wat er aan programmacode overbleef was het gebruikersinterface (tonen en invoeren van gegevens), een databaseinterface (ophalen en wegschrijven van gegevens) en een interface om te communiceren met de rule-engine. Dit maakte het coderen heel erg simpel: alles kon een op een gekoppeld worden. De feitelijke beslissingen over wat te tonen en hoe de invoer verwerkt diende te worden kon in zijn geheel door de rule-engine afgehandeld worden.


8

Systeem innovatie


De werking van een rule-engine is als volgt: er wordt een bestand geladen met regels als de volgende:  Als de polis casco toestaat en het geselecteerde voertuig is geen vrachtwagen dan is casco toegestaan.  Als casco is toegestaan en de actuele toestand van het geslecteerde kenteken is actief dan is de casco-checkbox beschikbaar  Als een checkbox beschikbaar is dan schrijf de volgende XML: <een XML tag>  Als de casco-checkbox beschikbaar is dan is de eigenrisico keuzelijst beschikbaar  Als een keuzelijst beschikbaar is en een keuzeitem uit de keuzelijst is geselecteerd dan schrijf de volgende XML: <een XML tag> De geladen bestanden zien er iets formeler uit met regels die de volgende vorm hebben: (defrule (some condition) (some condition)

)

;declaratie van de regel ;een conditie die mogelijk correspondeert met een feit ;een conditie die mogelijk correspondeert met een feit hierbij kunnen waarden uit de tweede conditie verwijzen naar waarden uit de eerste conditie. Hiermee wordt de verzameling van mogelijke matches ingeperkt tot die gegevens die in beide condities dezelfde waarde hebben (vergelijkbaar met een database join)

=> (infer new proposition)/ ;nieuw gegeven wordt afgeleid of een actie uitgevoerd (execute some action)

Programmeren met dit soort regels heet rulebased programming. Naast de regels worden ook gegevens geladen: initieel uit een bestand, opgehaald uit database of verkregen uit invoer in het gebruikersinterface. De regels staan los van elkaar. Nergens wordt gedefinieerd wanneer een regel moet worden uitgevoerd, dit wordt slechts bepaald door de condities in de regel zelf. Als er een verzameling gegevens is die correspondeert met de condities in een regel dan wordt de regel actief (data-driven). Vervolgens vuurt de regel en wordt er een nieuw gegeven afgeleid of een actie uitgevoerd. Een eventueel nieuw gegeven kan in combinatie met reeds aanwezige gegevens weer andere regels actief maken. Het maakt niet uit in welke volgorde de regels worden gedefinieerd, dus nieuwe regels kunnen gewoon worden toegevoegd zonder te kijken op welke plek dat moet gebeuren. De enige volgorde die hoeft te worden aangelegd is een prioritering van verzamelingen van regels: bijvoorbeeld het wegschrijven van XML-tags dient te gebeuren nadat er is afgeleid welke waarden er naar het interface geschreven moeten worden bij een nieuwe request. Over het algemeen hoeven er maar drie niveaus van prioriteit gehanteerd te worden. In volgorde van prioriteit: 1. input en berekeningen 2. business rules 3. output. In het regelvoorbeeld is te zien dat er maar één regel nodig is voor het aanmaken van tags voor checkboxen die beschikbaar zijn in het interface: er hoeft niet voor elke checkbox een aparte regel gemaakt te worden. Als deze regel er is, hoeft er dus alleen nog maar beschreven te worden welke checkboxen er beschikbaar komen na een request. (dit is ook mogelijk in object-georienteerde talen. Zie paragraaf rules vs object-orientatie waarom oo toch niet alles oplost).


9

Systeem innovatie


Deze manier van werken bracht ons een aantal voordelen waardoor we in staat waren de applicatie binnen gestelde termijn geaccepteerd en in productie te krijgen:  Op het moment dat de verschillende interfaces op hun plek waren konden we de verzameling regels (rulebase) incrementeel opbouwen. Steeds als er nieuwe kennis beschikbaar kwam werden deze in precieze zinnen geformuleerd, gecontroleerd op correctheid door procesmensen, en vervolgens omgezet in een formele regel. De functionaliteit van de applicatie werd op deze manier steeds rijker.  De regels kennen alleen een if-then gedeelte en niet een else-gedeelte (anders zou elke regel steeds actief zijn). Dit maakt dat de regels alleen doen wat ze beschrijven en dat wat niet beschreven is, gebeurt ook niet. Feitelijk was het genoeg om de geformuleerde zinnen te gebruiken voor een compleetheidscontrole. Normaal gebeurt dit ook in het voortraject op basis van de specificaties, maar moet vervolgens ook in code gecontroleerd worden: dat hoefde niet meer, want de specificaties wáren de code.  Elke beleidsregel of polisvoorwaarde of invoercontrole hoefde maar een keer gespecificeerd te worden (single point of definition): op het moment dat we voor een scherm de XML-regels klaar hadden, hadden we deze klaar voor de hele applicatie, want dezelfde regels waren van toepassing op alle schermen. Bij andere regelgebaseerde applicaties gebruiken we nog steeds vrijwel dezelfde set met regels. Deze regels beschrijven gewoon de kennis van het wegschrijven van XML voor een gebruikersinterface. Deze kennis veranderd niet en is voor alle applicaties van dit type gelijk.


10

Systeem innovatie


4. Conclusie Door het principe van single point of definition en de onafhankelijkheid van Business rules verkrijgen we een aanzienlijke versnelling van ontwikkelingstrajecten (tot zo'n 50%) en beheer wordt stukken eenvoudiger: immers, door een regel te wijzigen, wijzigen direct alle applicaties mee waarin de regel actief is. Men hoeft geen code meer te interpreteren en alle voorkomens van een bepaalde regel in de programmacode op te sporen waarna misschien blijkt dat een wijziging van de regel inhoudt dat het programma een geheel andere structuur moet krijgen. De ICT-afdeling hoeft zich niet meer te bekommeren om de business logic, maar kan zich concentreren op die zaken waarin ze excelleert: technische infrastructuur en architectuur. Door het kiezen van een generiek datamodel en een eenduidige interpretatie van concepten in combinatie met het gebruik van business rules kunnen er zeer snel nieuwe applicaties worden toegevoegd. De strategische waarde van de bedrijfsinformatievoorziening wordt daarmee aanzienlijk verhoogt en de time-to-market sterk verkort.


11

Systeem innovatie


5. Referenties

Representative Customers Adobe AT&T Atlantic Mutual Insurance Booz Allen & Hamilton BUPA CIGNA CCC Information Services Credit Suisse EDS eJiva Gallagher Financial General Motors IBM Inland Revenue

IRS KPMG KPN Telecom Merck NASD NetIQ Nokia Pecoma SBC Systor AG Wells Fargo Weschester County US Department of Labor US Department of Defense

Haley Supported Technology INFORMATION TECHNOLOGY Java XML SQL C++ COM Visual Basic and others


OPERATING ENVIRONMENTS MicrosoftWindows Sun Solaris HP-UX IBM MVS IBM AIX ZOS and others

12

Systeem innovatie

Taal in bedrijf. Taal en Architectuur. Het creëren van flexibele en strategische systemen

Recommend Documents