ABN AMRO · Service Administratie

In 2003 implementeerden we bij ABN AMRO de Service Administratie: het servicegerichte informatiemodel dat ik ook beschrijf in mijn boek Service Administratie – De praktijk van ICT ketenmanagement.

Toen ABN AMRO enkele jaren later een belangrijk deel van haar IT ging outsourcen, werd dezelfde serviceterminologie gebruikt in de RFP. IBM won de aanbesteding en ook in het contract werd deze structuur gebruikt.

Daarmee ontstond een gemeenschappelijke taal tussen de Service Managers van ABN AMRO en IBM. Services, SLA's, businesswaarde en verantwoordelijkheden waren aan elkaar gekoppeld. Ook diensten van andere externe leveranciers werden in dezelfde administratie opgenomen.

Deze structuur is bijna 15 jaar de basis geweest voor de afspraken en samenwerking tussen ABN AMRO en IBM.

ABN AMRO & IBM · CMDB-based billing

Een CMDB gebruiken voor impactanalyse is één ding. De informatie gebruiken om te bepalen wat je een leverancier betaalt, gaat een flinke stap verder.

Voor tienduizenden end-user devices werd de CMDB onderdeel van de financiële afrekening tussen IBM en ABN AMRO.

Daarbij gold een eenvoudig uitgangspunt: een wijziging in de CMDB moest te herleiden zijn naar een geautoriseerde Service Request. Kon dat niet worden aangetoond, dan was er ook geen onderbouwing voor de rekening.

De kwaliteit en beheersing van de CMDB waren daarmee goed genoeg om er financiële afspraken op te baseren.

Een VM kon in allerlei varianten worden geleverd: on-premises of vanuit de private cloud, bronze, silver of gold, managed of self-managed. Voor al die varianten aparte catalog items en workflows bouwen wilden we juist niet.

In de Service Catalog vroeg een gebruiker daarom gewoon een VM aan. De gekozen kenmerken bepaalden vervolgens welke Product Service nodig was.

Aan zo'n Product Service was een Service Category gekoppeld. Daarin lag vast in welke CMDB-class het CI thuishoorde, welke attributen relevant waren en waar die informatie in de CMDB moest worden opgeslagen.

Die definities werden bij het opbouwen van het catalog item automatisch gebruikt. Standaard taakplannen bepaalden welke werkzaamheden nodig waren en via rollen kwamen de taken bij de juiste teams terecht.

Zo konden we met één generiek aanvraagproces tientallen technische varianten ondersteunen, zonder voor iedere variant aparte workflowlogica te bouwen.

IBM Private Cloud · Automation

Met de introductie van de IBM Private Cloud trokken we dat principe verder door. Een Service Manager moest niet allerlei losse componenten bestellen, maar in één keer de infrastructuur kunnen aanvragen die nodig was.

We definieerden ongeveer 12 standaardtopologieën, van een enkel CI tot omgevingen van ongeveer twintig onderling gerelateerde CI's.

Per topologie lag vast welke Service Categories nodig waren en met Relationship Templates legden we vast hoe de componenten met elkaar verbonden moesten worden. Bij een aanvraag werden die definities samengevoegd.

De technische bouwtaken produceerden vervolgens een gestandaardiseerd XML-bericht voor de externe automation tooling. Zo konden de infrastructuur én de bijbehorende CMDB-registratie vanuit dezelfde aanvraag worden opgebouwd.

We gingen daarbij nog een stap verder en legden ook architectuurregels vast. Als bijvoorbeeld één VM in een stack extra CPU kreeg, kon dat betekenen dat de andere VM's in dezelfde stack automatisch mee moesten veranderen om de architectuur in balans te houden.

Service Catalog, CMDB, architectuur en technische automation waren daarmee geen losse onderdelen meer, maar werkten vanuit dezelfde service-informatie.