Wat is architectureluur?

Een lezer vraagt zich af:

"Wat is in je verhaal precies de scope van "architectuurlogica"?

In welk begrip zit alles wat met BPM te maken heeft? BPM omvat in legacy applicatie veel code en is m.i. niet herbruikbaar."

De bedoelde post ging over Asterix en de business-logica.

1. architectuurlogica: daarmee bedoelde ik dat dele van de code dat ontstaat omdat een bepaalde architectuur wordt toegepast. Dus bv database-benadering, schermopbouw, in juiste formaat gieten van parameters voor een RPC, vertalen van EDI-berichten, code nodig om een EJB goed te laten werken, enzovoort, enzovoort. In de praktijk is dit een heel groot deel van de code. De eigenlijke business-logica zelf is zo gecodeerd, en de rest is "het laten werken". Dat is "architectuurlogica".

BPM-logica in de strikte zin des woords is business-logica. En dat is niet zo'n groot deel van de code, alleen lijkt het veel omdat daar de verknoping met architectuur-logica nog sterker is.

2. is BPM-logica niet herbruikbaar? Dat weet ik nog zo net niet. Het probleem van veel systemen waarin BPM-logica expliciet is opgenomen, is dat er allerlei zaken in zitten die daar helemaal niet horen. En omdat de BPM-laag van het gemiddelde systeem niet is ingericht op hergerbuik en vermijding van redundantie, is het gevolg dus; redundantie.

Het begint er al mee dat de "business-rules" vaak in de BPM-laag worden geevalueerd. Dat is in verreweg de meeste gevallen helemaal niet nodig, sterker: onhandig, maar het gebeurt toch. In dat soort systemen is de laag onder de BPM-laag meestal niet veel meer dan een veredelde database. Naar mijn idee zijn dat gewoon slechte architecturen.

Als een systeem goed wordt ontworpen, met het "gedrag" (in de zin van object behavior) op de juiste plaats (dwz in de meeste gevallen; bij de data), dan blijkt de BPM-laag helemaal niet zo ingwikkeld en dik te zijn.

Daar komt bij dat ook binnen een BPM-laag doorgaans meer hergebruik mogelijk is dan doorgaans wordt ontworpen.

Samenvattend: ik denk dat er wel degelijk veel hergebruik mogelijk is in het BPM-deel, voor een groot deel door logica in ddat BPM-deel daaruit te halen.

Details

Nick Carr is normaliter een SaaS-evangelist, en een goeie ook. Deze keer wat zinnige kanttekeningen. Vooral zijn tweede punt, tav de lock-in van Office-formaten e.d., is van belang.

Functionaliteit uit de muur: vervolg

In een reactie op de post "functionaliteit uit de muur" wordt gevraagd:

"Ik begrijp uit je verhaal dat je voor de traditionele IT-afdeling vooral een rol weggelegd ziet in het vertalen van de business naar de IT. De IT komt dan vervolgens "uit de muur".

Wat komt er volgens jou precies "uit de muur"? De services in de zin van webservices of ook de proceslaag (executie) die - tijdens executie - van deze webservices een werkbare applicatie maken (BPM), de UI laag, etc.?"

Er zijn 2 betekenissen van "uit de muur" die hier door elkaar dreigen te lopen:

1. "technisch uit de muur": de software wordt geserveerd op een remote host, en wordt door de gebruiker via een client met een browser oid benaderd.
In die zin komen inderdaad de webservices in de zin van business-webservices uit de muur, dat is duidelijk.
Maar er is geen reden waarom dat met de proces-laag niet ook zou kunnen. Het lijkt mij erg handig om ook de BPM-engine remote te hosten, en ik zie geen reden waarom dat niet zou kunnen. De voordelen zijn evident: makkelijker integratie met de business webservices, geen noodzaak meer van extern bereikbare lokale servers, geen aanschaf en onderhoud van een of andere BPM-engine of ESB. (zie ook deze post).
En zelfs voor het UI geldt hetzelfde. Tot voor kort was dat technisch lastig voor elkaar te krijgen, maar met een Ajax-oplossing wordt in feite het UI geladen vanuit de server. Met een Flex-oplossing gebeurt in wezen hetzelfde.

Dus als het om deze betekenis van de term "uit de muur" is het antwoord: ja.

2. de andere betekenis van "uit de muur" is: als standaard, als een commodity. Inderdaad bedoel ik deze betekenis ook.

Voor de business webservices geldt zeker dat dit "commodities" zullen worden. Misschien zijn er kleine wijzigingen en toevoegingen zinvol voor specifieke klanten, maar in de praktijk zal de commodisering hier toeslaan.

Voor de business-processen geldt dat minder. Juist deze zullen min of meer uniek zijn voor bedrijven. Dus hoewel ze technisch uit de muur komen, zijn ze geen standaard commodities.

Ik denk echter wel dat het mogelijk is van veel processen een of enkele standaard-varianten klaar te zetten, en ik denk dat ook hier meer gestandaardiseerd kan worden dan men nu denkt.

Voor UIs geldt (uiteraard) min of meer hetzelfde.

Dus als het om deze betekenis van "uit de muur" gaat is het antwoord: voor business-webservices: ja, voor processen en UIs: nee, maar het zou wel eens naar "ja" kunnen toegroeien.

Databases

Eerder heeft nav een post van mij Rik gevraagd:
"SaaS maakt het mogelijk (web)services buiten de deur te beheren. Ik neem aan dat de bijbehorende data (stam- en transactiedata) meegaat. Hoe wordt deze data aan de SaaS provider-kant beheerd? Slaat de provider de data van bijvoorbeeld het object "inkooporder" van alle bedrijven die dit object bij deze provider hebben "Ge-SaaS-d" fysiek bij hetzelfde object op? M.a.w. heeft zo'n provider een grote data-bak met alle inkooporders van een hele sector bij elkaar geplaatst? of ontstaat er een explosie van allerlei tabellen/databases?"

Volgens mij zijn dit 2 vragen:

1. hoe wordt eea technisch opgeslagen?
2. waar? Bij de SaaS-provider? Bij de klant? Beide?

Ad 1. Voorzover ik weet worden doorgaans "gewone" RDBMSen (MySQL, Oracle, etc) gebruikt, maar omdat je bij SaaS-systemen vaak met klantspecifieke uitbreidingen op het datamodel werkt, is het interessant om wat minder gebruikelijke systemen te gebruiken: row-oriented systemen, objectbases al of niet op XML-basis, etc.

Ad 2. In principe worden de gegevens bij de SaaS-provider opgeslagen, en ik denk dat meestal gegevens van verscheidene klanten in één "fysieke" database worden opgeslagen. Echter, de meeste SaaS-providers hebben serverparken op verscheidene locaties, dus het zal wel niet allemaal in één heel grote database worden opgeslagen.

Er is nogal wat discussie over de vraag of de klanten een "eigen" kopie van de database willen hebben, om security-redenen (achter de firewall) of als backup.
Oracle bv beweert dat dat het geval is, maar de logica van SaaS wijst naar mijn idee de andere kant uit. ik verwacht dan ook dat een dergelijke proliferatie van databases niet de norm wordt.

Vastberaden, maar soepel en met mate

Vorige week vrijdag ben ik naar het BEA-symposium over de BEA-ESB, SOA, etc geweest. Uitstekend georganiseerd, goede presentaties, en een hoge opkomst.

En toch, en toch.... Ik liep er rond, luisterde naar de verhalen, en vroeg me af: wat zouden we hiervan over vijf jaar denken? En over drie jaar?

Dat begon gelijk met het betoog van Massimo Pezzini, Gartner-expert op het gebied van SOA. Hij schetste het bekende beeld voor wat betreft de beloftes van de SOA, maar hij liet ook zien hoe ingewikkeld eea wel niet is: het kiezen en implementeren van een ESB, de organisatorische vereisten, en dan al die dingen waarmee je rekening moet gaan houden. Security! Choreography!! Orchestration!!! En vooral: GOVERNANCE!!!!

Hij eindigde met een reeks zeer ingewikkelde plaatjes, gevolgd door de mededeling dat het mogelijk was om succes te hebben met al dit moois, maar dat je dan wel aan de ene kant doelgericht en zeer gedisciplineerd moet zijn, en aan de andere kant realistisch en pragmatisch.

Wat zou een klant (dat wil zeggen: een niet IT-er) hier nou van denken? Het zal wel voordelen hebben, en misschien moet ik er aan geloven, maar het is allemaal wel erg ingewikkeld, ik heb er natuurlijk weer dure externe jongens voor nodig, en vooral: dit dus gaat klauwen met geld kosten. En het korte-termijn resultaat is onzeker, om niet te zeggen: vaag.

Maar stel dat SaaS zometeen werkelijkheid wordt, en we de functionaliteit "uit de muur" laten komen, is dan die ESB en al dat gedoe nog nodig? Komt die BPM-laag dan niet ook bij een SaaS-provider te liggen? Zit dat wat ik nodig heb dan niet gewoon in de browser, of in het OS? (Als er tussen die twee dan nog een verschil waarneembaar is.) Er zal dan natuurlijk een SOA zijn, en ook zoiets als een ESB, maar de vraag is in hoeverre een "gewoon bedrijf" dat zelf moet regelen en zelf moet aanschaffen.

Zullen al die SOA-trajecten achteraf goede investeringen blijken te zijn? Ik denk het niet, al is het is natuurlijk mogelijk om "toekomstvast" te investeren, dat wil zeggen: een scherp oog gericht te houden op de SaaS-ontwikkelingen. En soms zijn de SOA-investeringen nu onmiddellijk de moeite waard omdat ze een concreet en urgent probleem oplossen met de bestaande systemen, en dan vooral de integratie daarvan.

Een goed voorbeeld van een succesvol project werd geboden in het uitstekende verhaal van de CTO van Nuon, Jeroen Scheer. Maar hij benadrukte ook dat een groot deel van het werk daar in de organisatie zat, en dat de systeemintegratie daar een weliswaar noodzakelijk, maar toch niet al te groot deel van uitmaakte.

Ik denk dat zelfs bij legacy-integratie projecten het pragmatisme en het gezonde verstand zal leiden tot beperkte investeringen in de technische architectuur, omdat juist dat deel waarschijnlijk in de SaaS-infrastructuur zal "verdwijnen", en dientengevolge veel goedkoper zal worden.

Want dat is uiteindelijk de belofte: standaard IT wordt als service geleverd, tegen lage prijzen op gebruiksbasis. Voor standaardzaken hoeven dus geen grote investeringen meer te worden gedaan. Maar als dat waar is voor functionaliteit, dwz: voor de systemen zelf, waarom dan niet ook voor de ondersteunende infrastrcutuur, zoals een ESB?

Cap en GAPE: aanvulling

Ik sprak vandaag iemand van Capgemini, en die wist te melden dat (voorzover hij wist0 de samenwerking tussen Cap en Google gaat over het hosten van Googel Apps, en eigenlijk niet veel meer dan dat.

Ik blogde daarover eerder.

is Bokito eindelijk los?

SAP introduceert de langverwachte SaaS-versie van het SAP-ERP systeem. Gericht op de middelgrote bedrijven, etc, etc.

Ik ben benieuwd hoe zich dit verhoudt tot "nieuwe" SaaS-oplossingen zoals WorkDay.

3 soorten Internet platforms

Een interessant stuk van Marc Andreessen over de soorten platform die op het Internet bestaan. Andreessen gelooft in SaaS, zoveel is duidelijk.

Toevoeging: Andreessen noemt 5 leveranciers die level 3 leveren: Ning (dat is ie zelf), Second Life, Salesforce.com, Amazon en Akamai. Ik vermoed dat het interessante WorkDay ook tot dat rijtje behoort (al is me bij WorkDay nog niet helemaal duidelijk waar de klantcode wordt geexecuteerd). Hoe dan ook: WorkDay schreeuwt om MDA (zie ook eerdere post).

Logische ontwikkeling

Salesforce.com maakt het mogelijk om het ontwikkelplatform te gebruiken zonder Salesforce logo's e.d.

Dat is een mooie en logische ontwikkeling.

Asterix en de business-logica

In een Asterix-verhaal (ik geloof Asterix en het 1ste legioen) komt een scene voor waarin een aantal "barbaren" dienst neemt in het romeinse leger. Ze moeten gekeurd worden, en ontdoen zich dus van hun diverse kledij. Er is ook een Goth bij, die een ontzettend martiaal berevel draagt, en er deswege zeer indrukwekkend uitziet. Bij die keuring echter blijkt uit dat berevel een buitengewoon schriel mannetje te stappen. Zonder berevel blaas je 'm zo om.

Ik moet aan dat beeld nogal eens denken als het gaat om de extractie van business-logica uit legacy. In legacy-systemen is erg veel geld, soms tientallen miljoenen, gestoken. En we hebben dus ook het idee dat die business-logica dus ook wel een forse omvang zal hebben. En menig bedrijf vleit zich ook met de gedachte dat dit "unieke" business-logica is, en daarom van nog grotere waarde.

Echter, als we die business-logica uit het legacy-systeem halen, en ontdaan van redundantie, code die nodig is voor de gekozen architectuur (database-benadering, scherm-afhandeling, transactieonele integriteit, enz) eruit halen, dan blijft er doorgaans een mooi en overzichtelijk business-model over. Een systeem van 600.000 regels code blijkt dan samen te vatten in een model van 27 classes. En een zeer groot deel van die 27 classes blijkt ook nog eens uiterst generiek te zijn: ze zijn vrijwel helemaal ook van toepassing op een willekeurig ander bedrijf.

Met andere woorden: de echte business-logica is slechts een zeer klein deel van een systeem (althans gemeten in regels code), en ook nog eens voor een klein deel uniek.

Nou gaat dit alleen om de business-logica, en die andere code is ook nodig. De database moet benaderd worden, de schermen moeten worden afgehandeld, enzovoort. Het berevel was wel nodig. Maar die architectuur-logica geldt voor alle systemen, en vrijwel al die code zou, mits goed gescheiden van de business-logica, kunnen worden hergebruikt. En met MDA/D/E kan dat.

Dus: als we in staat zijn om:
- generieke business-logica te hergebruiken
en
- software benodigd om de business-logica in de gewenste architectuur te hergebruiken
dan kunnen we bestaande systemen vervangen voor een fractie van de investeringen in het legacy-systeem.

En als we dan ook nog eens de voordelen die SaaS in dit verband biedt (centraal beheer, delen van kosten over vele gebruikers) in acht nemen, dan leidt dat tot een onrustbarende maar waarschijnlijk onontkoombare conclusie: de vervangingswaarde (en daarmee de economische waarde) van veel bestaande software ligt ver, ver beneden de waarde waarvoor de software in de boeken staat, laat staan de som van de investeringen.

Oeps. Betekent dat nou dat we al die jaren niks nuttigs hebben bereikt? Nee, natuurlijk niet. Er waren toen geen betere mogelijkheden. Maar dat is geen reden om onze kop in het zand te steken. Het kan nu wel anders.

Moet dat dan onmiddellijk gebeuren? Nee. Als een legacy-systeem goed werkt, dan zijn meestal de operationele kosten laag. Vervanging is dan lang niet altijd economisch zinvol.

Maar dat laat onverlet dat de consequenties van "functionaliteit uit de muur" verbijsterend zijn.

GAPE en Cap

Phil Wainewright gelooft niet erg in Capgemini die Google Apps gaat ondersteunen. Volgens hem zitten klanten die Google Apps willen, niet te wachten op een hoop consultants.

Daar zal ie wel gelijk in hebben, maar ik denk dat Capgemini op deze manier bij echte SaaS-klanten wil binnenkomen. En dus wellicht in eerste instantie helemaal niet zoveel consultancy wil leveren.

Cap weet aan welke kant de boterham gesmeerd is

Capgemini gaat Google Apps bij klanten introduceren en ondersteunen, volgens dit bericht. Een logische ontwikkeling, maar toch ook opmerkelijk, omdat Cap hiermee afstand neemt van de traditionele standpunten van de IT-ers over de toepasbaarheid van dit soort diensten ook in grotere bedrijven.

De honden blaffen, maar de karavaan gaat verder.

IT afdelingen en Web 2.0

In dit en in dit verhaal worden voorbeelden gegeven van organisaties die Web 2.0 oepassingen willen implementeren, maar daarin niet worden geholpen, of zelfs worden tegengewerkt door de eigen IT-afdeling.

Ik geloof het allemaal onmiddelijk. In deze voorbeelden gaat het vooral om "social web" achtige toepassingen. Het zou dan nog kunnen dat eea buiten de expertise zit van de bestaande IT afdelingen.

Maar ik denk dat het probleem verder gaat, en dat IT afdelingen vaak ook core-business toepassingen tegenhouden. Gedeeltelijk omdat ze er geen verstand van hebben, gedeeltelijk omdat ze het onzin vinden, en gedeeltelijk omdat ze door bv SaaS in hun bestaan worden bedreigd.

De organisatie van IT, software ontwikkeling, etc is een groot obstakel geworden, vrees ik. We komen hierop terug.

Het risico van SaaS

Ik ben deze week nog niet actief geweest op deze blog. En waarom niet? Omdat "op de zaak" het Internet "het niet deed". Wat was er gebeurd? Kennelijk was op het LAN, dat verbonden is met het netwerk van de provider een zwaar geinfecteerde computer gehangen. Die begon direct allerhande rotzooi te verspreiden. Hierop sluit de provider de verbinding af, dat wil zeggen: email via de provider was nog wel mogelijk, maar verder niets. Geen FTP, geen HTTP, niets.

Daarna begon het grote gehannes. Want het oorspronkelijke probleem (de geinfecteerde laptop) was snel opgespoord en opgelost, maar toen moest de verbinding weer herstart worden. En door een hoop administratief gedoe, misverstanden, een niet te bereiken helpdesk, enzovoort duurde dat erg lang.

Sterker: nu, bijna vier dagen verder, werkt het nog steeds niet. Inmiddels is er een noodverband, die op dit moment door mij wordt gebruikt.

Maar ik ben blij dat wij als bedrijf niet van SaaS afhankelijk zijn, want dan hadden we nu een Heel Groot Probleem gehad.

SaaS staat en valt bij de betrouwbaarheid van de infrastructuur. En daarin zitten, zeker voor kleinere bedrijven, erg veel schakels, en vooral erg veel schakels waarop je geen invloed hebt. Als je eenmaal op de backbone zit, zal het allemaal wel erg robuust zijn. En als er een probleem is, dan heeft iedereen het probleem. Dat is een troost, en het betekent ook dat het waarschijnlijk snel wordt opgelost.

Maar de verbinding naar de backbone is het zwakke punt. Je bent afhankelijk van 1 provider, en bij problemen van de snelheid van diens reactie, de kwaliteit van de helpdesk, etc. Dat zijn stuk voor stuk risico's. En makkelijk switchen van provider is er niet bij. Dat levert een onbeschrijflijke heisa op.

Misschien is het een idee om twee verbindingen via twee infrastructuren te hebben: 1 ADSL, en 1 via de kabel. Maar dan moet er wel kabel zijn, en die ligt hier niet in dit kantorenpark.

Conclusie: tobben.