Wil de it-organisatie relevantie houden, dan moet het roer drastisch om. Door het model van een cloud services broker te omarmen kan business zich richten waar het echt om gaat. Innovatie! Charles Darwin zei het al: 'It is not the strongest of species that survives, nor the most intelligent. It is the one that is most adaptable to change.'
Zelfs als cloud voorstander had ik het er afgelopen jaar wel eens moeilijk mee. We werden continu overladen met reclame en informatie over cloud -producten en diensten die vaak niet veel zeggend waren. Met een oplossing zonder het woord cloud erin kon je in 2013 niet aankomen!
Paradigma verschuiving
Toch is de massale aandacht voor cloud helemaal niet zo gek, het past in de trend van bewustzijn over focus op kernprocessen en daarmee gepaard gaande doorlooptijd, flexibiliteit en kosten. Door de economische crisis en het volwassen worden van clouddiensten treedt er een zichzelf versterkend effect op. De Amerikaanse overheid had al een cloud first policy aangenomen en dit schuift langzaam op naar cloud only. Deze trend van (uitsluitend) interne it naar hybride of zelfs uitsluitend externe it-diensten gaat komende jaren alleen maar versnellen. Volgens IDC groeit de cloud-markt 23,5 procent jaar op jaar. Dat is vijf maal zo veel als de it-industrie in zijn geheel. Geen wonder dat softwareleveranciers deze boot niet willen missen.
Zo koos PostNL onlangs voor een extreme it-strategie door massaal in te zetten op clouddiensten van Microsoft en Amazon en de eigen it-organisatie te halveren. Een hand vol kernapplicaties blijft achter. Een van de redenen om hiervoor te kiezen was kosten: de mogelijkheid om snel te kunnen afschalen. Voor PostNL gezien hun krimpende markt bittere noodzaak.
Nu it steeds meer een zaak gaat worden van het spel tussen verschillende partijen moet een it-organisatie steeds meer rekening houden met verschillende belangen en deze goed op elkaar afstemmen. Om dit spel goed te beheersen is het centraal beleggen van vraag en aanbod cruciaal. De term die Gartner geeft aan cloudsourcing noemt men Cloud Services Brokerage (CSB). Het gebruik van hiervan is een middel om niet alleen het afstemmen van vraag en aanbod maar ook aspecten als integratie, migratie, beveiliging, beschikbaarheid en doorbelasting van kosten centraal te houden. Zo worden het inrichten van diensten zoals een centrale helpdesk, single-sign-on (sso) en identity & access management randvoorwaardelijk voor het slagen van een Cloud Services Broker.
Evolueren of uitsterven
Het gevaar bestaat dus dat it geleidelijk helemaal buiten de eigen it-organisatie wordt geplaatst. Hoe kan de it-organisatie dan overleven? Door zich te transformeren van een aanbod naar een vraag gestuurde afdeling. Dat wil zeggen actief in te spelen op de vraag en duidelijke meerwaarde voor de business te leveren. De it-organisatie zou het Cloud Services Broker-model kunnen omarmen om tot een hybride cloudplatform te komen met geautomatiseerde diensten. En deze in te richten en met bijbehorende dienstverlening. Hiermee heeft de it-organisatie een middel in handen om snel in te spelen op de behoefte van de business zonder de controle te verliezen.
Doordat de it-organisatie zich dan richt op het zo snel en goed mogelijk leveren van geautomatiseerde diensten kan de business zich richten op waar het echt om gaat, namelijk business innovaties. Door het gebruik van een cloudservices-catalogus waar continu nieuwe best-of-breed diensten of zelfs bouwblokken in worden gepubliceerd kunnen deze direct worden afgenomen en met elkaar worden gecombineerd zodat nieuwe applicaties en/of diensten ontstaan. Gartner spreekt van pace layered applications.
Het vermogen om snel op verandering in te spelen gaat steeds meer het succes van bedrijven bepalen. Wie dat het slimst doet is heer en meester.
@Jack
SOA is een concept uit de ICT architectuur dat niet echt grootschalig is toegepast en in 2009 is doodverklaard : http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
In de SAP wereld waar ik in werk, is het concept nooit aangeslagen. Dat komt onder andere omdat er onder de motorkap niets fundamenteels veranderde. Bovendien kost het teveel om te implementeren en te onderhouden. Waarom zou je een webservice creëen als een simpele functie hetzelfde kan doen ? SOA is een hype gebleken … deal with it.
KJ
Grappig dat je het artikel aanhaalt, het is in mijn ogen een goed artikel, maar de kern van het artikel is deze regel:
“Although the word ‘SOA’ is dead, the requirement for service-oriented architecture is stronger than ever.”
Met andere woorden: In cloud computing hangt alles aan elkaar met services (API’s) en dat zou je met een ander woord SOA kunnen noemen.
Het woord is dood, het verbinden van diensten gaat via platform onafhankelijke API’s is echter mainstream. Dus SOA is steeds meer de de factor standaard.
Dat SOA en SAP nooit is aangeslagen lijkt logisch. Als je alles in één systeem hebt, waarom zou je dat dan willen ontsluiten op een platform onafhankelijke manier. Nu is dit niet mijn kennis gebied, maar ik kan me niet anders voorstellen dat ook SAP zich uiteindelijk gewoon voegt naar de rest van de wereld en het woord wellicht dood is, maar niet de achterliggende gedachte. Want ook SAP zal steeds meer toegang moeten verlenen aan de buitenwereld.
Dat SOA een veelkoppig monster is lijkt me evident. Een foute toepassing (SOA doen zonder over SOA te hebben nagedacht) is namelijk een zekere manier om het fout te doen waardoor het bijt. SOA zou altijd toegepast moeten worden vanuit een strategie en een systeem. Puntsoplossingen zijn altijd listig en verleidelijk. Ze kunnen voor en tegen je werken. Het kan dus goed zijn EN fout.
@Ewout,
Mooie reactie, waaruit ons verschil van inzicht blijkt. Voor jou is legacy de keuze die gemaakt wordt om niet te investeren in kennis, voor mij de keuze die gemaakt wordt om niet te investeren in kennistechnologie (lees: SOA).
Een op een mainframe draaiende silo-applicatie is legacy, ook al is alle kennis voor beheer en onderhoud nog steeds aanwezig in de organisatie. Veel ernstiger is het natuurlijk als deze kennis inmiddels is verdwenen.
Een belangrijk deel van de vermeende inefficiëntie van SOA wordt mijns inziens overigens veroorzaakt door het aanhoudende procesdenken, expliciet in de vorm van BPM, waardoor onvoldoende inhoud is gegeven aan de eerder genoemde Business Flow Services. In mijn optiek is het concept van Business Flow Services de *tegenhanger* van wat Resa in zijn uitstekende opiniestuk “I AM in de cloud” de orkestratie van processen noemt. En zeer terecht stelt hij in een reactie: “We zijn gewend om de werkprocessen als klein of grote blokjes neer te zetten zonder intelligentielaag er tussen. De uitvoering van het proces in de hele keten moeten we als een domino effect zien. Wanneer er geen verbindingsbrug tussen twee blokjes is dan stopt de werking en verlaagt de efficiëntie. “
@kj,
SOA als procestechnologie (al of niet in combinatie met BPM) is terecht doodverklaard;
SOA als kennistechnologie is springlevend en heeft dus de toekomst.
@Henri,
Ook al een mooie reactie, waaruit ons verschil van inzicht blijkt.
Voor jou is cloud computing de basis, en SOA de bonus.
Voor mij is SOA de basis, en cloud computing de bonus.
In mijn optiek loopt de weg van legacy naar cloud computing over SOA. Legacy wordt gekenmerkt door een sterke verwevenheid van data, functionaliteit en flow (of afwikkelingsvolgorde), waardoor deze systemen steeds moeilijker en moeizamer zijn aan te passen aan veranderende bedrijfsomstandigheden in de markt, de wetgeving en de technologie. Bovendien voldoet legacy vaak niet aan de eisen voor realtime verwerking, die selfservice tegenwoordig vaak stelt.
Ontvlechten (of ontkoppelen) van data, functionaliteit en flow uit de legacy doe je met SOA en niet met cloud computing; even een pijl trekken vanuit de legacy naar de wolk, zoals in de afbeelding bij het opiniestuk, is dus te kort door de bocht.
@Jack
BPM versus SOA maakt al duidelijk dat principe niet klopt, als je het grote geheel in kleine stukjes moet delen om het begrijpbaar te houden mis je de aansluiting:-)
@Ewout, @kj, @Henri,
http://www.ingovernment.nl/blog/hoezo-processen
Jack, dank voor de link, gelezen ook. Snap zijn bedoeling wel, maar ben het er niet mee eens.
Dat bepaalde mensen herhalende saaie handelingen uit moeten voeren voor een proces, hoort er nu eenmaal bij. Het zou wat zijn als we hier principieel tegen zouden zijn en daarom maar afschaffen.
Of moeten we helemaal een holistische kijk op de wereld hebben en ons afvragen of rijkdom nu wel wenselijk is? Niet iedereen is een kenniswerker, niet iedereen heeft de capaciteit om een kenniswerker te zijn.
Ik ben dus voor standaardisatie in processen die nu eenmaal standaard zouden moeten zijn.
Henri, je zegt:
Niet iedereen is een kenniswerker, niet iedereen heeft de capaciteit om een kenniswerker te zijn.
Maar misschien komt het de flexibiliteit van een organisatie wel enorm ten goede als je iedere medewerker beschouwt als kenniswerker (overigens, wat ieder mens ook in wezen is!).
Natuurlijk kun je een lopende band medewerker beschouwen als een machine die werkzaamheden uitvoert met of aan een machine. Maar bij de minste of geringste storing komt het productieproces stil te liggen, omdat deze als machine beschouwde medewerker zowel de kennis als de motivatie ontbeert om de storing zo snel mogelijk te verhelpen. Beschouw je deze medewerker echter als kenniswerker (en dus als mens), dan heeft deze persoon wel de kennis, motivatie en verantwoordelijkheid om het productieprobleem zo snel mogelijk te verhelpen.
Hetzelfde geldt voor de ondersteunende bedrijfstechnologie; die kun je inrichten als procestechnologie OF als kennistechnologie. Richt je het in als procestechnologie, dan geeft dat een verlaging van de flexibiliteit en een verhoging van de complexiteit (zoals de bekende legacy-systemen al laten zien). Bedrijfstechnologie inrichten als kennistechnologie heeft precies het omgekeerde effect.
Jack,
Niemand wil een robot zijn, maar ik ervaar dat veel mensen het als een verademing zien als het systeem verteld welke werkzaamheden eruit gevoerd moeten worden en hoe.
Kenniswerkers zijn relatief duur en werk wat met kennis gedaan moet worden overigens ook. Daarnaast is het moeilijker het werk onderling uit te wisselen en is er meer inwerktijd nodig en zo kan ik nog wel een riedel opnoemen. Je bent te romantisch.
Natuurlijk is robot versus kenniswerken een schaal waar je niet snel op de uiteinden zit. En persoonlijk contact tussen mensen onderling lijkt me evident. Ik koppel het werk los van de mens en zie de mens zeker niet als “human resource”.
Ook je laatste alinea ben ik het vrijwel oneens, maar daarbij moet ik wel opmerken dat je elkaar makkelijk verkeerd kan begrijpen. Overigens verplaats je de complexiteit, je verhoogt of verlaagd hem niet.
Maar dit is zeker genoeg stof om een keer een boom over op te zetten! Denk wel dat daar een zinvolle discussie over kunnen hebben.