SAP ENTERPRISE SOA: TOP-DOWN OF BOTTOM-UP PROCESSEN VERBETEREN

SAP ENTERPRISE SOA: TOP-DOWN OF BOTTOM-UP PROCESSEN VERBETEREN Publicatie juli 2009 Niek de Visscher Inter Access B.V. SAP Enterprise SOA Architect Solution Driver SAP Enterprise SOA & Netweaver Copyright Inter Access B.V. 2009 ©

  

Hoe kan SOA daadwerkelijk bijdragen aan het verbeteren van processen? Wat is de beste manier om (Enterprise) SOA geadopteerd te krijgen en zo snel en kwalitatief mogelijk op een SOA-compliant manier te gaan werken? En hoe zit de ideale aanpak eruit om op een zo kort mogelijk termijn de business-vruchten van SOA te plukken?

Het is geen gemakkelijke opgave om de ratio en de beste SOA-aanpak te vinden en zo onze processen te laten excelleren en resultaten te verbeteren door vooral beter en sneller te kunnen zijn dan onze concurrent(en). Daarbij spelen niet enkel technologische keuzes een rol maar ook het bepalen van de ‘kop en de staart’. Hoe krijgen we zo snel mogelijk de eerste opbrengsten van een procesverbetering met behulp van SOA? In dit artikel vindt u een korte beschrijving van de business impact van SOA, inclusief een voorbeeld van een volwassenheidsmodel voor SOA d.m.v. CMMI. Daarnaast leest u hoe SOA business benefits kan realiseren vanuit een technologisch oogpunt. De essentie van het verhaal wordt echter gevormd door een positionering van 2 mogelijke benaderingen van SOA-adoptie en –implementatie: top-down of bottom-up. Daarbij vindt u een model waarmee u kunt vaststellen welke aanpak voor uw situatie het beste past, de impact van de gekozen aanpak, een stappenplan voor elke aanpak en een historische analoog met een andere sector met als doelstelling om u aangrijpingspunten te geven voor het managen van de gekozen aanpak. Laten we eerst beginnen met het grootste voordeel van een SOA: flexibiliteit.

INHOUD

Flexibiliteit met SAP Netweaver ................................................................................................................................3 Bottom-up .................................................................................................................................................................4 Low-hanging fruit ......................................................................................................................................................5 Top-down ..................................................................................................................................................................6 De SOA-behoeften piramide .....................................................................................................................................7 stappenplannen ........................................................................................................................................................8 Skunk-Works ...........................................................................................................................................................10 Conclusie .................................................................................................................................................................11

© Inter Access B.V. 2009 2 Niek de Visscher

SAP ENTERPRISE SOA: TOP-DOWN OF BOTTOM-UP PROCESSEN VERBETEREN FLEXIBILITEIT MET SAP NETWEAVER Met behulp van SAP Enterprise SOA kunnen we sneller en flexibel anticiperen en reageren op interne situaties (een crisis) en/of externe gebeurtenissen (een crisis) die ons dwingen om te veranderen, die ons noodzaken om onze bedrijfsprocessen snel te renoveren en te verbeteren via de automatisering met SAP.

HOE KAN SAP NETWEAVER EN DE SOA TECHNOLOGIE VAN SAP ONS DAARMEE HELPEN? De SOA-producten van het SAP Netweaver platform zijn gebaseerd op open standaarden die zo kunnen leiden tot kosteffectieve implementaties. De standaarden worden namelijk breed ondersteund door een verscheidenheid aan leveranciers en platformen. Applicaties die op basis van de SOA-principes zijn ontwikkeld werken samen met andere applicaties, systemen of databronnen via ‘losjes-gekoppelde’ interactie. De schakel in deze samenwerking tussen systemen wordt gevormd door webservices (met als standaarden WSDL en SOAP). Binnen SAP Netweaver maken webservices de link van de (composite) applicatie met de SAP Enterprise Services waarbij de orchestratie en de ontwikkeling vaak via SAP Process Integration plaatsvindt. Door het gebruik van Enterprise Services kan SAP vanuit andere (ook nonSAP) applicaties worden benaderd als een ‘blackbox’ van backend processen die geen logica op applicatieniveau meer nodig hebben. Deze logica is samengevat in Enterprise Services en gebundeld in de Enterprise Service Repository (de ESR). Zo krijgen we applicaties die veel meer flexibiliteit tonen bij het opnieuw gebruiken en combineren van reeds bestaande applicatielogica en veel meer gefocust kunnen zijn op efficiëntie in het gebruik en naadloze integratie met de werkomgeving en de desktop (High Performance Workplace) en zelfs leuk kunnen zijn in het gebruik ervan. Algemeen geldt voor SOA dat men verder bouwt op bestaande systemen en processen, zodat vroegere investeringen niet verloren (hoeven te) gaan. SOA met SAP is procesgestuurd en de semantiek wordt steeds meer van een businessmatige aard: ‘IT -business assimilatie’ in plaats van ‘IT-business integratie’ kan zo worden gerealiseerd en zo wordt SAP een proces-optimizer in plaats van een proces-enabler.


In feite kan SOA als volgt een impact op de business hebben:

Business impact

Business transformatie

Business optimalisatie

Business feedback

Kostenbesparing

Nieuwe functionaliteit

Tijd 1)

DE BUSINESS IMPACT EN FASERING VAN SOA

Alleen is ‘een SOA met SAP’ niet zomaar te bouwen of uit te rollen. De implementatie van SOA heeft veel te maken met zaken zoals de keuze voor standaarden, de ontwikkeling van een technologische visie en bijhorende producten en de Business Case maar (vooral) ook met de activering van gebruikers, de concrete aanpak van de verbetering van operationele processen en het creëren van draagvlak. Dé perfecte methodiek en dé ideale best practices voor de implementatie van SOA met SAP zijn er niet en we moeten dus aan de hand van de specifieke situatie bepalen welke aanpak nu het beste zou kunnen passen: topdown, beginnend bij de business case en de strategische context of bottom-up, beginnend bij de aanpak van concrete problemen op operationeel niveau van de applicaties. Doen door te bewijzen of bewijzen door te doen.

BOTTOM-UP De bottom-up aanpak is een manier met mogelijk veel resultaat op korte termijn (afhankelijk van de specifieke situatie), met de nadruk op direct processen verbeteren, zichtbaar kosten besparen, concreet realiseren van


draagvlak door de hele organisatie heen en het hebben van absolute controle op de SOA-realisatie en het SOA denken bouwproces. Kortom, een p(l)akkende SOA-olievlek die zich beetje bij beetje verspreidt binnen de organisatie en de gebruikers een glimlach op het gezicht tovert, omdat het opeens zo veel leuker is om met SAP te werken (via de browser, de juiste informatie voor de juiste persoon,…) en het blijkbaar ook allemaal zo intuïtief kan, terwijl er aan de andere kant van de gebruikersinterface veel gestructureerder kan worden gemeten, er goede en bruikbare KPI’s verzameld kunnen worden, er veel makkelijker wijzigingen doorgevoerd kunnen worden en dat terwijl de processen sneller en efficiënter aangestuurd kunnen worden en ons van de juiste informatie kunnen voorzien. Dit moeten we echter niet hals over kop doen. We moeten nadenken over waar we de eerste oliedruppels laten landen en hoe we dan verder gaan. Laten we zeggen, een bottom-up benadering die begint bij de gebruikers met het aanpakken van processen die een Quick-Win kunnen zijn. Dit soort processen zijn:       

Operationeel van aard Niet te complex Veroorzaken ‘pijn’ bij gebruikers en de organisatie (lees: bezorgen een ‘duur’ gevoel) Zijn belangrijk Zijn zichtbaar voor de gebruikerscommunity Kunnen op korte termijn worden aangepakt Afgebeeld in SAP

LOW-HANGING FRUIT Jazeker. Daar is niets mis mee zolang het maar het grotere doel dient, namelijk ‘adoptie’ van SOA door de organisatie vanuit de gedachte dat SOA niet meer dan een kapstok is, de concretisering van een gedachte en de gemakkelijke beschikbaarheid van technologische rocket-science om, samen met BPM en adaptive IT, betere resultaten te gaan behalen. SOA als kapstok, BPM als de manier van werken, ‘procesgestuurd handelen en denken’, ‘processen verbeteren’ en ‘resultaten boeken’, want daar gaat het in essentie om. Quick-and-Dirty? Absoluut niet. Bottom-up SOA adoptie is geen gemakkelijke opgave omdat er vanuit de aard van het project weinig tot geen aandacht is voor indrukwekkende papieren tijgers of ingewikkelde veranderingsprogramma’s en de organisatie en haar functionarissen dus erg snel ‘met de billen bloot’ moeten. Er moet kennis en inzicht worden getoond. Deze aanpak vergt een enorme dosis ambitie, doorzettingsvermogen, bevlogen en betrokken ‘guru’s’, parate proceskenners, flexibiliteit, stressbestendigheid en vooral een zeer goed uitgedacht aanvalsplan en bijhorende methodiek en/of een specifiek framework.


TOP-DOWN Bottom-up past echter niet altijd want soms is het namelijk juist wel nodig om de zaken top-down aan te pakken. Dit is met name zo voor organisaties die:  

al een zekere maturiteit binnen het procesdenken en de service-oriented architectuur hebben gerealiseerd of, die te maken hebben met uitdrukkelijke regulering en governance, bijvoorbeeld omwille van de producten waarmee de organisatie werkt, de privacywetgeving waaraan de specifieke businessmaterie onderhevig is of de publieke aard van de organisatie. 1

De SOA-maturiteit van een organisatie kan worden uitgedrukt binnen een CMMI referentiekader, waarbij aan elk CMMI-level een doelstelling t.a.v. SOA wordt gelinkt.

CMMI-LEVEL CMMI Optimizing

5 4 3 2 1 CMMI Quantitatively Managed

CMMI Defined

CMMI Managed

CMMI Performed

SOA-DOELSTELLING Business optimalisatie

Business transformatie

Business feedback

Kostenbesparing

Nieuwe functionaliteit

1

Het CMMI is een volwassenheidsmodel voor systeemontwikkeling, softwareontwikkeling, geïntegreerde producten procesontwikkeling en leveranciersmanagement. Uitgebreide informatie op: http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration.


2)

SOA MATURITY MODEL EN CMMI LEVELS MET KEY BUSINESS IMPACT.

Naast deze benadering is het belangrijk om te kijken naar meer specifieke elementen. Deze specifieke elementen kunnen we uitzetten in een ‘SOA-behoeften piramide’.

DE SOA-BEHOEFTEN PIRAMIDE De SOA-behoeften piramide is geenszins even academisch onderbouwd als de behoeftepiramide van Abraham H. Maslow maar biedt wel een goede kapstok om structuur te geven aan organisatiespecifieke behoeften t.a.v. SOA (en BPM). Belangrijk hierbij is dat deze specifieke behoeften met de juiste aanpak omgevormd kunnen worden van ‘IT-problemen’ naar ‘SOA-enablers’. Afhankelijk van het aantal en het type behoeften van een organisatie kan een gefundeerde keuze gemaakt worden voor een top-down of bottom-up approach of een specifieke ‘mix’ van de twee. Door het ‘mappen’ van de behoeften op de piramide komt een ‘heatmap’ tot stand die de specifieke situatie inzichtelijk maakt. De echte uitdaging hierbij zit uiteindelijk in het bepalen van de hoeveelheid ‘pijn’ en bijgevolg de hoeveelheid ‘motivatie tot verandering’. Daar waar de meeste IT-problemen (SOA-enablers!) en pijn (motivatie!) te vinden is (bij de top, bij de bottom of ergens daartussen) is het startpunt van de aanpak. Deze aanpak kan polariseren van het maken van een business case en het uitvoeren van SOA Awareness sessies (top-down, vanuit het beleid), tot 2 het ‘ad libitum’ verbeteren van gebruikersinterfaces, d.m.v. Mash-Up technologie of verrijking via publieke webservices (bottom-up, vanuit de applicaties).

2

Een mashup is een web 2.0 applicatie of website die gebruik maakt van content van een of meerdere bestaande applicaties of gegevensbronnen (SAP en non-SAP) om een nieuwe toepassing te maken.


CIO CFO

BPO COO

Top-Down

Bottom-UP

Operations Mgmt

Operational Community

3)

Sneller kunnen veranderen, lagere TCO en hogere ROI

Beter kunnen controleren van de procesketen, betere end2end meetbaarheid Executie van de bedrijfsprocessen moet gemakkelijker, sneller, betrouwbaarder en zonder redundantie 1 scherm, 1 login, 1 helpdesk, 1 portal, 1 rapport, 1 applicatie, 1x training, 1 consultant

SOA-BEHOEFTEN PIRAMIDE

STAPPENPLANNEN Indien er een keuze is gemaakt voor een bepaalde richting dan komt al snel de vraag hoe we dit traject aan moeten pakken. Een eerste fase daarin is het neerzetten van een concreet stappenplan waarmee we aan de slag kunnen. Voor de bottom-up aanpak kan het onderstaande stappenplan als voorbeeld dienen. Een bottom-up approach is gericht op directe procesverbetering:


Kies een concreet proces

Meet de verbetering en leg vast, stem af met stakeholders en vier de resultaten!

Maak mogelijke verbeteringen duidelijk

Bouw, test en zet in

4)

BOTTOM-UP APPROACH

De stappen bij een top-down aanpak vormen vaak een waterval en zijn ingericht op het realiseren van globale doelstellingen: Richting kiezen

Start •Maak de business case (ROI/TCO) en onderzoek de mogelijkheden

5)

•Kies een richting en leg bestemmingsplan nen vast (architectuur, richtlijnen, standaarden)

Acceptatie krijgen

Bouwen

•Zet een cyclus op •Bereid de 'waves' om adoptie van voor en begin de visie te met development realiseren (Inception, Discovery, Evaluation, Operations)

Live brengen •Breng wave per wave naar de business en refereer voor meting naar de orginele plannen

TOP-DOWN APPROACH

Bij de bottom-up aanpak ligt er een duidelijk accent op doen, uitzoeken en toepassen en dit op een iteratieve manier met veelvuldige terugkoppeling van (tussen-)resultaten met de stakeholders (dit vereist wel aandacht voor ontwikkelingsmethodiek en een passend framework). In dit geval bevinden de stakeholders met de ‘pijn’ zich vaak op het niveau van operations management of de operations community (zie de piramide) met als gevolg een duidelijke voorkeur voor operationele procesverbetering en directe sturing op korte termijn resultaten.


Het gevolg van een bottom-up is een snelle totstandkoming van een uitbreiding van de SOA-vlek: tenminste 1 concrete procesverbetering en een draagvlak dat begint te groeien op het gebruikersniveau. De vrees bij deze aanpak is een gebrek aan controle op dit creatieve proces, dat al snel een eigen leven schijnt te gaan leiden. Toch is dit creatieve proces te managen. Over naar een andere sector en een andere tijd.

SKUNK-WORKS Ter illustratie van de aparte vorm van management dat dit bottom-up proces nodig heeft om het tot een succes te maken, een ‘andersom’ aanpak met een sterk ‘out of the box’ aspect en misschien zelfs anarchistische insteek, is het de moeite waard om te kijken naar wat Kelly Johnson van Lockheed Martin realiseerde in de periode van 1943 tot 1975. Kelly Johnson, een ingenieur en hoofd Research & Development van Lockheed, vond dat het ontwikkelingsproces veel te beperkt werd door formele contract-, projecten goedkeuringsprocessen en ging zijn eigen gang. 3

Hij realiseerde met zijn ‘Skunk Works’ een R&D-team dat vele malen efficiënter werkte dan andere units en werkelijk innovatieve projecten realiseerde, volgens scope, op tijd en binnen het budget. Johnson draaide daartoe de bureaucratie binnen Lockheed de rug toe en maakt het R&D proces vrij van tijdrovende, anti-creatieve invloeden. Hij stelde na verloop van tijd, en vele successen, 14 basisregels op die ook voor ons interessant zijn en die toepasbaar zijn op de manier van management van onze bottom-up aanpak: 1.

2. 3.

4.

5. 6.

7. 8.

3

De projectmanager moet complete controle over het project worden toegekend. Hij of zij rapporteert aan een divisie president of hoger (en dus niet aan een programma-manager, maar zo hoog mogelijk in de boom). We werken in sterke, goed uitgeruste maar kleine kantoren (geen overhead, lean & mean). Het aantal mensen dat voor het project werkt moet rigoureus worden beperkt. Denk hierbij aan 10 tot maximaal 25% van de normale projectbemanning. Ze moeten wel de beste in hun vakgebied zijn (minder kwantiteit, meer kwaliteit). Er moeten een enorm simpel releasemanagement systeem beschikbaar zijn, met een enorme flexibiliteit voor het aanbrengen van wijzigingen (we worden niet bestuurd niet door systemen, maar de systemen worden door ons bestuurd, om ons te helpen in ons proces). We steken onze tijd zo min mogelijk in het maken van rapporten maar belangrijke projectaspecten leggen we altijd vast. Maandelijks rapporteren we de gemaakte en de nog te maken kosten voor de rest van het project. Geen latere of onverwachte facturen en geen ongenaam verraste stakeholders (geld en budgetteren is belangrijk). De aannemer van het project wordt extern gezocht en we willen de allerbeste prijs – kwaliteitverhouding . We vermijden dubbele inspectieactiviteiten. Ons kwaliteitssysteem is gecertificeerd en volstaat: vertrouw op het oordeel van subcontractors en leveranciers en laat hen de basisinspectie taken uitvoeren. Doe dat niet opnieuw (vertrouwen).

De afdeling lag onder de reuk van een stinkende plasticfabriek met deze naam.


9.

10.

11. 12.

13. 14.

De aannemende partij moet zijn deliverables testen vanaf de eerste stadia. De aannemer kan en moet testen tijdens de initiële fases. Indien hij dat niet doet, verliest hij zijn rechten voor de rest van het project (laten zien wat je doet en kennis is primair). De specificaties voor de hardware moeten ver van te voren worden afgestemd en overeengekomen. We leggen daarnaast van te voren vast aan welke specificaties we niet kunnen voldoen en de redenen waarom we dat niet kunnen (verwachtingen duidelijk maken). Funding van het programma moet 100% klaar zijn bij aanvang van het project (draagvlak). Er moet een basis van vertrouwen zijn tussen opdrachtgever en aannemer, op basis van een zeer nauwe samenwerking en dagelijks overleg. Dit om misverstanden en correspondentie tot een absoluut minimum te beperken (praten en niet mailen). Toegang tot het project door buitenstaanders wordt uitermate goed gecontroleerd (geen onnodige invloed). Omdat we slechts enkele professionals gebruiken in het project moeten we middelen voorzien die het individu belonen op basis van geleverde prestaties en niet op basis van het aantal personen die dit individu aanstuurt.

CONCLUSIE Een bottom-up aanpak van SOA-adoptie en implementatie kan voor sommige organisatie grote voordelen opleveren: dit zijn organisaties die nog weinig SOA-maturiteit hebben en veel ‘pijn’ ervaren op de gebruikersvloer. Andere organisaties hebben weer meer voordelen bij een top-down aanpak: dit zijn organisaties die al wat verder staan op SOA-gebied en andere behoeften hebben. Deze behoeften zijn uit te zetten in een ‘SOA-behoeften piramide’ waarmee de bottom-up of top-down gestalte krijgt. Een bottom-up aanpak is gefocust op directe procesverbetering en op stap voor stap met gebruikers aan de slag gaan om zo het nodige draagvlak en de argumentatie voor de ‘top’ van de piramide te realiseren: door te laten zien dat SOA werkt. De top-down aanpak, de methodiek die het meeste wordt gebruikt en gepredikt in de SAPwereld, vereist een draagvlak op C-level met een uitgewerkte business case en globale doelstellingen. Organisaties die kiezen voor deze aanpak lopen het risico dat procesverbetering eerder op het theoretische niveau blijft haperen en dat applicaties niet of nauwelijks voordelen voor gebruikers opleveren. Een bottom-up approach kan dan weer ‘chaos’ en ‘anarchie’ opleveren. Het managen van een bottom-up aanpak vereist een bijzondere managementstijl, veel creativiteit, zeer veel kennis (zowel conceptueel als handson) en de juiste randvoorwaarden.


SAP ENTERPRISE SOA: TOP-DOWN OF BOTTOM-UP PROCESSEN VERBETEREN

Recommend Documents