Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

De kwaaltjes van cloud computing

 

Expert

E D
Iets met ICT, nvt. Expert van voor het topic .

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5115676). © Jaarbeurs IT Media.

7,4


Lees meer over


 

Reacties

Altijd leuk om te lezen dat ik je bezig houd. Ik laaf me altijd aan je kennis en inzichten die mij helpen weer verder na te denken en te onderzoeken zodat ik het weer over mijn favoriete onderwerp kan hebben: Cloud computing.

Tijdens mijn reactie lees ik nogmaals door je opinie heen en zal ik je van repliek dienen. Want er zitten wat inzichten in je betoog verstopt, zelf voor jou zelf, waarmee ik begin met je vergelijkingen met enterprise computing, want dat is zeker geen slechte vergelijking. Cloud computing lijkt in een aantal gevallen zeker op cloud computing en je geeft hiervoor een lijstje met vijf punten waarvoor ik me met name wat IaaS betreft prima ik kan vinden. Punt 1 is echter voor enterprise computing relatief en voor cloud computing absoluut. Wat ik bedoel is dat enterprise computing nog steeds een hoop geld kost, voor MKB vaak teveel, maar dat juist door cloud computing zelfs een freelancer beschikking heeft tot enterprise computing! En dat is wel degelijk revolutionair. Betalen naar gebruik is bij cloud computing veel letterlijker dan bij enterprise computing waarbij je vaak gewoon eigenaar bent van het ijzer en krimpen, een ander krachtig voordeel ten opzichte van enterprise computing, bij enterprise computing in wassen neus is doordat bijvoorbeeld de licentie structuur minder lean is. De zogenaamde "minderkosten" uit punt 2. Punt 3 is bij cloud computing nog veel krachtiger omdat autoscalen tegenwoordig een standaard optie is. De wendbaarheid bij cloud computing gaat dus verder waar enterprise computing stopt. De iteratiesnelheid bij punt 4b is bij cloud computing ook vele malen hoger. Probeer jij maar snel te switchen als je net ff lekker geïnvesteerd hebt in je enterprise computing. Just saying. Zelfs over punt 5 kan ik een voordeel geven van cloud computing boven enterprise computing. Als mijn cloud dienst provider een nieuwe lichting servers heeft kan ik per direct overstappen zonder terug te hoeven krijgen. Life-cycle van bestaand ijzer is niet meer. Ook qua resilience is de snelheid van nieuwe mogelijkheden ongekend. Automatische geo-grafische onafhankelijk recoveren over on-premises / cloud heen lijkt kinderspel te worden, mits je de techniek maar op de juiste manier inzet en tegen minimale kosten. Wel de lusten, niet de lasten.

Eerlijkheid gebied mij te zeggen dat de marketing over deze nieuwe mogelijkheden vaak vooruit loopt op de praktijk, maar zelfs als je dit meeneemt is de "cloud" nog steeds de place to be. Maar genoeg hierover.

SOA is net als cloud computing slechts een duiding, de ene SOA implementatie is de andere niet, gelijk aan de ene cloud is de andere niet. Dit is vooral waar als je beseft dat een dienst afnemen over het internet ook als als cloud computing aangeduid wordt door het Software as a Service te noemen. Iets volstrekt anders dan Infrastructuur als een service of Platform as een service wat helemaal abstract is. Praten over SOA zonder details kan inhoudelijk nooit diepe betekenis hebben. SOA is tot cloud wat BI is tot Big Data. Noem het 2.0 of whatever. Niet cloud computing is/word groot, maar er zijn diensten en eco-systemen die groot worden, teveel focus op cloud computing laat je de bigger picture vertroebelen. Uiteindelijk hebben we het gewoon over diensten van leveranciers, visie op business modellen en maturing van IT standaardisatie. SOA, ofwel het gebruiken van API's vaak in de vorm van webservices afgenomen onder architectuur is wat mij betreft springlevend, ik zweer erbij. Maar erken ook de gevaren in de vorm van performance / beveiliging / wildgroei en foute implementaties en een gebrek aan governance, je laatste alinea kan ik dan ook grootdeels onderschrijven. Ik zal het proberen helder te maken waarom ik dus SOA in mijn ogen de way to go is.

Stel: Er is een grote succesvolle webshop die niet alleen goed boert omdat ze verdienen aan de marge van verkoop versus inkoop, maar die ook nog eens uiterst effectief spullen van bron naar bestemming brengt. Als ze andere webwinkels gebruik kan laten maken van hun automatisering en logistiek zouden ze ook nog eens kunnen verdienen aan de levering van goederen van die andere webshops. Heldere propositie, toch? Hoe kunnen zij dit mogelijk maken? Misschien op vele manieren, maar de facto gebeurt dit door middel van API's in de vorm van webservices. Die grote webwinkel gaat natuurlijk niet zelf met al die pakketjes zeulen, het blijft een webwinkel, geen post bezorger. Dus ergens in de keten praten ze ook met de webservice van de pakketdiensten en koppelen dit weer met de eindgebruiker zodat die meer inzicht (en controle) heeft over de levering, een zeer belangrijk aspect voor het succes van webwinkels. De derde partij die de oplossing van de grote webwinkel adopteert heeft ook weer toegang tot de webservice van de pakketbezorger zodat ook zij hun klant tot dienst kunnen zijn en voila, de SOA cirkel is rond. Nu is het dus mogelijk om een succesvol winkelbedrijf te hebben zonder maar ooit je eigen producten gezien te hebben, de webwinkel zelf is een website als een spin in een web van webservices. Wat je dus ook van SOA vind, de mogelijkheden en kracht zijn in mijn ogen evident.

Mijn verhaal verschilt misschien niet eens zoveel met dat van Ewout, maar zoals uit mijn voorbeeld blijkt is het hebben van een server inderdaad wellicht wat achterhaald.

Wat betreft het data verhaal en eigendom dat is gewoon een kwestie van opletten.

Laat de discussie maar op gang komen, ik sta klaar om e.e.a. toe te lichten...

@Henri
Dat cloud computing het MKB een vorm van Enterprise Computing geeft zal ik niet ontkennen maar de vraag is of MKB zich in dat geval ook bewust is van het feit dat daarmee ook Enterprise beheer bij komt kijken. Juist hier zie ik veel mis gaan omdat op de blauwe ogen van leverancier vertrouwd wordt door 'cloud regiseurs' terwijl er een betere (lees goedkopere) oplossingen zijn zoals een appliance op locatie welke remote beheerd wordt.

Dat ik tegen SOA aanschop heeft misschien te maken met slechte implementaties maar om te stellen dat API's efficient zijn betwist ik als ik kijk naar de overhead in de stack. Desondanks ben ik natuurlijk gek op de API's die het mogelijk maken om beheer te automatiseren hoewel deze vaak vergeten worden door de SOA klutsers. Scripten doe ik tenslotte al sinds Windows 2000 waarmee Microsoft met WMI een goede beheer API leverde en wat tegenwoordig blijkbaar DevOps heet.

Zoals ik al stelde heeft SOA nooit rekening gehouden met data, hergebruik hiervan met principes als Big Data zijn dus die fout toegeven. En als het om data shuffelen gaat tussen parallele verwerkende componenten dan is het netwerk aan de onderkant meestal de bottleneck. Hoewel ik - mede om jouw te sparen - de techniek er een beetje uitgelaten heb zit er een heel verschil in cluster of grip cloud computing.

En Laat me niet lachen over webwinkels, als bestelling op back-order staat of de service te wensen overlaat dan is de klant weg. Betreffende je betoog over API's maak ik hier trouwens liever gebruik van tools die me een mogelijkheid geven om direct de database te manipuleren om zo te voorkomen dat ik een RSI aandoening krijg van al dat klikken om virtuele voorraad aan te vullen.

SOA is toch een beetje gedevalueerd tot een soort van RPG, de Report Program Generator van IBM die het mogelijk maakte om allerlei informatie op te lepelen vanuit de AS/400 en ik bijna 20 jaar geleden deed. Zullen we dus maar zeggen dat de meeste SOA adapten een beetje de 'copy c(r)ats' zijn die interessant lopen te doen bij de business omdat deze niet in staat zijn om fatsoenlijke SQL statements te maken, toch ooit bedoeld om de business een efficiënte manier te geven om te werken met (gestructureerde) data.

@Henri
Kijk ik naar mijn klanten, dat is het MKB, dan zie ik cloud-oplossingen als te duur. De kosten van een eigen server inklusief onderhoud, stroom etc. etc. liggen beduidend onder de kosten van een cloud-oplossing.
Je krijgt tegenwoordig voor relatief weinig geld zoveel kapaciteit bij de koop van een eigen server dat het omslag punt waar cloudcomputing voordelig wordt nog tamelijk hoog ligt.
Misschien heeft dat met de demografie van deze omgeving te maken waar heel veel bedrijfjes met 1 tot 20 medewerkers zijn.

Ik kan met Ewout meegaan als hij stelt dat clodcomputing niet zo nieuw is als graag geroepen wordt, clusteren en virtualiseren bestaan al wat langer, nu doen we dat ook via internet. In dat laatste zit dan het probleem, je verbindingen beveiligen kost namelijk ook het een en ander aan middelen en uren.

Ik heb na het lezen van he5t TOP artikel en de reacties mijn meningen over cloud nog steeds niet bijgesteld.

Juridisch
Ik zie nog steeds geen verbetering in het inzichtelijk maken van juridische aspecten. Wel telkens weer een flinke dosis uitleg en presentatie, begrijpelijk overigens... vanuit eigen koker en perceptie.
Het maakt het verhaal voor potentiële klanten er absoluut niet eenvoudiger op.
Het kan natuurlijk zo zijn dat cloud en paashaas diensten het de klant eenvoudiger zou moeten maken maar daar zitten heel veel haken en ogen aan.

Recent artikel van Insteroute
Ik verwijs graag even naar een recente publicatie hier in Computable van Interoute en mijn reflectie. Dat scheelt zaken dubbel tikken op de zondagmorgen.

Cloud en toevoegende waarde
Vanuit de insteek van en voor mezelf dat elke IT peripheral of, methodiek in en met IT, dat elke stap een 'Toevoegende Waarde' moet hebben, waarom zou je anders gebruik maken van IT, kom ik heel erg vaak tot de conclusie dat die toevoegende waarde er niet altijd is.

Natuurlijk, cloud kan zeker een toevoegende waarde hebben voor bepaalde typen ondernemingen maar ik kom, in het verlengde van een punt van Ewout, de inzichtelijkheid en uitleg van die diensten, de verantwoordelijkheden op cruciale vlakken weer niet tegen.

Ik vind overigens de opmerking van Henri, "Wat betreft het data verhaal en eigendom dat is gewoon een kwestie van opletten." een beetje antireclame. Verwijzend naar een recentelijker omvallen van een cloudleverancier en die van vorig jaar begrijp ik dat eigenaren van die data een flinke kluif hebben gehad weer bij hun data te kunnen komen. Het lijkt me een gezamenlijke verantwoordelijkheid maar juridisch...

Bottleneck
Technisch gezien waarschuw ik zelf al jaren voor die bottlenecks. Of dit nu een proces of procedure weeffout is of een sec technische. Als je in zee gaat met een cloudleverancier heb je namelijk niet alleen met die cloudleverancier te maken. Ik hou het even simpel. Ik zit thuis en bedien mij van UPC. Hardstikke goed en UPC, aardige lui. Maar tussen UPC en mij zit de gemeente, Eneco in dit geval, en die is verantwoordelijk voor de spanning in de wijkkast.

Tussen UPC en mij zit dan ook nog de Kabelboer, die weer niet gekoppeld is aan UPC noch Eneco. Tussen UPC en mij zit overigens ook nog twee andere energieleveranciers en een technische onderneming die twee key components beheerd tussen mij en UPC.

Kort en goed, dit geld ook voor de verbinding tussen mij en het datacenter van de cloudleverancier. Die riep namelijk namelijk dat mijn data 'virtually anywhere' te benaderen zou zijn. Het gaat doorgaans hardstikke goed, maar er is juridisch nogal wat gaande waar het die garantie betreft. (Overmacht)

Last...
Ik ben het zeker met Jan van Leeuwen eens als je stelt dat cloud gewoon niet voor iedereen 'antwoord' is. Het is het inzichtelijk maken van opties maar zeker ook wat dit voor een Klant zal gaan betekenen en eerleijk gezegd, ik hoor de cloudleveranciers natuurlijk niet spreken over bottlenecks of 'Overmacht' tijdens een verkoopverhaaltje... Begrijpelijk.

@Ewout
RPG komt zelfs van de S36 / S38, heb ik ooit ook nog eens een kursus in gehad, man wordt ik oud!

@Jan
Inderdaad wordt nog weleens vergeten dat organisatievorm mede bepalend is voor succes van cloud computing. Lokaal georiënteerd MKB verslikt zich naast dynamiek en netwerk ook nog weleens in taal. Anderzijds kan het natuurlijk ook omgekeerd werken hoewel er uiteindelijk maar weinig multinationals werkelijk een Enterprise zijn, het is in dat geval meer poltiek dan techniek.

Ook de argumentatie voor cloud computing kan omgedraaid worden, lokale resources en remote beheer geeft meer controle, niet alleen juridisch. Zo zijn er ook nog applicances, al dan niet gebaseerd op een reference architecture, die dezelfde eigenschappen hebben als cloud computing.

@NumoQuest
Ik heb Henri vele malen op aspect data gewezen, kroonjuwelen van elke organisatie zijn ook niet de servers. En dit feit wordt nog stelselmatig ontkent door cloud adapten die een achtergrond in het SOA denken hebben. De toekomstvisie van deze evangalisten is dus nogal bekrompen, ze zijn als raaf uit het verhaal van George Orwell die over de suikersnoepberg vertelt. Of misschien moet ik zeggen de 'datasnoepberg' zodat ze hun vaardigheden van rapportgenerators maken kunnen continueren met Big Data hype.

Desondanks denk ik toch dat cloud computing - of in ieder geval de principes ervan - een toegevoegde waarde heeft. Maar dan meer vanuit een simpel uitgangspunt als standaardisatie op zowel techniek als datastroom. Tenslotte zal een groeiende stroom aan ongestructureerde data nimmer voor betere bedrijfsprocessen zorgen. Wie eerst aan cloud computing denkt en dan pas aan het proces is vroeg of laat gewoon de sjaak. Want kijkend naar de organisch gegroeide architecturen met SOA kan ik niet anders concluderen dat dit meer een virus dan een oplossing is.

NumoQuest : "Wat betreft het data verhaal en eigendom dat is gewoon een kwestie van opletten." noem je "een beetje antireclame."
Als je een reis online boekt moet je ook gewoon opletten. Dat is onderdeel van verantwoordelijkheid.

Ewout : Natuurlijk is data een kroonjuweel, met als grote verschil dat je kroonjuwelen niet kunt kopieren en data gelukkig wel. Je opmerking daarna sluit dus totaal niet aan en staat ook los van cloud computing en is gewoon inherent aan IT uitbesteden.

Wat betreft je anti SOA teksten....
Als ik data wil ontsluiten via Apps heb ik een webservice nodig.
Als ik externe bedrijven (leveranciers, klanten) toegang wil geven dat mijn data anders dan via de webpagina zelf heb ik webservices nodig.
Als ik rechten wil consolideren over silo's heen in een IAM heb ik webservices nodig.
Voor praten met de enterprise service bus... heb je webservices nodig

Dit lijstje kan ik eindeloos uitbreiden, maar de strekking is duidelijk: Ieder modern bedrijf heeft webservices nodig. Laat dit nu net de essentie zijn van SOA. Ik welke bocht je jezelf wilt wringen, SOA is nauwelijks een discussie punt. Maar je mag het ook best anders noemen als dat het iets beter maakt.

"Want kijkend naar de organisch gegroeide architecturen met SOA kan ik niet anders concluderen dat dit meer een virus dan een oplossing is."
Dit kun je veel breder zien. Zonder governance over je architectuur worden oplossingen altijd virussen en de enige goede governance is silo overschrijdend. Met of zonder SOA.

Toch zitten we met veel zaken niet heel erg van elkaar af Ewout. Het gaat mij ook meer om de principes die voordelen bieden en niet per se aan de invulling ervan en of dit strikt genomen cloud computing is of niet.

Ik ben totaal niet loyaal aan cloud computing oplossingen van bijvoorbeeld Microsoft Azure of Amazon Webservices. Ik kijk naar wat een dienst me te bieden heeft en gebruik (of adviseer) dat. Komt er een alternatief? Muy bien. Als je de (SOA) architectuur goed op zet is dat redelijk portabel.

Cloud computing diensten bieden mij mogelijkheden om het landschap te verkennen. Te proberen en experimenteren door betalen naar gebruik en volledige zelfbediening. Maar geven met razende snelheid steeds meer krachtige tools tegen zeer lage prijs om oplossingen te deployen, managen, te groeien en te krimpen, te monitoren en veerkrachtig te maken. Deels is dit voorbehouden aan cloud computing via een externe dienst, sommige aspecten zijn ook middels enterprise computing te realiseren.

Jan, als je een vaste server voor 3 jaar afneemt zal de cloud wellicht duurder zijn, de vraag die je moet stellen is echter: Wat doe ik met die server? Als er een specifieke applicatie op moet draaien heb je inderdaad vaak een server nodig. Maar als het gaat om een mail en fileserver, dan zijn er juist mogelijkheden om helemaal geen server meer te nemen. Elke oplossing heeft zijn voors en tegens en als je als bedrijf denkt een server af te nemen in de cloud zodat je het beheer zelf kan doen maar niet snapt wat een server is, dan maak je inderdaad een foute keus.

@Henri

Eens met wat je zegt maar het venijn zit hem commercieel zakelijk erg veel en vaak in de staart, en de hele kleine lettertjes vaak. Als IT professionals er al moeite mee hebben hoe is dit dan voor de vele kleinere ondernemingen waar de hose aan cloudleveranciers de pijlen op richten. Maar in basis wel eens met je stelling.

@Henri
Mail op je eigen server is inderdaad niet de oplossing, daar biedt webhosting/mailhosting al grote voordelen. Bij fileserver wordt het al ietsje lastiger vanwege de data-throughput over je verbindingen, een simpel gigabit-lan is al snel in het voordeel.
Praten we over een databaseserver dan wordt het cloudaanbod meteen een stuk minder aantrekkelijk, ook vanwege de juridische aspekten.
Een bedrijfje met 5 medewerkers is goedkoper uit met een € 3k server die ze in 5 jaar afschrijven, dat beetje kosten aan onderhoud maakt het zeker niet duurder als een cloud-oplossing.

@Jan,

Als we stellen dat onderhoud van een servertje voor een klein bedrijf ca € 80,- per maand kost. Samen met je afschrijving zit je dan al op 1560 per jaar. Daar is het werkplek beheer of applicatiebeheer nog niet in opgenomen.

De meeste cloudbeheerders doen ook applicatiebeheer voor de apps die ze aanbieden en met die dik 300,= per medewerker per jaar kun je al best wat doen.

Wat ik in de advertenties en aanbiedingen vaak zie is dat SAAS modellen worden aangeboden als Cloud model, waar je op zich weer een discussie over zou kunnen starten.

In grote lijnen ben ik het met de eerdere sprekers eens. Maar in zekere zin is er niet zoveel anders dan vroeger toen elk bedrijf een server in de eigen tent moest zetten. Ook toen moest je de juiste adviseur zoeken om een juiste keuze te maken (de commerciele boefjes liepen toen ook al strak in het pak rond). Ook beheer was toen nodig.

Wat ik vaak in mijn omgeving zie (vooral kleine MKB klanten)is dat men naar "het nieuwe werken" wil. Gelukkig krijgen steeds meer plekken glasvezel internet beschikbaar, maar op dit moment is alleen al gelet op netwerk performance (naar het internet) toch wel iets te zeggen voor het hosten in een cloud omgeving.

@Ewout,

heb jij al vaker geschreven over je aversie tegen SOA? Zo ja, post svp eens wat linkjes.

Ik ben persoonlijk geinteresseerd in architectuur en zie in SOA opzetjes juist voordeel, omdat we naar een steeds meer gekoppelde samenleving gaan die ook nog eens steeds sneller moet schalen.

Bovendien zie ik op heel veel plekken koppelingen direct op de database mis lopen, omdat je erg grote afhankelijkheden inbouwt op iets wat niet meer dan een koppelvlak is (of moet zijn).

Ik leer graag, dus gooi je anti-soa artikelen in de groep. Benieuwd naar de mening van iemand die er zijn vak van heeft gemaakt.

@Henri
Waarom vertaal je service telkens naar webservice?
Waarom heeft elk modern bedrijf webservices nodig?

Als je over governance begint is het misschien interessant te kijken naar de roep om een Chief Data Officer. Deze zal zich naar mijn opinie bezig moeten houden met de Business Intelligence vraagstukken zoals welke data er bewaard MOET en MAG worden.

Ik laat in het midden of ik andere dingen lees of dingen anders lees maar jouw klanten zijn nog niet de klanten van de klant. Direct alles met een webservice invullen zorgt dus nog weleens voor 'paarse krokodil' situaties.

Betreffende discussies e-mail oplossingen wijs ik graag op eerdere opinies hierover, een brievenbus is nog geen systeem. Ook hier ligt de focus namelijk nog weleens op het gemak in plaats van de data waardoor er informatie verloren gaat.

Dat er iemand wat tegengas geeft bij de cloud hype lijkt mij juist interessant. Met name voor de cloud evangelisten. Niet dat ze dit soort verhalen dagelijks horen maar met name dat ze in discussie kunnen gaan met medestanders.

Wat het voorbeeld van de webshop betreft zou ik heel goed oppassen om dit als cloud-voorbeeld te gebruiken. Als jij een kleine webshop meer voor de hobby dan wat anders wilt hebben dan is een cloud versie zeker interessant.

Echter heb je een volledige business draaien en je bent als webshop wat forser dan gemiddeld dan is de cloud helemaal geen optie. De beschikbare software voor dit soort webshops is helemaal niet gemaakt voor de cloud. Dus zul je je eigen ijzer ergens in een rack moeten hebben. En daar zit dan vaak ook specifiek maatwerk bij met vaak ook ontsluiting naar legacy. Dan wil je qua architectuur ook nog eens alles bij elkaar hebben zodat je geen gigabytes over het internet moet gaan sleuren en updates near real-time een must zijn.

@Benno
Mijn aversie betreffende SOA richt zich op het ontbreken van een visie rond data, het gaat niet om de service die deze toegankelijk maakt maar de visie om deze te integreren tot informatie. Veel SOA oplossingen - zoals een ESB - maken van de gebruiker een interface wat een aantal nadelen heeft als het gaat om governance. De koppelvlakken worden hierin een steeds grotere uitdaging.

Dat je met webservices naast de primaire data voor het proces ook allerlei secundaire informatie kunt verzamelen zorgt ervoor dat het vertrouwen in digitale dienstverlening met rasse schreven afneemt. Dit geldt met name voor veel webshops die naast de bestelling ook allerlei klantgegevens verzamelen.

Betreffende koppelingen direct op de database zitten er natuurlijk enige afhankelijkheden aan de keuzen die je op deze datalaag gedaan hebt, de business logic in bijvoorbeeld stored procedures leggen heeft inderdaad als nadeel dat je afhankelijk bent van product. Voordeel is echter dat het vaak veel efficienter is.

Het intrigeert me dat je stelt dat SOA het bestaan van data negeert, of dat een visie rond data zou ontbreken.
Op zich zelf is het prima om termen als Cloud en SOA niet al te veel als heilige graal te zien, maar als je de marketing taal rondom Cloud en SOA even negeert, dan zijn het in mijn ogen toch logische vervolgstappen in de hedendaagse software ontwikkeling. Ook een nieuwere term (hype?) als API Management is dat, omdat services binnen een organisatie iets andere eisen stelt dan organisatie-overstijgende services.
Integreren op de data laag geeft een gevoel van teruggaan in de tijd met alle nadelen van EAI, want als je SOA ten volle wilt benutten moet je werken met open standaarden en belangrijke principes als Loosely Coupling en Autonomy. Dit gezegd hebbende, zie je dat de verschillende databases as a service in de cloud kennelijk ook een behoefte bevredigen voor rechtstreekse interactie met een datalaag, zonder al te veel logica eromheen.
Hoe dan ook, service georienteerde omgevingen zijn overal en niet meer weg te denken. Technisch gezien wordt oneindig veel data en informatie rondgepompt. Hoe en waar die data dan wordt opgeslagen is m.i. iets minder relevant.
Maar misschien richt jou aversie zich op slecht geimplementeerde SOA omgevingen waarin onnodig veel data wordt rondgepompt omdat er niet goed over de informatie architectuur is nagedacht.

@Friso
Eerlijk zegt weet ik niet waar ik jouw reactie nu moet plaatsen, bevrediging met services versus het rondpompen van data lijkt mijn stelling te bevestigen. Een stelling die je misschien intrigeert maar welke je helaas dus niet ontkracht.

Een ontsluiting van de datalaag zonder zorg voor de data is dus als de bloemetjes buiten zetten zonder je te bekommeren over de gevolgen daarvan. Leuk dat je open standaards aan de discussie toevoegd maar dat lijkt me misplaatst aangezien SOA concept sterk functioneel gedreven is.

De in jouw ogen overbodige logica is vaak het ecosysteem die hele business proces overeind houdt. Het gaat namelijk niet waar de data opgeslagen wordt maar hoe omdat dit in grote mate dus de governance bepaald. Nu er eindeljk met PIA aandacht komt neemt de behoefte aan een CDO tenslotte toe, aan de overkant van de haringplas vooral gedreven door class action lawsuits.

Me aansluitend bij enkele eerdere reageerders ben ik van mening dat het diensten-concept onmisbaar is voor een goede verdere ontwikkeling van ict-toepassingen. En bij uitstek geschikt is om de relatie met business-mensen te verbeteren omdat zij als geen ander gewend zijn te denken in termen van diensten. Ik denk dat ze het zouden toejuichen als IT'er dat vaker zouden doen. Met gemopper op "soa" als bron van alle kwaad ga je volgens mij precies de verkeerde kant op.

@Ad
Relatie verbeteren tussen de IT en de business is één, relatie verbeteren tussen de business en de klant is twee. Ik stelde in mijn opinie dat SOA het aspect data negeert en tot op heden blijf ik daarin volharden. Je aansluiten bij de reageerders die een blinde vlek hebben voor de core asset van een bedrijf lijkt me nogal frappant voor een informatie architect.

Recentelijk gaf ik ongezouten mening over de praktijkcase door een 'We hebben een hamer dus alles is een spijker' consultant over een waterschap. Van een informatie probleem werd een data probleem gemaakt zodat het op het bordje van de IT gelegd kon worden. Dat is naar mijn opinie niet de relatie verbeteren, zeker niet als ik kijk de klanttevredenheid.

Kijkend naar het doorbreken van de 'code of silence' van klokkenluiders noemde ik niet voor niks IOA welke gaat om business intelligence. Vandaag interessante en internationale discussie gehad over Information Risk/Right Management wat een steeds grotere uitdaging wordt. Veel compliance officers - de CDO 0.9 - steken hun hoofd nog in het zand om tegen de mol te kunnen vertellen dat het prachtig weer is.

Stellen dat het diensten-concept onmisbaar is voor goede ontwikkeling van ICT diensten lijkt me in tegenspraak met imago probleem dat de overheid heeft betreffende de digitale dienstverlening. En zeggen dat het aan de dienstverlener ligt is gewoon onzin, je kunt verantwoordelijkheid niet uitbesteden hoewel de overheid - lees business - dat dus wel telkens probeert.

Ewout,

Laat ik de vraag eens omdraaien. Als soa niet goed is, hoe moet het dan wel? Want dat verklap je niet.

Want dat governance een essentieel onderdeel is bij soa kan ik me iets bij voorstellen. Maar dat soa- data negeert mist juist het punt, of het punt is bij mij niet doorgedrongen. Soa bestaat bij de gratie van data, zonder data geen soa. Dus als er soais moet er data bestaan, dat kan niet anders.

Maar hoe dit een speerpunt is geworden van kwaaltjes over cloud computing...

@Henri
De vraag stellen is hem beantwoorden, EAI is misschien wat sleets geraakt door alle verleidingen van goedkope resources maar het valt me op dat bij SOA het antwoord vaak een (web)service is voordat de business vraag überhaupt nog maar gesteld is. Het hangt er natuurlijk maar vanaf wat je viewpoint is maar uiteindelijk gaat het om de prestatie van de business, dat techniek sneller wordt zegt tenslotte niets over het end-to-end proces.

SOA klutsers zijn daardoor toch wel een beetje de Pavlov hondjes van de IT welke telkens beginnen te kwijlen als er weer wat nieuws op de markt is. Commercieel is het hergebruik van ervaring natuurlijk niet aantrekkelijk want zoals ik al aangaf in mijn opinie worden oude schoenen nog weleens weggegooid voordat de nieuwe ingelopen zijn. Toch altijd leuk dat jij me vraagt hoe het dan wel moet, met dat dienstgerichte denken van SOA zou ik zeggen: RTFM;-)

Sorry Ewout, dat je geen cloud- en soa-fan bent maak je goed duidelijk. Maar de onderbouwing blijft wat mij betreft warrig. Laat ik de TFM gaan lezen of zo.

@Ad
*zucht*

1. Ik zie cloud computing als een delivery model, één van de vele die we hebben, en niet als wondermiddel.
2. SOA zijn business georïenteerde principes, geen klant of IT georïenteerde principes zoals ik duidelijk stel.

Betreffende je opmerking over wel of geen fan aangaande SOA: "When the shit hits the fan, it's all get messy" Vergeet niet dat service level agreements inspanningsverplichtingen zijn en nog geen garantie voor resultaten.

Misschien ben ik warrig maar kijkend naar de realiteit ligt er nog een behoorlijke uitdaging in de optimalisatie van processen, met name binnen Enterprises. Horizontale processen over vertikale structuren levert als ik me niet vergis ook nog flink wat problemen op binnen de decentrale overheid.

Ewout,

Je beide punten lijken mij niet correct.

1) Cloud computing is meer dan alleen een leveringsmodel. SaaS, PaaS en IaaS zijn leveringsmodellen, cloud computing zelf is niet alleen een business model, maar ook een stuk techniek.

2) SOA is Software georiënteerd ontwerp "patroon" (design pattern), dus wel degelijk IT georiënteerd.

Als je al met foutieve aannames begint kan de rest al bijna niet meer kloppen.

Daarnaast ontwijk je mijn vraag over hoe het wel moet, gooi je er weer een paar afkortingen tegenaan. En kom je weer met hoe het niet moet.

SOA is geen cloud computing en kan ook prima zonder cloud computing. Dus dat je SOA een zwaartepunt maakt doet afbreuk aan je artikel die zou moeten gaan over de kwaaltjes van cloud computing.

Ik zeg; terug naar de tekentafel!

@Henri
SOA is TCP zonder IP, IT is meer dan infrastructuur.

Ewout,

De laatste bijdrage in deze boeiende discussie, voortgekomen uit jouw al even boeiende opiniestuk, is van een week geleden, dus de hoogste tijd om deze weer op gang te brengen.

In een eerdere reactie stelde ik:
“SOA als procestechnologie (al of niet in combinatie met BPM) is terecht doodverklaard;
SOA als kennistechnologie is springlevend en heeft dus de toekomst”,
dus je zult begrijpen dat ik het slechts ten dele met je eens ben.

Ik onderschrijf je aversie tegen SOA, voor zover deze de procesgeoriënteerde variant betreft.

Daarmee is de discussie rond SOA wel urgent, gezien het feit dat deze procesgeoriënteerde visie op SOA de literatuur, de markt en de uiteindelijke toepassing in bedrijfsapplicaties voor 100% domineert.
Het heeft dus niet zoveel zin om TFM te lezen :-)

Met andere woorden; SOA als kennistechnologie (wat ik ook wel aanduid met 5GL/SOA) bestaat vooral nog op de tekentafel (en gezien de bijval die ik op dit forum krijg moet ik concluderen: mijn tekentafel).

Als je stelt dat SOA het bestaan van data negeert, dan zet ik daar in eerste instantie vraagtekens bij, omdat uitgerekend de procesgeoriënteerde visie op SOA (vanaf nu kortweg aangeduid met SOA/BPM) beschouwd kan worden als een data-gedreven (en ook wel event-gedreven) aanpak.

SOA abstraheert inderdaad van de fysieke opslag van gegevens; het zal SOA (en dus zowel de interne businessklant als de externe klant) een biet zijn of gegevens hiërarchisch, relationeel, object-georiënteerd of anderszins zijn vastgelegd in databases. Maar abstraheren is niet hetzelfde als negeren.

Hier zit wel een gemene adder onder het gras: object-relational impedance mismatch; het verschijnsel dat gegevens uit relationele databases nogal moeizaam zijn te mappen op objecten (en dus ook op services!). Mogelijk moet het gebruik van relationele databases binnen SOA dus worden afgeraden.

Je stelling dat SOA het bestaan van data negeert is terug te vinden in het volgende document:
http://www.insideanalysis.com/wp-content/uploads/2012/04/TheIOA-WP-Final-0419.pdf ;
het past ook bij mijn stelling dat de hedendaagse SOA’s procesgeoriënteerd zijn.

Nu wordt in dit (overigens zeer toegankelijke) document wel terecht gesteld dat SOA een volgende stap is in een evolutie van programmeertechnieken die valt onder het objectgeoriënteerde paradigma; het lijkt mij echter niet terecht om de OO-aanpak een vorm van procesoriëntatie te noemen. OO was al voorbij de proces-data dichotomie, en datzelfde zou dus voor SOA in nog sterkere mate moeten gelden; ware het niet dat SOA ten onrechte toch weer in de proces-pool van deze dichotomie wordt geduwd. Om Information Oriented Architecture (IOA) vervolgens aan de data-kant binnen deze dichotomie op te zetten; blijkbaar als een verdere abstractie van het relationele model. 5GL/SOA is echter ver voorbij de tegenstelling tussen IOA en procesgeoriënteerde SOA!

Blijft dus de vraag in hoeverre (je terecht stelt dat) de procesgeoriënteerde visie op SOA verweten kan worden dat het data negeert (een verwijt dat 5GL/SOA uiteraard niet valt te maken). Mijns inziens gaat het vooral (en uitgerekend) mis in de bedrijfsproceslaag; de laag die precies wordt vormgegeven met BPM-tools en met kretologie als “orkestratie”. In eerdere reacties heb ik het 5GL/SOA-alternatief voor deze laag al voorgesteld: Flow-services.

Samenvattend: Henri Koppen slaat de plank mis door vast te blijven houden aan SOA/BPM (en bovendien door SOA geen punt van discussie te noemen); jij slaat de plank mis door afscheid te nemen van alle vormen van SOA en anno 2014 nog eens aan te komen met IOA.

@Jack
Dat we het eens zijn dat SOA al dan niet met BPM de data zelf nog steeds negeert is mooi meegenomen, dat we van mening verschillen over IOA heeft misschien te maken met het feit dat ik er vanuit beheer naar kijk. Misschien sla ik de plank mis maar er zijn nog planken vol met archiefdozen al dan niet digitaal. Dat code en techniek sneller evolueren dan organisaties probeerde ik duidelijk te maken met de wet van Moore, residu van alle ontwikkelingen is data waarvan de ongestructureerde volumes steeds groter worden doordat we niet alleen steeds meer digitaliseren maar ook niets weggooien. Of de rap groeiende databerg het gevolg is van SOA klutsers 1.0 of een organisatie die niet de laatste versie ervan geadopteerd heeft maakt voor het resultaat niet uit. Service richt zich (nu) teveel op de business wat een gevolg kan zijn van de proces- in plaats van klantorientatie maar dat is lood om oud ijzer.

Ik durf in 2014 dus best aan te komen met IOA als ik overweeg dat veel organisaties nog werken met systemen uit de vorige eeuw

Jack, beetje pretensieus om SOA zoals dit door 90% van de wereld blijkbaar wordt gezien af te schrijven en iets op jouw tekentafel als de waarheid te verkondigen en vanuit die redenatie te schrijven dat ik de plank mis sla.

Je probeert inhoudt te geven aan de *toepassing* van SOA. Maar dat is in mijn ogen niet terecht. 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.

Dat je een SOA gebruikt voor 5GL / BPM / IOA, sure. Je doet het tegenovergestelde van Ewout, die probeert cloud computing plat te slaan naar een leveringsmodel. Terwijl cloud computing veel meer is. Jij probeert SOA veel meer te maken dan het is.

In onze huidige wereld van cloud computing, virtualisatie, API's en diensten die met elkaar kunnen praten is SOA gewoon een feit. Het wordt alleen niet zo genoemg, muy bien.

Tegenwoordig wordt BI als Big Data verkocht, sure. Dat is marketing.

"het verschijnsel dat gegevens uit relationele databases nogal moeizaam zijn te mappen op objecten (en dus ook op services!). Mogelijk moet het gebruik van relationele databases binnen SOA dus worden afgeraden."
- Wat de toekomst is van relationele databases is ongewis, maar wat je schrijft ben ik het wederom niet mee eens. Ten eerste; een record in een tabel kun je prima als object benaderen en met ORM er bovenop kun je dat prima als basis gebruiken om met services te praten. Wil je als object in zijn geheel communiceren? Sure, parse hem naar JSON en je bent klaar.

De open vraagt blijft dus: Wie slaat hier de plank mis?

Maar zoals ik eerder schreef, SOA is Off Topic :-)

@Henri
Als we alle planken bij elkaar nemen hebben we genoeg om SOA te 'kisten' en ten grave te brengen;-)

Als service klutser moet je eens ophouden om spijkers te leveren als de klant om schroeven vraagt, lees overdrachtelijk nog eens dat stukje over grottekening en infographic als je twijfelt over delivery model van cloud computing.

Ewout, de term misschien, de realiteit is ieder bedrijf steeds meer gebaseerd wordt op SOA.

Ik zal mijn argumenten nogmaals in andere bewoordingen met je delen, want er is nauwelijks een andere conclusie mogelijk.

Hoe verbinden applicaties zich aan een server voor data? Met een rechtstreekse verbinding of via Open DataBase Connectivity (ODBC). Dit is jarenlang het (enige) model geweest, en bij browser applicaties is dit nog steeds dominant. De webserver staat vaal heel dicht bij de database server.

Maar wat als je data moest delen met andere applicaties buiten de organisatie. Daarvoor werd in de eerste instantie Integrated Development Environment (IDE) voor bedacht -dit was nog voor de opkomst van het internet- wat in de praktijk vaak een gedrocht werd.

Tegenwoordig zie je ook nog wel dat er ingewikkelde VPN verbindingen worden opgezet, of een firewall geconfigureerd wordt om een andere applicatie toegang te geven tot een deel van de database.

Dit is technisch uitdagend, heeft een hoge doorlooptijd en is gewoon gevoelig en schaalt niet.

In een wereld waarin alles met alles kunnen verbinden steeds meer het nieuwe normaal is: Je smartphone kan wel met 20 verschillende systemen verbinden (maar los van het data delen tussen deze apps), en samenwerkingen tussen organisaties wordt steeds normaler moest er er iets anders komen en dit is de facto webservices geworden.

Als je applicaties bouwt met webservices als fundament, dan heb je hiermee een aantal krachtige voordelen als het aankomt op integratie, veiligheid en schaalbaarheid. Het is ook heel flexibel en uitbereidbaar en bovenal, je werkt hiermee platform onafhankelijk, iedere andere tool kan met je communiceren door middel van deze webservice. Wie hiervan de kracht niet ziet of zich ertegen afzet, zal dan wel een alternatief moeten noemen en dit onderbouwen.

In mijn ogen hebben webservices als basis voor client server applicaties twee nadelen : Performance en Beheersbaarheid. Een webservice is fundamenteel trager dan een client-(database)server verbinding, het is namelijk een tussenlaag die in zichzelf performance kost en ook de output van een webservice is gewoon minder efficiënt dan een database connectie. Deze twee nadelen kunnen echter in veel gevallen gemitigeerd worden doordat een webservice van nature schaalbaar is, je kunt er vrij simpele rekenkracht tegenaan gooien. En beheersbaarheid wordt vooral aangetast omdat men steeds meer kan en dat het dus gemakkelijk is een oerwoud aan verwevenheden te creëren. Maar als je de webservice net zo traditioneel inzet als je client-server verbinding is er niets aan het handje en heb je zelfs meer meetmogenlijkheden dan daarvoor. Want als de business heel veel wil en je gebruikt *geen* webservices, dan heb je pas een probleem!

Oja, dat richten op webservices als de de facto standaard binnen een bedrijf en bouwen onder architectuur, dat noemt men SOA.

Dus Ewout, de opjager van service klutsers, ik zou graag een aanpak lezen hoe je de integratie en flexibiliteit wensen van de business oplost zonder SOA. Ik ben oprecht benieuwd!

Ik zou graag zien dat er gaten geschoten worden op bovenstaande, dat is dan per definitie leerzaam voor me, of helpt me argumenten aan te scherpen.

Maar bovenstaande is in mijn ogen een hele toegankelijke uitleg over de geschiedenis van SOA en webservices.

@Henri
Je vraagt je toch af hoe ze het vroeger deden. Oh wacht, ik riep iets over grottekeningen die misschien wel als pre-historische infographic gebruikt werden.

Tuurlijk is het mooi dat we alles en iedereen over de hele wereld kunnen verbinden en zo informatie uitwisselen met de snelheid van het licht. Die dynamiek biedt kansen maar zoals we ondertussen merken ook bedreigingen.

In een heel korte reactie naar jouw stelde ik dat SOA nog teveel TCP zonder IP is. Ik kan het mis hebben maar Jack lijkt in zijn betoog uit te gaan van het Informatie Protocol in plaats van het Techniek-Communicatie Probleem.

Nogmaals, cloud computing is TCP en dus niet meer dan een delivery model.

Dat ik wat gekscherend over SOA doe komt door klutsers die van alles een webservice willen maken, altijd lachen bij Service Desks. Als je belt dat Internet het niet doet vertellen ze dat je naar de website moet gaan om een incident aan te maken. Snap jij het?

SOA is misschien niet dood maar herdefinieer eerst de service, deze laat nog weleens te wensen over. Maar misschien komt dat wel door de semantische dementie als je begrijpt wat ik bedoel.

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!

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×