SOA bij Nuon een kwestie van faseren
De inzichten van destijds leverden niet bepaald de meest gestroomlijnde IT-systemen op. De energiebedrijven bleken regelmatig niet in staat de vele administratieve handelingen af te wikkelen die bij bijvoorbeeld de verhuizing van een klant kwamen kijken.
Het was duidelijk dat er iets moest gebeuren. Jeroen Scheer, sinds een jaar of drie verantwoordelijk voor de enterprise architectuur bij Nuon, viel destijds met zijn neus in de boter. In 2004 begon hij met zijn collega’s aan een SOA-strategie. Hij omschrijft dat vooral als een ‘way of living’, waarbij je voortdurend uitgaat van het modulair maken en houden van het IT-landschap. Het hart van een SOA-aanpak is voor Scheer de plek waar je de processen aanstuurt: business process management. “Een marketeer en een IT’er praten vaak langs elkaar heen. Maar als je een marketeer dwingt om te praten in termen van het proces dat hij nodig heeft om zijn product-marktcombinatie mogelijk te maken, moet hij gaan nadenken over welke informatie hij nodig heeft. En je laat de IT’er die geen moer weet van marketing samen met hem dat proces definiëren. En dan is het aan de IT’er om te zeggen ‘dan hebben we die en die services nodig en dat kost zoveel’.”
Die services zijn er niet zomaar. Met een referentie-architectuur als uitgangspunt begonnen Scheer c.s. voorzichtig met pilot-projecten. “We doen het heel gefaseerd. Je bouwt eerst een fundament. Van de flinke verzameling SOA-infrastructuursoftware die de gekozen leverancier BEA biedt, heeft Nuon tot dusver nog maar een stuk of vijf onderdelen in gebruik, waaronder de portal, de enterprise service bus en de service-orchestrator. “Je leert dan eerst hoe je een service maakt. Nu komt het moment dat we meer dan tien services hebben en dan wordt het wel handig om iets met een registry en een repository te doen.”
Scheer waarschuwt ervoor de enterprise service bus als hét fundament voor een SOA te zien. “In al die mooie plaatjes zie je altijd een horizontale laag met een enterprise service bus, maar die hoort helemaal niet thuis in logische referentiearchitectuur. SOA kun je ook met postduiven doen.”
Gaandeweg bleek het SOA-traject ook het inzicht op te leveren dat je ook te véél kunt automatiseren. SAP en Siebel werkten destijds niet ideaal samen, terwijl de nieuwe processen daar wel van uitgingen. “Daardoor kreeg je uitvalbakjes en die bleven liggen, met alle klantontevredenheid van dien. En vervolgens gingen we het uitvalbakje automatiseren.” In 2005 werd besloten de processen (zoals de afhandeling van een verhuizing) met tijdelijke krachten aan de praat te houden, terwijl ondertussen stap voor stap werd geanalyseerd waarom de berichten steeds uitvielen. “En bij de oplossing komt dan het SOA-principe kijken.”
Waar SOA duidelijk in de praktijk wordt gebracht is het call center. “Daar hebben we te maken met ten minste twee applicaties. De klantgegevens zitten in Siebel en de contractgegevens zitten in SAP. Daardoor moest soms wat er in Siebel was ingevoerd via ctrl-C en ctrl-V in SAP worden ingeplakt, met alle fouten van dien. Met het nieuwe portal heeft de call center agent voortaan het gevoel dat hij met één applicatie zit te werken en hij heeft geen idee uit welke applicatie die gegevens komen. In plaats van het te dupliceren halen we nu het SAP-gegeven op uit SAP.
Een ander voorbeeld is een product/prijsconfigurator (PPC), een service waarin alle mogelijke combinaties van producten en prijzen kunnen worden opgeslagen. De klant kan uit die combinaties zijn eigen maatwerk kiezen en de bijbehorende productcode wordt in SAP opgeslagen. “Zo hoef je SAP zelf niet te verbouwen.” Over hoe de bijbehorende proceslaag – gedefinieerd in Siebel en SAP – daarmee geïntegreerd moet worden, denkt Scheer nu na.