{Corporate Portfolio Management}

Ik heb een team samengesteld. In totaal zijn het 10 mensen, maar ze zitten niet voltijds in het team. Ik weet dat dit geen ideale situatie is, maar het is niet anders. Iedereen zat op andere projecten of deed activiteiten voor de lijn. Aangezien ik twee petten op had, namelijk ook de manager pet voor 8 van de 10 mensen, kon ik wel de prioriteiten bepalen voor het merendeel van het team.

Wat  een ander probleem vormde is het feit dat het team uit enorm verschillende functies en achtergronden komt. Namelijk zowel beheer, ontwikkeling en test, maar dus ook uit verschillende technologieën. Java, .Net en het financiële pakket. Dat betekent dat niet iedereen zomaar alles van elkaar over kan nemen. Sterker nog: het is een bak kikkers die alle kanten eruit springen als je niet uitkijkt.

Dan hebben we de start. We gaan gewoon beginnen!

Geen PID, Project Brief, geen governance die al dan niet bepaalt of we verder mogen. Allemaal weten we dat we in onze ontwikkelstraten veel beter, sneller en beheerster kunnen gaan bouwen. Maar dan moeten de straten wel beter opereren. We moeten alles wel veel beter beheersen dan we ooit gedaan hebben. Wat er fout is geweest?

Veel te veel handmatig; Aan de start van een nieuwe omgeving gaat alles nog wel redelijk synchroon over de verschillende omgevingen. Maar na een paar maanden zijn er (door omstandigheden zullen we maar zeggen) veel verschillen tussen bijvoorbeeld een T-omgeving en een A-omgeving. Wijzigingen die niet consequent doorgevoerd worden, configuraties die “even” aangepast worden omdat een test team even vast zit of teveel autorisaties voor teveel mensen. Letterlijk meegemaakt dat er een script geschreven werd om op een bepaalde omgeving het loglevel weer terug te zetten naar 1, aangezien er altijd wel iemand het loglevel op 5 zette.

Te foutgevoelig; Aan het einde van het programma, doorlooptijd van 2,5 jaar, hadden we het deployen van nieuwe versies over de OTAP-straat niet op orde. Bij de eerste tests bleken twee gebruikers verschillende tabbladen te zien toen ze hun testen startten op de acceptatie omgeving. Dat betekent dat je na 2,5 jaar nog steeds niet geleerd hebt van je werkzaamheden.

Te weinig een generieke aanpak; De technieken kunnen danig van elkaar verschillen. Een pakket is duidelijk iets anders dan zelfbouw. Maar ook de .Net en de Java straat waren danig verschillend. Niet alleen in tools, dat kan omdat een technologie nu eenmaal specifieks ondersteund wordt door een leverancier, maar ook in testsoorten of aanpak of methode. Dat is wel vreemd. Waarom gaat alles niet door dezelfde status kwaliteitscontrole? Waarin is Java daar anders dan .NET?

Gebrek aan metrics; In feite is dit geen ongewenste situatie. Een gebrek aan kennis is nooit een reden om te denken dat iets niet goed gaat. Ik weet zoveel dingen niet, maar dat is geen reden om me ongerust te maken. Echter in dit geval is er geen kennis van bijvoorbeeld de doorlooptijd van een change. Of het feit dat een change sneller opgepakt wordt met .Net dan met Java. Of hoeveel bevindingen er in een Systeem Test omgeving gevonden worden. Etc. Etc.

Het moest beter en het kan beter. Met dat gevoel creëer je een team. Alles wat we doen is een verbetering en is per definitie goed. Het schept een band.

Om door te dringen tot de kern van de activiteiten die rand voorwaardelijk zijn voor het uitvoeren van devops zijn een paar definities nodig. Daar ontkomen we niet aan. Dit is niet alleen nodig voor het vervolg van het verhaal, maar ook om de bizar grote versnippering van een gemiddelde IT afdeling te begrijpen en dus ook de uitdaging die daarbij komt kijken.

De definities die ik wil hanteren zijn te doorgronden door verschillende brillen of doorsnedes te hanteren. De eerste heeft te maken met de technologische stack en ziet er zo uit:

Een verticale doorsnede (stack) van de geleverde services geeft de diverse soorten functionaliteit weer die onderdeel zijn van een ontwikkelstraat. Van beneden naar boven betreft dit:

1. Hardware, Server OS (en DBMS); Dit betreft de fysieke servers en/of PC’s die direct aangestuurd worden door een Operating System. Bij mijn klant betreft dit Windows en Linux servers. Indien een database hierop geïnstalleerd is volgt er geen bovenliggende stack, maar betreft het een database server.
2. VM; dit betreft een virtuele instantie van een server. Het is mogelijk om een cluster aan virtuele servers te draaien op 1 fysieke server.
3. Server OS (en DBMS); Dit betreft het operating system bij de VM-instantie, al dan niet geïnstalleerd met een database.
4. Middleware; Dit betreft alle software die noodzakelijk is als tussenlaag tussen de applicatie en een database en/of Operating System. Voorbeelden zijn applicatie servers als Websphere, Weblogic of IIS, maar ook MQseries, een service bus of een webservice.
5. Software; In het geval van een pakket installatie is dit de standaard (plain vanilla) installatie van de desbetreffende applicatie. Het betreft ook de configuratie van dit pakket (en de latere beheer activiteiten als patching & upgrading van dit pakket).
6. Het maatwerk; de daadwerkelijk gebouwde toegevoegde functionaliteit (van een pakket). De reden waarom deze nog een gedeelte paars heeft komt omdat beheer verantwoordelijk is voor het plaatsen van deze functionaliteit. Ontwikkeling is uiteraard voor de bouw van deze fucntionaliteit.

 

En dan nu het simplificeren van de zaken: de eerste 5 zijn allemaal een onderdeel van provisioning en de laatste worden gezien als deployments. Hierbij is de laatste een verantwoordelijkheid van de desbetreffende ontwikkelteam. Dat kan een scrum team zijn, een change in een lijnteam of een waterval project. Hierbij assisteert beheer in het plaatsen van de software, het eventueel controleren van de software sources en het daadwerkelijk operationeel beheren van de software (bijvoorbeeld door het draaien van batches).

De eerste vijf zijn sinds kort de verantwoordelijkheid van mijn System Team.

De meeste grote organisaties hebben meer dan 1 ontwikkelstraat. Hoe dat komt verbaast me nog wel eens, maar het is nu eenmaal zo. Uiteraard kunnen we lang en breed praten over wat een ontwikkelstraat nu eigenlijk is, maar generiek gelden hiervoor de volgende regels:

1. Er wordt maatwerk gemaakt.
2. Er wordt gebruik gemaakt van een eigen ontwikkeltaal.
3. Er is een logistiek proces waarin nieuwe functionaliteiten gemaakt worden en uiteindelijk in gebruik genomen worden.

Vervolgens krijg je een veelvoud aan smaken, talen, processen, raamwerken en methodes. Bijvoorbeeld dat men gebruik maakt van verschillende versies in zo’n proces of dat er verschillende stadia zijn waarin de functionaliteit zich bevindt of dat er een veelvoud van platformen bestaan waarop mijn van deze functionaliteit gebruik maakt. Termen als ITIL, Prince2 of MSP zijn allemaal methodes (of best practices) die inspelen op zo goed en zo gecontroleerd mogelijk wijzigingen door te voeren in een productionele omgeving. Enfin: ontwikkelstraten.

Mijn klant heeft de beschikking tot meerdere van dit soort straten. Voornamelijk zijn dat .Net en Java. Deze zijn aangevuld met een BI ontwikkelstraat (voor de Management Informatie Systemen) en er is ook een financieel pakket. Deze laatste is ook een ontwikkelstraat, aangezien het standaard pakket niet toereikend is voor de functionaliteit die gewenst is.

Allemaal maken ze gebruik van een OTAP straat en allemaal hebben ze een aparte manier van werken. En dus hebben ze allemaal een eigen proces. Allemaal!

Ze maken gebruik van hun eigen tools, hebben hun eigen processen, hun eigen snelheid en ook de governance is anders. Pas als men richting productie gaat worden er generieke eisen gesteld, aangezien hier ITIL heerst. De ITIL ayatola’s eisen een change in het helpdesk pakket, anders gaat er niets in productie. Sterker nog: er is bepaald dat de A-omgeving ook onder beheer valt en dus moet men zelfs een change indienen om naar een acceptatie test omgeving te gaan.

Zie hier de grote clash vanuit Dev naar Ops: van flexibiliteit (lees: chaos) naar structuur (lees: starheid).

Mijn opdracht is hier een verbetering in aan te brengen onder het motto: wij willen naar DevOps migreren.

Ik zit midden in een project waarin onderzocht wordt hoe de ontwikkelstraat van een klant kan worden versneld. Dit is in principe een LEAN traject waarin gekeken wordt welke stappen in het proces versneld en/of verbeterd kunnen worden.

Gestart zonder PID geen architectuur en ook geen formele goedkeuring. Hoe dat komt zal ik melden in de volgende blog. Het bewijst wel dat alle voorgaande formele processen die ik beschrijf voor het portfolio management niet noodzakelijk de enige weg naar succes is.

Ik zal in de blog bij gaan houden wat onze vorderingen zijn.

Rationalisatie is een term die de ICT gebruikt om het landschap van applicaties of services te ontdoen van overbodige (voornamelijk dubbele) zaken. Google en de woordenboeken geven aan dat het een zo efficiënt mogelijke organisatie is van productie en distributie.

Vaak vertaalt dit zich naar: welke applicaties kan ik migreren tot één.

Vorige week met een partner een gesprek gehad over deze rationalisatie en portfolio management. Het probleem zat in het feit dat ondanks de duidelijk aantoonbare (financiële) voordelen van het migreren van applicaties, klanten dit toch vaak niet doen. Uiteindelijk lukte het hem niet om de klant te overtuigen van de noodzaak.

Waar ligt dat aan?

Volgens mij ligt dit aan de voorkant van het proces: het Strategische Portfolio.

Pas als je weet hoe een klant beslissingen maakt aan de voorkant welke ideeën en initiatieven uiteindelijk worden geautoriseerd, kun je daarin meepraten. Pas dan kun je rationalisatie als onderdeel opvoeren in de besluitvorming.

Dat betekent dus ook dat het geen ICT feestje moet zijn. De business moet daar een heilzaam traject in zien. Dus ICT: kom uit je schulp!