Door Dik Bijl, Enterprise Architect, Microsoft Nederland
Dit is het slotartikel van een zevendelige serie over SOA. Zoals in de titel staat aangegeven komt er een korte terugblik op de serie, gevolgd door aanbevelingen die u verder op het spoor brengt van deze architectuur. U kunt over SOA lezen, mijmeren en praten tot u een ons weegt, maar feitelijk is de “proof of the pudding in the eating”. En mijn vraag aan u als TDM-er (Technical Decision Maker) is: “bent u al zover dat u een praktische stap wilt maken met SOA?”.
In dit artikel hoop ik wat handvatten te geven waarmee u die stap echt kunt maken. De handvatten bestaan uit de beschrijving van een tweetal cases - bedrijven die u al zijn voorgegaan en daarmee succes hebben behaald - en de architectural guidance rondom SOA. Microsoft biedt veel architectural guidance en ik kan hier nauwelijks een tipje van de sluier oplichten, maar zoals gebruikelijk geef ik aan het slot van het artikel een aantal links, waarop u zelf kunt doorspitten.
Ik sluit het artikel af met iets wat ik zelf ook nog niet voor ogen had toen ik driekwart jaar geleden aan deze serie begon. Microsoft heeft net deze zomer een nieuwe visie gelanceerd rondom SOA; noem het SOA versie 2. Een van de veranderingen is dat we het vanuit Microsoft minder over SOA gaan hebben en meer over (de 5 pilaren van) “Connected Systems”. Hoe of wat dat betekent, leest u verderop.
Samenvatting
Mijn voornaamste doel voor het schrijven van deze serie was om met u mijn enthousiasme voor het service georiënteerd denken te delen. Ik vind dat dit nieuwe denken over IT niet de zoveelste hype is, maar echt een wezenlijke doorbraak, net als indertijd het client/server denken. De reden waarom ik dat vind is omdat, net als bij client/server, serviceoriëntatie eerst en vooral een beproefd business-concept en een beproefde business-strategie is; en niet alleen maar de zoveelste nieuwe technologie. Ik heb dat vooral in afleveringen twee en drie duidelijk geprobeerd te maken.
Die relatie met de business-strategie biedt een paar voordelen. In de eerste plaats: als het een beproefd model is op basis waarvan het bedrijfsleven en eigenlijk breder: de maatschappij - in elk geval: de reële wereld - zichzelf organiseert, dan moet het ook een goed model kunnen zijn voor de organisatie van de IT - de virtuele wereld - , nietwaar?
Dat heeft te maken met mijn eigen vooronderstelling dat er niet zo verschrikkelijk veel manieren zijn waarop activiteiten goed georganiseerd (dat wil zeggen: opgedeeld en gecoördineerd) kunnen worden en dat de maatschappij, het bedrijfsleven daarin ver voorloopt op de IT: daar is het allemaal voor het eerst bedacht, uitgevoerd en bijgeschaafd.
In de tweede plaats: als de IT(-infrastructuur) zich organiseert op dezelfde manier als het bedrijfsleven, dan is er automatisch sprake van een goede afstemming (‘alignment') tussen business en IT. IT-ers zijn al heel lang op zoek naar manieren om de IT beter af te stemmen op de business en deze lijkt me heel natuurlijk.
Tenslotte, als het service georiënteerd denken een goed en beproefd business-concept is, dan zullen business-mensen het ook goed begrijpen. En IT-ers zijn nog veel langer op zoek naar een manier waarop ze de toegevoegde waarde van IT beter kunnen uitleggen aan mensen uit de business. Let wel, dit zijn allemaal niet-technologische redenen waarom ik zo enthousiast over dit concept ben.
Qua architectuur biedt het service georiënteerd denken enerzijds veel perspectief, maar anderzijds ook flink wat uitdagingen. Het is nieuw en anders en je moet als architect door een ‘paradigma verschuiving' heen, wil je de voordelen ervan echt snappen. Vergelijk het met het veranderen van je denken van procedure-gericht of gegevens (of: database)-centrisch denken naar object georiënteerd denken. Zo'n paradigma verschuiving vereist een ‘herprogrammering' van je hersenen, van je denken.
De basisprincipes van service georiënteerd denken zoals in aflevering 3 beschreven vormen daartoe slechts een eerste aanzet. Net als met de principes van overerving, inkapseling en polymorfisme zal het wel even duren voor bij iedereen het kwartje valt. Het goed vormgeven van een SOA heeft alles te maken met het goed snappen en uitvoeren van de basisprincipes. Verderop geef ik wat eerste beginselen op het vlak van de architectural guidance, maar toegegeven: er valt nog heel wat werk te verzetten op dat gebied.
De volgende stap is de keuze met welke technologie je dat service georiënteerde denken wilt gaan realiseren in je IT-landschap. Er zijn verschillende technologieën waarmee je SOA kunt realiseren, maar tot voor kort waren al die technologieën bedrijfseigen (‘proprietary') en leidde de keuze voor een technologie vrijwel direct tot een ‘lock in'.
Wat dat betreft is de webservicesarchitectuur een katalysator voor de acceptatie van het service georiënteerd denken geworden. IT-leveranciers hebben zich op grote schaal achter deze technologie voor gedistribueerde verwerking (‘distributed processing') hebben. De IT-afnemer - U als klant - is al lang voorbij de vraag of web services wel een succes gaat worden; nu rest alleen nog de vraag: wanneer.
Waar aflevering 4 sprak over webservices als beste manier om een SOA te realiseren, heb ik in afleveringen 5 en 6 een pleidooi gehouden voor Microsoft als beste leverancier van op webservicesarchitectuur gebaseerde technologieën.
Enerzijds vanuit de lange termijn geredeneerd: Microsoft is een bedrijf dat aan de wieg van web services heeft gestaan, nog steeds als de trekker ervan wordt gezien, dat een goede visie en een paar krachtige strategische initiatieven heeft voor de verdere ontwikkeling van de IT binnen de enterprise en dat zich voorlopig geen zorgen over zijn voortbestaan hoeft te maken.
Anderzijds is Microsoft eerst en vooral leverancier van een softwareplatform waarop anderen oplossingen kunnen maken; en dat is Microsoft vanaf zijn eerste bestaan geweest. Microsoft is altijd goed voor ontwikkelaars en eindgebruikers geweest en is dat ook in toenemende mate voor de architect en de IT-beheerder aan het worden.
De webservice gerelateerde producten en technologieën die nu al bestaan en voortdurend worden uitgebreid en verbeterd zijn in aflevering 6 aan bod gekomen. Dit en volgend jaar zijn belangrijk met het oog op het bieden van nieuwe producten ter ondersteuning voor het service georiënteerd denken: VS.NET 2005, SQL Server 2005, BizTalk Server 2006 en “Indigo” (nu: Windows Communication Foundation - WCF).
Daarmee heb ik hopelijk mijn belofte uit aflevering 1 waargemaakt. Namelijk dat ik in de achter ons liggende reeks de volgende stelling zou uitbouwen en onderbouwen: “Een SOA is een uitstekende architectuur ter ondersteuning van de business-strategie waarbij business en IT optimaal op elkaar afgestemd zijn, die het best met behulp van de webservicesstandaards technisch gerealiseerd kan worden, waarbij Microsoft het beste softwareplatform en de beste implementatie van de webservicesstandaards biedt.”
Aanbevelingen
Stel u bent inmiddels overtuigd van de waarde van het service georiënteerd denken, maar wat als u de volgende stap wilt maken, de daad bij het woord wil voegen. Het restant van dit artikel bestaat uit aanbevelingen die ik u graag meegeef op uw reis naar het SOA-paradijs.
Die aanbevelingen zijn heel beknopt:
- Leer van de ‘early adopters' van webservices en SOA
- Neem notie van architectural guidance die Microsoft en anderen u bieden
- Pas op voor oversimplificatie en voor overhypte WEA's als SOA en ESB (WEA=Weer Een Acroniem)
Dell
Dell is een echte early adopter op het gebied van webservices. Al in 2001 is het met leveranciers van onderdelen van voor de Dell-computers in de slag gegaan om de levering van onderdelen beter af te stemmen op het productieschema van Dell, dat uitsluitend op “build to order” basis werkt. Dat leidde tot behoorlijke besparingen op de voorraden; besparingen voor zowel Dell als zijn toeleveranciers.
Ook aan de voorkant - de verkoopkant - is Dell geleidelijk aan met webservices gaan werken. Daarvoor is het gebruik gaan maken van Microsoft's .NET technologieën. Het begon als een soort test met een vijftal webservices om de verkoop via partners en de klanttevredenheid te verhogen.
Een webservice bood partners als Yahoo!, C|Net en ZDNet “real time” prijsinformatie aan direct uit de online pc configuratie-engine waarvan Dell.com gebruik maakt. Op die wijze konden die partners die informatie op hun eigen sites in hun eigen stijl aanbieden. Een andere webservice gaf klanten inzicht in de actuele orderstatus door informatie te vergaren vanuit de warenhuizen van Dell en die van zijn verschepers.
De ervaringen met het gebruik van webservices - die elk voor zich een reëel business-voordeel boden - leidde ertoe dat Dell steeds meer webservices ging gebruiken als schil rondom zijn eigen back end systemen en die van zijn partners.
In maart 2003 begon Dell met een nieuw project: het Integrated Dell Desktop (IDD) om een nijpend business-probleem op te lossen. Klanten van Dell gebruiken ofwel Dell.com om hun orders te plaatsen ofwel de Dell call centers waar de “inside salesforce” van Dell actief is. Vaak gingen klanten eerst op Dell.com kijken en hun systemen pre-configureren om vervolgens het call center te bellen voor verder advies en definitieve bestelling.
De call center medewerkers hadden echter niet dezelfde geïntegreerde Dell.com ervaring als hun klanten, maar moesten informatie putten uit een 40-tal back end systemen om de klant goed te kunnen bedienen. Back end systemen met informatie over eerdere prijsvoorstellen, hun huidige winkelmandje, klachtenafhandelingen, service calls, correspondentie etc.
Figuur 1: Dell IDD
IDD is ontwikkeld als smart client applicatie dat gebruik maakt van de reeds bestaande webserviceslaag die Dell in twee jaar tijd had vervaardigd aangevuld met een aantal nieuwe webservices om de behoeften van IDD af te dekken [figuur 1]. Door gebruik te maken van WinForms in plaats van WebForms (voor thin client browser based applicaties) kon alle functionaliteit van de lokale pc worden aangesproken: rekenkracht, geheugen, display, integratie met randapparaten en andere lokaal draaiende applicaties zoals de call routeringsapplicatie.
Dit leidde tot een applicatie die sneller gebouwd kon worden, veel minder code bevatte, eenvoudiger aanpasbaar was en die tegelijkertijd ook een betere ervaring voor de gebruiker opleverde. Als een bestaande klant nu belt wordt via de call routering applicatie informatie aan de smart client applicatie doorgegeven waarna via een aantal webservice calls de complete klanthistorie wordt geladen in de lokale cache van de smart client applicatie. Daardoor heeft de verkoper in een klap alle relevante informatie van de klant voorhanden inclusief de pc-configuraties die de klant zojuist via Dell.com had ingegeven.
Dit bespaart niet alleen veel tijd in het afhandelen van de call maar verbetert zowel de ervaring van de salesrep als die van de klant. Dell berekende dat IDD een ROI van een factor 9 had. Daardoor is besloten IDD versneld wereldwijd uit te rollen, het uit te breiden met meer functionaliteit en om gelijksoortige applicaties voor andere groepen medewerkers (customer care, technical support) te gaan ontwikkelen.
Dell begon klein, zocht naar ‘low hanging fruit' en experimenteerde met webservices technologie maar altijd gericht op het verbeteren van de business value en onderbouwd met een business case en een ROI-berekening. Naarmate Dell meer ervaring kreeg en successen boekte, breidde het verder uit en ging langzaam maar zeker in de richting van een full scale SOA met smart client webservices consumptie.
Thomson
Thomson Financial is een van de grootste aanbieders van financiële gegevens en analyse in de financiële industrie.Het heeft een kleine 8000 medewerkers in 22 landen met een omzet van ongeveer 1,5 miljard US dollars. Thomson bestaat uit een 40-tal verschillende business units, waarvan vele door overnames zijn toegevoegd.
In het begin heeft Thomson de services zoals die door de overgenomen partijen werd geleverd volledig intact gelaten. Meer en meer begon er overlap in de dienstverlening te ontstaan, wilde men de klanten beter geïntegreerde services aanbieden en zocht men naar kostenreductie door consolidatie. De klanten van Thomson zijn andere bedrijven uit de financiële sector. Thomson wilde zijn klanten de mogelijkheid bieden om zijn services direct als API aan te bieden, zodat die klanten de services in hun eigen systemen konden opnemen.
Maar daarnaast wilde Thomson ook een eenvoudig aanpasbare user interface met de rijkheid en flexibiliteit van een windows desktop. Dat leidde ook hier - net als bij Dell - tot een oplossing met een tweetal primaire componenten: een servicelaag dat de business-functionaliteit inkapselde en beschikbaar werd gesteld als een set herbuikbare webservices; en een smart client applicatie die de services programmatisch benaderde en een optimale gebruikservaring aanbood.
De voornaamste business-voordelen waren: betere afstemming op de klantbehoeften, een grotere gebruiksproductiviteit, snelle integratie met klantsystemen en snellere ontwikkeling van nieuwe, aanvullende functionaliteit. Dat alles leidde tot een grotere verkoop van services.
Architectural guidance
Zowel Dell als Thomson hebben bij het geleidelijke opzetten en inrichten van hun SOA een beroep gedaan op het Architecture Strategy Team (AST) van Microsoft. Dat team bezit veel kennis van hoe een op (web) services gericht IT-landschap in te richten: vanaf de grote lijnen tot en met meer gedetailleerde ‘patterns' en best practices.
Ze brachten niet alleen kennis mee, maar deden in die projecten ook weer verdere kennis en ervaring op. En op basis van die in de praktijk getoetste en verworven kennis hebben de architecten en ontwikkelaars van Microsoft weer gepubliceerd, zodat anderen niet elk wiel opnieuw hoeven uit te vinden cq hun teen aan iedere steen hoeven te stoten. En van die kennis en ervaring kunt u als trendvolger zeer veel leren.
De in aflevering drie beschreven vier basisprincipes van service oriëntatie zijn onder meer een gevolg van de ervaringen die productarchitecten en projectarchitecten opgedaan hebben bij het maken van nieuwe producten als Indigo of BizTalk en bij het uitvoeren van praktijkprojecten als bij Dell en Thomson.
Veel van de productarchitecten bij Microsoft zijn architecten met een lange historie op het gebied gedistribueerde verwerking; denk aan illustere namen als Jim Gray, Pat Helland en Don Box.
Veel principes van gedistribueerde verwerking zijn toepasbaar op serviceoriëntatie, maar zeker niet alles. Een berucht voorbeeld is de two phase commit (2PC): een mechanisme dat ontwikkeld is om te zorgen dat in een gebdistribueerde omgeving met gedistribueerde databases een transactie zich aan het atomaire principe houdt (‘alles of niets') en daarmee de consistentie en integriteit van gegevens waarborgt.
2PC is prima toepasbaar in een volledig gecontroleerde omgeving en waar sprake is van tight coupling van applicaties (componenten, programma's, services). Maar in een omgeving waar de autonomie van services een basisprincipe is, is het bepaald geen ‘best practice'. Het protocol is weliswaar opgenomen is in de WS-Transaction specificatie - en dus kun je het gebruiken - maar het is praktisch alleen toepasbaar voor services binnen de grens van het eigen IT-landschap, waar men dus alles onder controle heeft.
Een service wordt dan voor bepaalde tijd gelocked, totdat alle in de transactie deelnemende services hun wijzigingen hebben doorgevoerd en zich daaraan gecommitteerd. Maar het houden van een lock door een andere service druist in tegen de autonomie van services. Stel dat u een bepaalde service biedt aan derden en opeens wordt uw service door een van die derden gelocked in het kader van een gedistribueerde transactie. Dat is uitermate onwenselijk. Het kan zelfs tot een Denial of Service (DoS) leiden: uw service is voor onbepaalde tijd niet beschikbaar voor anderen.
Een veel betere manier om in een wereld van autonome services de consistentie en integriteit van gegevens te waarborgen is om in termen van reserveringen en compensaties te denken. Dus eigenlijk net als in de reële wereld; denk eens aan het reserveren, bevestigen en cancelen van hotelkamers en vliegtickets. Ook die specificaties maken onderdeel uit van WS-Transaction. Overigens is dit opnieuw een voorbeeld waarbij de reële, business wereld model staat voor de IT wereld.
Veel architectural guidance heeft betrekking op het ontwerp en de inrichting van de service: hoe grof of fijnmazig moet een service zijn; hoe algemeen of specifiek en hoe abstract of concreet; welke ‘internals' mag/moet de buitenwereld weten en welke niet, etcetera? Daarnaast is er veel guidance voor het samenstellen en verwerken van berichten: berichten kunnen verloren gaan, meerdere keren aankomen, in een verkeerde volgorde aankomen. Hoe ontwerp je de berichten en berichtverwerking zodanig dat je met die omgewenste situaties rekening houdt en je services er tegen beschermt?
Er is heel veel guidance beschikbaar. Aan het eind van het artikel staat een aantal links opgenomen waarmee u zich verder kunt oriënteren. Het kennis nemen van die guidance is zeker noodzakelijk, maar een kleine waarschuwing is op zijn plaats. De relatieve onvolwassenheid van het SOA-vakgebied leidt er echter toe dat niet iedereen het eens is over welke guidance en practices nu echt het beste zijn. vooralsnog blijft u daarbij zelf de scherprechter, maar verwacht in de naaste toekomst verbetering en meer overeenstemming op dat terrein.
Connected Systems
De ervaring die Microsoft in de praktijk heeft opgedaan met web services en SOA heeft geleid tot een aangescherpte visie op het vakgebied. Zoals in de inleiding verteld vangen we dit nieuwe denken onder de noemer van “Connected Systems”. Het omvat SOA maar Microsoft realiseert zich dat er meer voor nodig is dan alleen service georiënteerd denken om een landschap van waardevolle gekoppelde systemen/services te krijgen. SOA is een wellicht noodzakelijke, maar in elk geval niet voldoende voorwaarde.
De enorme aandacht die vele analisten en leveranciers aan acroniemen als SOA en ESB (Enterprise Service Bus) hebben gegeven, hebben het vakgebied eerder vertroebeld dan verhelderd. Er is geen eensluidende definitie van SOA: veel leveranciers verengen SOA tot een product, terwijl het ons inziens een evolutionair ontwikkelde set van architectuur principes is (die zoals ik in de reeks betoogd heb zijn oorsprong in de business strategie en business architectuur vind).
Hetzelfde geldt voor de hype rondom ESB: ook hier gaat het primair om een set van architectuur principes en patronen, dat later verengd is tot een product of set van producten. Omdat ESB een hype is geworden, hebben vele leveranciers hun bestaande MOM en EAI producten omgedoopt tot ESB en de definitie van ESB zodanig aangepast dat hun eigen producten er precies inpasten.
Microsoft komt tot de conclusie dat de klant met deze versimpeling en verenging tot een paar producten niet gebaat is. Vandaar dat Microsoft weg wil van het gebruik van pasklare, simplistische acroniemen en zich wil richten op de materie waarom het gaat. Service oriëntatie is een middel tot een doel: het doel is het koppelen van systemen (van mensen, machines, processen) zodanig dat het de business strategie versterkt en ondersteunt.
En service oriëntatie is niet het enige middel; er zijn er meer. De figuur hieronder laat zien dat voor Connected Systems vijf pilaren nodig zijn namelijk: service oriëntatie, integrated user experience, pervasive workflow, federated identity and federated data.
Figuur 2: Connected Systems: 5 pilaren
Over service oriëntatie is al heel veel gezegd in deze reeks: het biedt een evolutionaire benadering voor het ontwikkelen van gedistribueerde systemen op basis van ‘loose coupling' van op zich autonome services. De komst van de webservicesarchitectuur en de vele tools ervoor heeft het ontwikkelen van service georiënteerde systemen sterk vereenvoudigd. Overigens niet alleen het bouwen van nieuwe services ook het inkapselen van bestaande systemen als services is mogelijk.
Sevice orientatie alleen is echter niet voldoende voor het doel van Connected Systems. Het gaat namelijk niet alleen om “service delivery”, met andere woorden het aanbieden van de service, maar ook om de mogelijkheid die services te consumeren op een betekenisvolle manier. Service consumptie moet passen in de context en de werkprocessen van de werknemer, de klant en de partner. Connected Systems biedt Integrated User Experience door gebruik te maken van technologische mogelijkheden als smart clients, web applicaties en mobiele devices.
Workflow vind je in alle niveaus van Connected Systems - van formele orkestraties van bedrijfsprocessen tot en met de flexibele, ad hoc ‘workflow' die je tegenkomt bij de samenwerking binnen teams. Workflow is dynamisch en gemakkelijk aan te passen aan de groei en richting van de organisatie. Maar niet alleen het modelleren van workflow, ook het monitoren en analyseren van workflow is belangrijk met het oog op de doelmatigheid van de diverse formele en ad hoc werkprocessen en het goed kunnen reageren op uitzonderingen op de procesregels.
Als gebruikers verschillende services consumeren en die services autonoom zijn en zich dus overal kunnen bevinden - zowel binnen als buiten de organisatie - dan is het op een correcte manier toegang krijgen tot die services van belang. Is de gebruiker wel geautoriseerd; is hij wel de persoon die hij zegt te zijn? Dit alles moet gecontroleerd worden, maar zonder dat die gebruiker daarvan last heeft. Hem moet niet bij elke service consumptie om zijn credentials worden gevraagd. We komen daarmee op het gebied van Single Sign On en Identity Management in een federale, gedistribueerde omgeving met veel verschillende ‘trust' domeinen; met andere woorden Federated Identity.
Federated Data tenslotte betreft de noodzaak om een goed afgestemd en geïntegreerd beeld te krijgen van de informatie die samengesteld wordt uit verschillende gegevensbronnen. En dat terwijl die bronnen allemaal hun eigen onafhankelijke definitie van en view op de onderliggende gegevens hebben. Hoe stem je dat goed af; hoe synchroniseer je? Het gaat daarbij om zaken “entity aggregation”, “master data management” en het gebruik van goede gegevensanalyse en data mining.
Al deze 5 pilaren zijn dus nodig om tot Connected Systems - het doel - te komen. Dwars over deze pilaren spelen zaken als geïntegreerde beveiliging, management en niet te vergeten governance van connected systems, maar ook de geïntegreerde toolset en modellering om connected systems mee te ontwikkelen.
Deze visie van Connected Systems is erg “vers van de pers”; reden waarom ik er niet eerder aandacht aan heb kunnen besteden in deze reeks. Maar het is mijn bedoeling u hier binnenkort uitgebreider over te informeren.
Microsoft neemt “Connected Systems” zeer serieus. Dat blijkt uit het feit dat Microsoft per 1 augustus een nieuwe divisie met die naam heeft opgericht. Binnen deze divisie zijn alle activiteiten van de Distributed Systems Group (DSG) en de Business Process/Integration Division (BPID) nu gebundeld waardoor producten als BizTalk, Active Directory (Identity Management) en Windows Communication Foundation (voorheen: Indigo) nu onder hetzelfde management vallen en nog beter op elkaar afgestemd kunnen worden.
Maar het gaat niet alleen om het samenbinden van deze producten, het gaat veel meer om de onderlinge afstemming van de vijf genoemde pilaren. En ook om de architectural guidance op dit gebied beter te organiseren en stroomlijnen.
Tot slot
Aan het slot van deze serie heb ik een tweetal verzoeken aan u...
Ten eerste: wat vond u van de serie? Heeft het u geholpen om beter inzicht te krijgen in en meer geloof te krijgen voor het service georiënteerde denken? Heeft het iets toegevoegd aan de enorme reeks van artikelen, rapporten, boeken en beschouwingen over SOA? Is Microsoft's positie u duidelijker geworden?
U kunt mij dit laten weten door een e-mail te sturen naar dikbijl@microsoft.com graag onder vermelding van “reactie SOA-reeks”.
Ten tweede: ik ben van plan een boekje te schrijven over de nieuwe visie van Microsoft omtrent “Connected Systems” met daarin aandacht voor de verschillende, hier zeer kort benoemde pilaren van Connected Systems. Als u belangstelling heeft voor zo'n boekje - online of op papier - laat het me dan per e-mail weten; doe dat dan onder vermelding van “reactie boekje Connected Systems”.
Links
Cases
Guidance (een greep)
Connected Systems
| 
