Afgelopen weken kromden mijn tenen zich weer eens over de contentmarketing die als opinie gebracht werd. De gebruikelijke gouden bergen werden weer beloofd met zoiets abstracts als cloud computing. Voordat ik Henri Koppen weer in mijn nek heb, ik geloof best wel in cloud computing alleen niet als de Haarlemmerolie voor alle problemen omdat het enkel techniek is, meer een delivery model dan een oplossing.
Stellen dat cloud computing organisaties lean maakt is onzin want cloud computing is alleen maar de evolutie van Enterprise computing, het delivery model dat antwoord moest geven op een behoefte die ontstaan was met het idee van de service oriented architecture. Cloud evangelisten blijken opmerkelijk vaan een liefde te hebben voor het vergiftigde idee van soa wat organisaties dus verre van lean maakt doordat alle ongestructureerde en verspreid liggende data bedrijfsprocessen dus juist stroperig maakt.
Vaarwel soa
In elk geval is met de introductie van het soa idee de liefde tussen de business en it-afdeling behoorlijk bekoeld. Dat mede omdat er een ‘flawness’ in het service georiënteerde denken zit doordat soa het bestaan van data negeert. En verder richt het zich misschien wel op het hergebruik van software maar dus op het hergebruik van resources. Hierdoor kregen organisaties niet alleen steeds meer data maar ook rekken vol met servers die mede door de wet van Moore wel krachtiger werden maar dus niet beter benut. Cloudpredikers die beheerders voor server knuffelaars uitmaken hebben ook niet zoveel van data management begrepen. Maar Moore stelde dan ook dat it een gigantische industrietak is geworden die je niet zomaar vervangt. En met de wildgroei aan ‘-aaS’ termen lijken de wolven inderdaad wel hun haren te verliezen maar niet hun streken.
Tenslotte was de service delivery nimmer het probleem, de uitdaging zat al vanaf het begin in het beheer van alle data en de vele koppelvlakken. Met laatste bedoel ik niet de logische die door Enterprise Architecten in architectuur platen vastgelegd worden maar dus alle ongedocumenteerde connecties. Ik zal vast een geheim vertellen door te zeggen dat Internet zeker geen Enterprise Service Bus is. Zeker bij publieke oplossingen ligt er dan ook een uitdaging in de beveiliging van informatie. En wie bij cloud computing nog vasthoudt aan het idee van soa heeft gewoon een nieuwe trend gemist, de information oriented architecture.
Hallo Alice in wonderland
Zoals ik al aangaf in de introductie geloof ik in cloud computing maar dan alleen op basis van de principes als delivery model. Dat geloof komt voort uit het simpele feit dat het allemaal niet zo revolutionair is als de industrie ons wil doen geloven. Want als ik me niet vergis vulden we met Enterprise Computing al veel van de geldende principes van cloud computing in:
1.Lage initiële kosten om te implementeren (standaardisatie)
2.Meerkosten in rekening brengen als belasting groeit (kostenmodel)
3.Een geautomatiseerde implementatie (job scheduler)
4.Het beheer ingebouwd met daarbij:
a. Zelfbediening (rollen)
b. Best Practices (referenties)
5.Hergebruik (lifecycles)
Cloud computing voegt met virtualisatie dus alleen gedeeld resource gebruik toe en maakt van het netwerk de backplane voor de horizontale schaalbaarheid. Aangezien we dat netwerk na introductie van Windows NT 4.0 al voor unintended install clustering gebruikten weten we dus al een tijdje waar de bottleneck ligt. In Enterprise omgevingen gebruikten we daarom lokale distributiepunten welk principe dus ook in de cloud gebruikt wordt.
Kortom, cloud computing op zich zelf maakt een organisatie niet lean, want dat zijn de processen welke, zoals Theory of Contraints stelt, erop gericht moeten zijn om de bottlenecks weg te nemen. En bij de publieke cloudoplossingen voeg je naar mijn opinie er dus juist één toe in de vorm van het netwerk.
Van grottekening naar infographic
Bij de publieke cloudoplossingen is het ook moeilijk om te bepalen waarvoor je betaalt en wat je uiteindelijk krijgt. Aangezien veel providers met vaste kostenmodellen werken is het goed om ook eens naar punt 1 en 5 te kijken. Tenslotte werken veel providers met vaste prijzen in hun kostenmodellen en een nieuwe prijs voor een tweedehands server is dus vooral goed voor de marges van aanbieders. Verder hebben veel virtuele servers de specificaties van een eenvoudige pc waardoor beweringen over te behalen kostenreducties nogal factfree zijn.
Nu roepen cloudevangelisten dat het bezit van servers achterhaald waar ik wel mee kan instemmen, vaak was de business unit de eigenaar. Maar zoals ik al gezegd had negeert soa het bestaan van data welke juridisch geen heldere status heeft en waarvan veiligstellen meestal ten laste komt van de it-afdeling. Tel daarbij op dat organisaties door de wet aan het ‘verkeerstorenmodel’ gebonden zijn voor wat betreft de bedrijfsinformatie. Want het ging nimmer niet om de lifecycle van services maar dus om de informatie en -drager. En cloud computing kan als deliverymodel alleen maar een middel want de sleutel tot succes zit in een geïntegreerde vorm van it-servicemanagement voor met name capaciteitsmanagement van de business services.
Bedrijfsprocessen steeds stroperiger
Helaas weet de business dus meestal geen goede forecast te maken waardoor de roi van veel oplossingen gewoon natte vingerwerk is. Bedrijfsprocessen worden tenslotte steeds stroperiger door de toenemende volumes aan ongestructureerde en verspreid liggende data. Maar ik had meen ik al wat gezegd over de onveranderlijke it-industrie.
Betreffende een eerdere uitspraak van wederom Henri Koppen dat marketing met cloud computing op jacht kan gaan wil ik er op wijzen dat succesvolle jagers de buit meestal weer terug naar de grot sleepten. Minder succesvolle jagers werden voer voor de wilde beesten en zo is het natuurlijk ook met cloud computing waarvan dynamiek je ook tegen kan werken.
Jack, ik heb et document waarnaar je verwijs gelezen :
http://www.insideanalysis.com/wp-content/uploads/2012/04/TheIOA-WP-Final-0419.pdf
En dit paper, wat op zijn hoogst aardig is, maar stiekem een marketing instrument en eigenlijk heel weinig toevoegt gaat in het begin al mis met dit voorbeeld:
y = get(x);
En stelt daaronder dat dit strikt genomen over data gaat (y is data), maar dat er een functie gebruikt wordt en dat een functie per definitie processing is.
En vanuit dat deze premisse bouwen ze een case op waarin ze overigens een discussie aanhalen die ik ook vaak met ontwikkelaars voer : De OO programmeur ziet de database als bitbucket, de database engineer ziet OO als een dwingende ongewenste laag die flexibiliteit in de weg staat en traag is. Maar beide doen gewoon aan data opslag en aan data processing. Mijn punt is dat er een tegenstrijdigheid wordt geschetst die er eigenlijk niet is.
Een voorbeeld die dit misschien beter illustreert.
“Jan ni katika upendo na Linda.”
Voor veel mensen is dit gewoon data, maar als je Swahili spreekt is dit informatie.
Ofwel data moet altijd verwerkt (processed) worden.
SOA is dus zowel TCP als IP.
En als we het over webservices hebben. Je kunt een methode maken : GetOrderById welke informatie geeft over de order die best diep kan gaan, zoals welke onderdelen bevat de order, en welke onderdelen zijn al geleverd en hoeveel van het orderbedrag is al voldaan en door wie.
Het aanroepen gebeurd door een gebruiker, deze heeft zich gevalideerd met een IAM waardoor de methode ook kan bepalen of de aanroeper deze order wel mag zien.
Door een Order ook nog als object (construct) te definiëren kan de aanroepende applicatie al precies weten hoe het object eruit ziet en kan dit weer gebruikt worden als onderdeel van een OO keten. Waarbij zowel het object in XML als JSON gedefinieerd kan worden en daarmee platform onafhankelijk blijft.
Dit is slechts een technische aanzet die wel illustreert dat je SOA niet perse in een 5GL / BPM hoek of wat dan ook hoeft te drukken. Het zijn gewoon totaal verschillende dingen.
Nouja, ik heb hiermee wel genoeg kennis gedeeld dacht ik zo 🙂
Ben nog nieuwsgierig naar een reactie van Jack en ben verder ook echt wel benieuwd *wat* hij op de tekentafel heeft liggen.
@Henri
Marketing is what you do when your product is no good.
Betreffende ‘beeldspraak’ van SOA is TCP zonder IP gaat het om de overdracht, je Swahili gaat enkel om een taal. Ik zal het wel weer niet snappen maar is dat niet het deel van wat Jack ook zegt, een federated SOA architectuur waar Pidgin voor het abstraheren zorgt?
Nu zeggen ze ook dat een optimist eigenlijk een slecht geïnformeerde pessimist is, denk dat dit wel een beetje aansluit bij de problematiek die SOA heeft veroorzaakt. Tenslotte lijken we steeds meer problemen te krijgen met het terug vinden van alle informatie door zoals je al zo mooi aangeeft het taalprobleem omdat we dingen verbuigen naar techniek in plaats van andersom. Aangezien de boodschap je telkens ontgaat, een pictogram is een plaatje met duizend woorden.
SOA is een metadata gedreven architectuur maar heeft een blinde vlek voor context, Eskimo’s hebben 100 woorden voor sneeuw en volgens mij sneeuwen we onder in alle digitale informatie doordat het vinden steeds moeilijker wordt. Dat de business alles behalve verantwoordelijkheid wil aangaande data was me al duidelijk.
Henri,
Gewoonweg klasse, de tijd die je steeds weer neemt om discussies voort te zetten! Ik moet wel bekennen dat ik je hoge tempo nauwelijks kan bijbenen. Je hebt dus nog wel wat reacties van mij tegoed, maar anderzijds denk ik dat we elkaar bij volgende opiniestukken en discussies toch wel weer gaan tegenkomen.
Maar nu toch even een paar opmerkingen over je geplaatste reacties.
Je opmerking dat ik inhoud zou willen geven aan de toepassing van SOA vind ik zeer sterk. Wat ik echter vooral wil toevoegen aan SOA is: architectuur! In voorgaande reacties, oa. op jouw laatste opiniestuk, heb ik je “verweten” dat er te weinig architectuur zit in je visie en daar kan ik nu dus aan toevoegen dat de visie van Ewout zelfs architectuurloos is; vandaar dan ook zijn afscheid van SOA!
Als je het met mij eens bent dat SOA een ontkoppeling van data, functionaliteit, flow en presentatie/GUI mogelijk maakt – op z’n minst dus een 4-tier-architectuur, waarbij die presentatielaag bij uitstek dient voor het realiseren van selfservice, en dat desgewenst nog weer via verschillende kanalen – dan vraag ik mij af hoe die uitwisseling van gegevens tussen de verschillende lagen er in jouw visie uitziet. Als een keten van processen waarbij de output van een proces in de bovenliggende laag dient als input van een proces in een onderliggende laag? Op deze manier gerealiseerd gaat selfservice op basis van SOA in ieder geval bij grote applicaties – alleen al door de toename van de complexiteit – de mist in.
Een alternatief voor deze data-gerichte aanpak is dus een doel-gerichte (goal-driven) aanpak, zoals in het verleden al eens is gerealiseerd in een taal als Prolog. Om een aantal redenen performde deze taal zeer slecht; het gaat te ver om hier nu dieper op in te gaan.
Een procesgerichte visie blijkt niet van toepassing op handelingen in het dagelijk leven: je gaat niet naar de keuken om daar aardappelen te schillen, die vervolgens dienen als invoer voor het kookproces. Je gaat wel naar de keuken om een gerecht te bereiden, waarvoor onder andere gekookte aardappelen benodigd kunnen zijn (=servicegerichte of doelgerichte opvatting). En als de aardappelen verrot zijn, dan verruim je je blik en ga je vanzelf de diepte in voor oplossingen.
Je leest er zo maar overheen, maar stel dat ik in de vorige alinea in plaats van keuken badkamer had geschreven, dan was ook de servicegerichte opvatting tamelijk onzinnig geweest. Zowel “keuken” als “badkamer” ontsluiten ruimte waar ik mij naar toe kan begeven; echter, ze ontsluiten wel heel verschillende functionaliteiten. Taal is dus kennis van de wereld; informatie ontstaat altijd op basis van kennis (en niet door het verwerken van data).
De woorden in een taal zijn dus niet symbolen die betekenis krijgen door ze te verwerken; ze blijken in zichzelf betekenis te hebben. Net als objecten in een OO-aanpak worden ze niet verwerkt maar geactiveerd.
Lees nog eens wat prof. Verhelst zegt over ruimtelijk denken (en over flowcharts); par. 3.1 in:
http://www.econ.kuleuven.be/cbl/magazine/magazines/2003/2003-3.pdf
Tot zover eerst mijn reactie; er valt veel meer te zeggen!
Wat mijn tekentafel betreft; misschien bevat mijn profiel al een aardige schets.
@Ewout,
Het zal je waarschijnlijk niet verbazen:
big data is niet zo mijn ding, selfservice des te meer.. 🙂
@Jack
Wordt de hype van big data niet mede gevoed door metadata gedreven model van SOA?
En hiermee bedoel ik met name de metadata in transport als het om de SOA in de cloud gaat doordat er juridisch eigendom hier nogal wazig is. Die metadata is voor gebruikers onzichtbaar maar maakt ze wel traceerbaar.
Hoewel het een semantische discussie is of ‘Internet of Things’ nu wel of niet SOA 2.0 is lijkt het er vanuit mijn optiek veel op. En zoals ik al stelde is Internet geen Enterprise Service Bus doordat eigenaarschap hier diffuus is.
@Henri Je schrijft:
De essentie is dat applicaties (data) met elkaar kunnen praten door middel van services / API’s en dat je dit als architectuur principe hanteert. Dat is de scope van SOA. Niets meer, niets minder. Punt.
Mooie omschrijving, daar kan ik me iets bij voorstellen.
Louis, dank voor je compliment 🙂
Jack,
Thanks voor je reactie. Computable is gewoon een hobby voor me. Sommige lezen nieuwssites, ik verrijk me door te schrijven en te lezen.
We pakken wel weer een keer weer een draadje op om over te bomen. Ik heb je profiel gelezen. Dat had ik eerder gedaan, maar hij is anders dan de laatste keer dat ik hem gelezen heb. Heel interessant. Ik zie mezelf als filosoof, maar vind veel filosofie erg lastig om te lezen. Als het te abstract is, haak ik vaak af. Iemand kan geniaal zijn, maar als je het niet kan vertalen naar een taal die een grote groep bereikt, mist het vaak zijn doel. Zelf hou ik van Griekse filosofie , dialogen vind ik erg behapbaar (Socrates/Plato) en bijvoorbeeld Charles Darwin is mijn grote held.
Mijn aanvliegroute voor elke architectuur is domain driven design. Dit is de absolute basis voor het bouwen van een architectuur en komt voor SOA / Techniek / IT. DDD is in feite ook architectuur. Mooie ervan is dat iedereen het snapt en dat dit dus een brug is tussen IT en de de Business.
De gegeven PDF ga ik nog lezen, maar kom ik hier niet meer op terug.
Wat quotes van jou en mijn korte reflectie daarop:
“Ontkoppeling, zoals mogelijk gemaakt door SOA, heeft de belofte van complexiteitsreductie en flexibiliteitsverhoging; een belofte die juist door het denken in processen, ketens, regels en feiten teniet wordt gedaan.” – Deze belofte zie ik niet meteen aangezien de door jou gebruikte woorden teveel context gevoelig is, bijvoorbeeld : complexiteitsreductie… voor wie? (zelfde geldt voor andere termen). Zonder toelichting is het niet bruikbaar, maar dat komt nog wel een keer.
“De vraag is dus of er een alternatief is voor de proces- en regelgeoriënteerde benaderingen van BRM en BPM, zodat SOA haar belofte van flexibiliteitsverhoging en complexiteitsreductie eindelijk kan waarmaken. In mijn optiek is zo’n benadering er zeker en die luidt……. kunstmatige intelligentie.”
Echte kunstmatige intelligentie is op dit moment kansloos. Wat er het dichts bij komt is “machine learning”. Het vastleggen van patronen van een organisatie of individu die beslissingen kunnen ondersteunen. Als je SOA zoekt kan dit betekenen dat je nieuwsgierig bent naar een geslachtsziekte, of naar een service architectuur.
Zo had ik meer dan tien jaar geleden een BPM systeem gerealiseerd die gelopen workflow paden koppelde aan kosten. Zodoende werd vastgesteld dat als er een klacht kwam op een granieten product het goedkoper was om meteen het product te vervangen, dan de hele cyclus van monteur sturen en het proberen op te lossen. Dit was totaal tegen de intuïtie in.
Dan :
“Een procesgerichte visie blijkt niet van toepassing op handelingen in het dagelijk leven: je gaat niet naar de keuken om daar aardappelen te schillen, die vervolgens dienen als invoer voor het kookproces. Je gaat wel naar de keuken om een gerecht te bereiden, waarvoor onder andere gekookte aardappelen benodigd kunnen zijn (=servicegerichte of doelgerichte opvatting). En als de aardappelen verrot zijn, dan verruim je je blik en ga je vanzelf de diepte in voor oplossingen.”
Ik snap wel wat je zegt en dit lijkt ook een beetje op de discussie tussen BPM en case management. Maar ook daar geldt: In sommige gevallen is case management evil! Juist in omgevingen die zich goed lenen voor standaardisatie, moet je niet kiezen voor flexibiliteit en kenniswerkers. Veel te duur en zal slechte output geven.
Als je thuis naar de keuken gaat wil je lekker en gezond eten, als je bij de Mac werkt wil je gewoon proces gericht bezig zijn. Dus in veel gevallen blijft het “it depends” adagium.
In de discussie komen we verder 🙂
Op naar een volgend artikel!