Ben Kuiken beschrijft in het boek De laatste manager de sterke hiërarchische organisatievorm als één van de symptomen van het feit dat 'organisatie zoals wij die kennen' hun langste tijd hebben gehad.

"Waarom slaagt het grootste geavanceerde leger ter wereld er maar niet in om een stel bandieten op te sporen en te elimineren? Een leger dat de beschikking heeft over de modernste spionageapparatuur en de krachtigste wapens." De kracht van losse, terroristische groeperingen is haar decentrale karakter. Als decentraal netwerk van losse terroristische cellen is vrijwel ongrijpbaar voor het sterk centraal en hiëarchisch georganiseerde Amerikaanse leger.

Kuiken refereert in dit verband aan Ori Brafman en Rod Beckstrom's metafoor van de spin en de zeester (beschreven in het boek The spider and the starfish): "In tegenstelling tot de meeste dieren heeft de zeester geen hoofd, geen centrum waar alle beslissingen worden genomen en van waaruit de poten worden aangestuurd. Sterker nog: hak een poot af en hij groeit gewoon weer aan. Hak vier poten af en ze groeien allemaal weer aan. Een decentrale organisatie is met andere woorden veel minder kwetsbaar dan een centrale, want daar hoef je slechts op zoek te gaan naar het hoofd en je kunt haar onschadelijk maken."

Kuiken citeert Sergio Marchionne (Fiat) die stelt dat 'Een sterke gezagstructuur is voor een bedrijf is als cholesterol in de aderen'. Een belangrijk nadeel van een centraal aangestuurde organisatie ten opzichte van een decentraal netwerk is: de trage besluitvorming. "Elke vraag van de medewerker op de werkvloer moet langs de geëigende kanalen en door de verschillende lagen van managers naar de top, waarna de beslissing in omgekeerde richting langs dezelfde weg terug moet naar de werkvloer, zodat de medewerker weet wat hij moet doen. Omdat iedere middenmanager zijn positie waar zal willen maken, zal hij het niet kunnen laten om zijn 'plasje' te doen na een vraag en duidelijk maken wat hij ervan vindt. Zo slibben de aderen van de organisatie langzaam dicht."

Bron: De laatste manager, Ben Kuiken

To select well among old things, is almost equal to inventing new ones.

Nicholas Charles Trublet

Arjan Juurlink beschrijft in zijn boek Applicatieportfoliomanagement voor IT-complexiteitsreductie het belang van hebben van een helder inzicht in het applicatielandschap en het vastleggen van de relevante gegevens in een zgn. Applicatie Inventory. In het onderstaande wordt aangegeven wat volgens Juurlink de belangrijke aspecten zijn van het applicatie en geeft inzicht in de de belangrijkste begrippen en processen die een rol spelen bij het reduceren van complexiteit in het applicatie- en infrastructuurlandschap.

IT (Service)-portfoliomanagement: paraplubegrip voor alle activiteiten die zich bezighouden met het in lijn brengen van de IT-voorzieningen en de strategische doelstellingen van de organisatie. Het gaat om het besturen van de samenhang van de portfolio van IT-diensten met de strategie van de organisatie. Doel is door te sturen op samenhang in de portefeuille van IT-services de effectiviteit van de inzet van IT toe te laten nemen.

In het ideale geval is een organisatie in staat om naar IT-voorzieningen te kijken als onderdeel van business-services. Applicaties zijn het meest zichtbare deel van een business-service en worden door de gebruiker vaak als een geheel gezien met gegevens en infrastructuur. Omdat een SLA de dienstverlening vaak beschrijft in relatie tot het (complexe) applicatielandschap, gebruikt Arjan Juurlink het begrip applicatieportfoliomanagement als hulpmiddel voor het reduceren van complexiteit in het applicatie- en infrastructuurlandschap.

Voor het kunnen reduceren van de complexiteit in het applicatie- en infrastructuurlandschap is het volgens Juurlink noodzakelijk een Applicatie Inventory ('single-source-of-truth') aan te leggen, waarin minimaal voor elke applicatie de kosten, het belang en het risico (incl. de verwachte ontwikkeling van alledrie de aspecten tot het eind van de levenscyclus). Juurlink waarschuwt voor het gevaar om té veel zaken vast te leggen en pleit voor het vastleggen van een beperkt aantal gegevens voor het gehele landschap. Op basis van need-to-know is het mogelijk later alsnog meer informatie te inventariseren. Hij onderscheidt drie categorieën informatie:

1. Analysegegevens: gegevens die nodig zijn om het applicatielandschap in te delen in categorieëen. Het is van belang deze groep gegevens zo beperkt mogelijk te houden, omdat deze informatie voor het gehele landschap moet worden vastgesteld.

2. Rapportagegegevens: wanneer de eigenaar van een groep applicaties wil kunnen sturen op de afhankelijkheden en op de voortgang van de migratie naar de doelarchitectuur, zijn overzichten nodig op basis van doorsneden en invalshoeken (zoals proces, informatie- of productdomein, ontwikkelomgeving en soort technologie), om de voortgang (in 'standgegevens') te kunnen volgen.

3. Executiegegevens: (tijdelijke) gegevens die nodig zijn om te weten wanneer een applicatie daadwerkelijk wordt gemigreerd, zoals bijvoorbeeld aantallen logische of fysieke database-instanties. Het verzamelen van deze gegevens vindt plaats op basis van need-to-know en alleen voor applicaties die deel uitmaken van een migratie.

Juurlink clustert de eigenschappen van een applicatie in zeven categorieën:

1. Applicatiegegevens: [ identificatie, naam, versie | service level | status | maatwerk/standaard | fase levenscyclus | client/server/beide | jaar in productie | datum laatste release | jaar end-of-life ]

2. Functionele gegevens: [ relatie procesketen | relatie bedrijfsproces | belang voor bedrijfsproces | mate waarin proces wordt ondersteund | mate van gebruik (business events) | doelomgeving ja/nee | functionele kwaliteit ]

3. Gebruiksgegevens: [ aantal gebruikers | gem. frequentie van gebruik | aantal installaties | aantal incidenten | performance | gebruikerstevredenheid | datakwaliteit | inleertijd ]

4. Organisatiegegevens: [ businesseigenaar (eigenaar functionaliteit) | eigenaar applicatie | functioneel beheerteam | applicatiebeheerteam | aantal beheerders in organisatie | aantal beheerders buiten de organisatie ]

5. Leveranciersgegevens: [ leveranciersnaam | productnaam | productversie | omvang leverancier | binnen/buitenlands ]

6. Technische gegevens: [ hardwareplatform | operatingsystem | DBMS | aantal interfaces intern/extern | ontwikkelplatform | aantal regels code | middleware | doelomgeving ja/nee | technische kwaliteit ]

7. Business-strategie: op welke wijze draagt applicatie bij aan de strategie?

Arjan Juurlink hanteert de volgende definities:

1. Applicatie: eenheid van functionaliteit die van buitenaf autoriseerbaar is ten behoeve van een eindgebruiker. Een applicatie ondersteunt één of meer stappen uit een bedrijfsproces. Alles wat verdwijnt op het moment dat een applicatie wordt uitgezet, behoort tot deze applicatie.

2. Component: een applicatie bestaat uit componenten, een component is ondeelbaar en draait op dezelfde technische stack (optelsom van functionaliteit, ontwikkelplatform, databaseplatform, middleware, operating system en hardware).

3. Informatiesysteem: aantal applicaties die een bepaalde samenhang hebben (in termen van onderlinge verbindingen tussen applicaties, componenten en/of eindgebruikers).

Volgens Arjan Juurlink kunnen vijf soorten applicaties worden onderscheiden:

1. End User-applicatie: applicaties die door eindgebruikers zélf zijn ontwikkeld (vaak op eigen werkplek, denk aan allerlei Excel-trucendozen)

2. Image-applicaties: in verre mate gestandaardiseerde besturingssoftware en/of gebruikerssoftware (MS Office, internetbrowsers).

3. Standaardkantoorapplicaties: standaarddiensten (meestal standaardpakketten) die een gebruiker kan bestellen via de IT-catalogus.

4. SLA-applicaties: applicaties die niet standaard in de bestelcatalogus voorkomen, en meestal worden gebruikt ter ondersteuning van de (primaire) bedrijfsprocessen. Voor deze applicaties worden Service Level Agreements (SLA's) afgesloten met de (interne) leverancier, bijv. ten aanzien van beschikbaarheid, maximale tijd voor afhandeling van storingen. Het gaat meestal om uitgebreidere standaardpakketten, ERP-pakketten en specifieke maatwerkontwikkelingen.

5. IT-for-IT applicaties: ontwikkel- en beheertools, 'tooling' om IT-diensten te maken en/of beheren.

Nadat de basisgegevens van het applicatielandschap zijn geïnventariseerd en geregistreerd, is het mogelijk applicaties te classificeren. Classificatie helpt bij het bepalen van migratiescenario's naar de doelarchitectuur of uitfasering. Arjan Juurlink noemt de volgende veelvoorkomende scenario's:

• Behouden
• Uitbouwen
• Opschonen
• Herplatformen
• Migreren
• Consolideren
• Vervangen
• Uitzetten

Arjan Juurlink beschrijft zijn boek beknopt ASL en BiSL, maar in relatie tot complexiteitreductie zijn vooral drie processen van belang:

1. Applicatielifecyclemanagement : ASL-proces dat beslissingen faciliteert over investeringen in vernieuwing en onderhoud van een applicatie (gebaseerd op de levenscyclus van de applicatie).

2. Applicatieportfoliomanagement: ASL-proces dat het applicatie- en infrastructuurlandschap optimaliseert voor de bedrijfsdoelstellingen.

3. Planning en control: BiSL-proces wordt door Juurlink vertaalt naar projectportfoliomanagement dat zich bezig houdt met de coördinatie van projecten en programma's van een organisatie om de realisatie te optimaliseren, het risicoprofiel van de portfolio evenwichtig te houden en ervoor te zorgen dat projecten in lijn zijn met de strategie van de organisatie en binnen budgettaire grenzen wordt opgeleverd.

Volgens Juurlink bij het nemen van 'portfoliobeslissingen' gekeken worden naar de verdere - liefst gehele - levensduur van applicaties en de onderliggende infrastructuur. De lifecycle van functionaliteit wordt opgedeeld in drie categorieën:

1. Doelapplicaties: applicaties die (al) deel uitmaken van de doelomgeving.

2. Te migreren kernapplicaties: applicaties waarvan de functionaliteit nog niet in de doelomgeving is gemigreerd (maar dit moet nog wel gebeuren omdat deze applicaties nog zeker zo'n drie tot vijf jaar gebruikt moeten worden).

3. Legacy applicaties: applicaties die nog binnen de planperiode (meestal 1 tot 3 jaar) gesaneerd zullen worden.

Zie ook:

• Applicatieportfoliomanagement
• Business case voor IT-complexiteitsreductie

Bron: Applicatieportfoliomanagement voor IT-complexiteitsreductie, Arjan Juurlink

The time is always right to do what is right.

Martin Luther King

Little by little, one travels far.

J. R. R. Tolkien

However long the night, the dawn will break.

African Proverb

The world hates change, yet it is the only thing that has brought progress.

Charles F. Kettering

What, sir, would the people of the earth be without woman?
They would be scarce, sir, almighty scarce.

Mark Twain

Failures are fingers posts on the road to achievement.

C.S. Lewis

Quint Wellington Redwood ontwikkelde het Demand Supply Governance Framework (DSGF) om organisaties te helpen grip te krijgen op de besturing van IT. De achtergrond van het DSGF is dat Quint in samenwerking met het ministerie van Defensie in 2002 een model ontwikkelde voor de het outsourcen van IT (Smart Buyer Function, SBF) en aansturen van externe IT-leveranciers. Dit model evalueerde tot een framework gericht op de aansturing van IT-diensten van zowel externe als interne IT-organisaties (Sourcing Governance Framework, SGF). Door meer nadruk te leggen op regie (aansturen van de vraag naar IT-diensten, bereiken van het juiste evenwicht tussen vraag en aanbod), verbrede het framework zich tot een Demand Supply Governance Framework voor regie.

Het DSGF is een hulpmiddel voor het snel en doelmatig inrichten van de regiefunctie. Centraal binnen het DSGF staat het managen van de vraag naar IT-diensten en het aanbod door zowel externe als interne leveranciers van IT-diensten. De term 'demand supply governance' slaat op het op elkaar afstemmen van vraag en aanbod ('regie'). Het DSFG brengt de aandachtsgebieden in kaart die goed gemanaged moeten worden om - in de woorden van Quint - 'de overeengekomen IT-diensten te kunnen leveren en de toegevoegde waarde van IT voor de klant te verhogen'.

De doelstellingen van demand supply governance (regie) zijn tweeledig:

1. Borgen dat interne en externe leveranciers daadwerkelijk de IT-diensten leveren, conform de afspraken die daarover met de klant zijn gemaakt.

2. Het aantoonbaar verhogen van de toegevoegde waarde van IT, door een focus op diensten en projecten die de business een duurzaam concurrentievoordeel opleveren.

Binnen het DSGF worden drie domeinen onderkend: 'Business', 'IT' en 'Alignment' (het ‘regiedomein’) met elk drie niveaus: strategisch, tactisch en operationeel. Quint addresseert 29 aandachtsgebieden door deze te plotten op de negenvlaksmatrix. Verder worden ook drie werkstromen* (delivery flows) onderkend die staan voor de 'objecten' van (be)sturing.

1. De correcte levering van gecontracteerde standaarddiensten en aanvragen aan de gebruiker, conform de producten- en dienstencatalogus en SLA’s.

2. De tijdige en correcte levering van changes (speciale orders).

3. De tijdige en correcte levering van projectresultaten en de controle over het projectportfolio.

Alledrie de domeinen zijn betrokken bij elk van de leveringsstromen. De regieorganisatie richt zich binnen de drie stromen voornamelijk op de koppelvlakken die essentieel zijn voor een goede levering van IT-diensten en -projecten. Aan de hand van de aandachtsgebieden en de sturing van de werkstromen biedt het DSGF inzicht in de rollen die in de verschillende domeinen te vervullen zijn en welke competenties hiervoor nodig zijn.

*Ik woonde recentelijk een (interne) presentatie van Quint Wellington Redwood bij waarin vier ipv drie werkstromen werden onderkend:

1. Projecten

2. Specials (toekomstige PDC items)

3. Standaard verzoeken (PDC)

4. Operationele dienstverlening (SLA)

Bron: Whitepapper Regie van IT – diensten en projecten Verbinden van vraag en aanbod (Quint Wellington Redwood)