Pivotal is één van de bedrijven in de Dell Technologies familie die soms als een vreemde eend in de bijt wordt gezien, maar toch een sleutelrol vervult bij succesvolle digitale transformaties. In 1989 startte Rob Mee het software consultancy bedrijf Pivotal Labs. In een eerdere blog getiteld ‘zonder wrijving geen glans’ heb ik het ontstaan en de werkwijze van Pivotal beschreven.
Het was de beginperiode van de agile-filosofie voor het sneller ontwerpen van software. Ontwerpers en programmeurs die intensief samenwerken, snel nieuwe codes genereren en samen beslissen of iets inderdaad beter is of niet. Wat beter is, daar ga je mee verder, wat niet beter is, gooi je weg. In Rob’s visie was verandering de enige constante, dus moet je methodieken toepassen die die verandering realtime kunnen ondersteunen.
Digitale transformatie
Pivotal is, na de overname door EMC in 2012, begin dit jaar aan de beurs genoteerd en heeft een market cap van rond de 6 miljard dollar. Naast hoofdaandeelhouder Dell Technologies werden afgelopen jaren bedrijven als GE, Microsoft en Ford ook belangrijke aandeelhouders. Het bedrijf heeft typische Fortune 500 ondernemingen als klant zoals BMW, Mercedes-Benz, Lockheed Martin, NBC, Bloomberg, Orange, eBay, South West Airlines en Twitter. Ook Google was in de begindagen klant en Pivotal kan zelfs grote inlichtingenorganisaties tot haar klanten rekenen.
De digitale transformatie dwingt bedrijven anders over software te denken. In plaats van grote back-office applicaties nemen bedrijven steeds vaker standaard functionaliteiten af bij externe cloudproviders. Toch zijn nog veel eigen microservices nodig in zowel hun interne processen als hun producten. Deze specifieke services zijn lastig uit te besteden omdat ze diep vanuit het eigen proces of product moeten ontstaan. Als autofabrikant zal je microservices voor de interne systemen van de auto of voor de apps voor de klant moeten én kunnen ontwikkelen en – belangrijker – onderhouden. Dat is lastig uit te besteden.
Edge computing
Ook de opkomst van edge computing vraagt steeds meer lokale microservices die aan de randen van de infrastructuur intelligentie moeten brengen. De wereld van IoT maar ook OT bestaat grotendeels uit decentrale verzamelingen microservices die steeds vaker lokale cloud architecturen gebruiken, zie ook mijn vorige blog. Deze steeds meer op open source gebaseerde services worden weliswaar opgebouwd uit beschikbare standaardfuncties, maar voor het ontwerp, de samenbouw, het testen en het onderhouden zijn eigen kennis en vaardigheden noodzakelijk. Dit vraagt om deskundigheid in agile software ontwerpen en hier komt Pivotal in het vizier.
Er zijn intussen klanten die al meer dan 5000 apps hebben ontwikkeld en gemigreerd met gebruik van het Pivotal framework en platform. In de visie van Pivotal wordt ieder bedrijf uiteindelijk een software bedrijf. Om in een digitale wereld te kunnen functioneren, is immers een mix van standaardfuncties en bedrijfseigen functies nodig. En die bedrijfseigen functies zullen ze uiteindelijk zelf moeten (kunnen) ontwerpen en/of maken. Dus als elk bedrijf een software bedrijf wordt, moet elk bedrijf de methoden, technieken en basisvaardigheden hebben om die bedrijfsspecifieke services te kunnen ontwikkelen.
Aanpak
Om zelf microservices te ontwikkelen moeten niet alleen de agile ontwikkelprincipes bekend zijn, er moeten ook ingerichte werkplekken komen waar ontwerpers die services met open source gereedschappen kunnen ontwerpen. Verder moet er toegang zijn georganiseerd naar alle (big) data die nodig is of gebruikt moet worden om die diensten te faciliteren.
Cloud Foundry en EdgeX Foundry zijn wereldwijd geaccepteerde open source Platformen-as-a-Service (PaaS) met een grote keuze uit clouds, ontwikkel frameworks en applicatie services om in een continu proces cloud-native applicaties te bouwen. Moderne datalakes zijn de basis voor big data, analytics en Hadoop gebaseerde database omgevingen.
Team als uitgangspunt
Een belangrijk uitgangspunt om kwalitatief beter te ontwikkelen, is het zogenaamde ‘pair-programming’. Je kunt het vergelijken met het rijden in een auto: als je als bestuurder ook moet navigeren, is dat lastig. Maar als je naast een bestuurder een navigator hebt en die twee kunnen goed samenwerken, dan kan ieder zich op zijn eigen functie richten. Bij het ontwikkelen van software creëert de een de code en de ander zorgt voor de juiste navigatie en die rollen kunnen worden afgewisseld. Doel is dat een ontwikkelaar zich niet afzondert maar altijd als team functioneert.
Verder geldt de balanced team methodologie. Naast het ontwikkel duo zijn in het team meestal ook een product manager en een ontwerper aanwezig. Door agile en lean werkwijzen toe te passen, kunnen deze zelfstandige teams in korte tijd prima software ontwikkelen. Het voornaamste is dat samenwerking en succes van product en team voorop staan; niet het individuele succes. Dit vraagt om wederzijds vertrouwen. Dat vertrouwen opbouwen is één van de belangrijkste onderdelen van de agile werkwijze. Net als in sport gaat het om het succes van het team, niet van het individu.
Integraal Ontwerpen
Het succes van grote webwinkels is dat zij niet één grote applicatie hebben ontwikkeld maar dat hun proces bestaat uit duizenden, zo niet miljoenen kleine services die samen het businessproces vormen. En die miljoenen samenwerkende kleine services kunnen elk – bij wijze van spreken – tien keer per dag worden geüpdate zonder dat de klant of de eindgebruiker verstoringen ervaart. Elke service is op zich zó klein, dat de kans dat de gebruiker daar gedurende het korte update moment last van heeft, minimaal is.
Maar dat vraagt wel om een totaaloverzicht van het gehele proces. Al die kleine functionaliteiten zorgen immers voor het succes van het geheel. Bedrijven als Amazon en Netflix doen op de achtergrond duizenden updates per dag en kunnen op die manier hun hele proces actueel en gezond houden. Naast eigen software is er voor veel bedrijven ook nog de supplychain van ingekochte functionaliteit uit de alom aanwezige multicloud markt. Dit is het van oudsher bekende proces van make of buy: is het standaard genoeg om het te kopen of is het zo uniek of bijzonder dat ik het zelf moet of wil maken? Maar het eindproduct is en blijft uiteindelijk een samenstelling van die twee soorten services.
Net zoals fysieke fabrieken zullen informatiefabrieken processen moeten inregelen om integraal te kunnen ontwerpen. Vervolgens moeten ze een ‘make’ (eigen fabriek) of ‘buy’ (inkoop en toelevering) proces organiseren en tenslotte al die diensten in een eindproces of eindproduct samen laten komen. Proces-technisch is er niet zo veel verschil tussen het ontwerpen, maken en onderhouden van een fysiek product of een informatieproduct. In het laatste geval is alles alleen veel minder tastbaar en daardoor minder zichtbaar, dat maakt het zoveel complexer dan die oude vertrouwde fysieke fabriek. Maar we hebben in de wereld gelukkig goede voorbeelden waar bewezen is dat ook deze data- en informatiefabrieken net zo lean, geautomatiseerd, schaalbaar, flexibel en succesvol kunnen functioneren.