De manier waarop zakelijke gebruikers omgaan met softwareapplicaties is afhankelijk van de functie waarin ze werkzaam zijn. Toch werd in het verleden vooral gekeken naar de technische uitvoerbaarheid of de kosten bij aanschaf en beheer van applicaties. Daardoor werd vaak gekozen voor één of twee grote applicatiesuites waarin alle gebruikte functies waren ondergebracht. De opkomst van internet en smartphones heeft dit echter voorgoed veranderd.
Gebruikers zijn gewend geraakt aan (consumenten)apps waarmee ze snel hun noodzakelijkheden kunnen regelen en data kunnen updaten. De beperkte applicatiesuites die ze op hun werk moeten gebruiken, worden ervaren als frustrerend, ingewikkeld, traag of onpraktisch. Hoewel zij zich bewust zijn van de complexiteit van de digitale wereld, snappen zakelijke gebruikers niet waarom hun bedrijfsapplicaties niet op dezelfde manier kunnen werken als de apps op hun privé-smartphone. De it-branche heeft geen tijd meer te verliezen. Met de Pace-Layered Application Strategy kan de kloof tussen softwareontwikkelaar en gebruiker worden gedicht.
Applicaties ingedeeld in lagen
Bij de Pace-layered Application Strategy van Gartner worden applicaties ingedeeld in lagen op basis van de gebruikswijze en de snelheid waarmee ze veranderen/updates behoeven. Op basis van deze indeling kan een strategie worden bepaald waarmee sneller kan worden gereageerd en een betere return on investment (roi) kan worden gerealiseerd, zonder de integriteit, integratie en besturing uit het oog te verliezen. De drie lagen zoals gedefinieerd door Gartner zijn:
- Systems of Record (de commodity-laag): Standaard softwarepakketten of eigen legacy-applicaties die de organisatie draaiende houden en waarin bedrijfskritische data worden beheerd.
- Systems of Differentiation (de differentiatielaag): Branche- of bedrijfsspecifieke applicaties die unieke capaciteiten van de organisatie mogelijk maken.
- Systems of Innovation (de innovatielaag): Ad-hoc applicaties die zijn gebouwd om snel te reageren op nieuwe behoeften of kansen.
Eerst moeten de bestaande applicaties worden ingedeeld in drie lagen. Hierbij moet uitsluitend worden gekeken naar de behoeften vanuit het bedrijf en moet buiten beschouwing worden gelaten voor welk gebruik de leverancier de applicatie heeft ontwikkeld. Om dit proces te vereenvoudigen, kan het nuttig zijn om de bedrijfsbehoeften in te delen in lagen aan de hand van de volgende stellingen:
- Commodity-laag: Ik weet wat ik wil en de applicatie hoeft niet uniek te zijn.
- Differentiatielaag: Ik weet wat ik wil en ik moet me met deze applicatie kunnen onderscheiden van de concurrentie.
- Innovatielaag: Ik weet niet precies wat ik wil dus ik moet kunnen experimenteren.
Eigen kenmerken
Elke architectuurlaag heeft zijn eigen kenmerken. De applicaties in de commodity-laag moeten zo efficiënt mogelijk zijn en moeten aan allerlei regels voldoen. Vaak gaat het om traditionele bedrijfsprocessen en transactionele activiteiten. Voor deze applicaties is vooral belangrijk dat ze stabiel zijn. Vaak heeft slechts een deel van de medewerkers toegang tot deze applicaties.
De applicaties in de differentiatielaag moeten echter snel kunnen worden aangepast aan veranderingen in de markt en tegelijkertijd blijven voldoen aan de regels en het beleid van het bedrijf. Deze applicaties worden meestal geïsoleerd, omdat de processen die ze ondersteunen volledig losstaan van andere bedrijfsfuncties. De applicaties in de innovatielaag, tot slot, zijn volledig gericht op flexibiliteit en snelheid. Deze applicaties staan vaak aan de bron van essentiële bedrijfsinnovaties en moeten dus reactiever zijn dan de standaard it-applicaties. Het is belangrijk dat zakelijke gebruikers deze applicaties kunnen gebruiken om snel oplossingen te ontwikkelen voor unieke bedrijfsproblemen, ook al zijn de applicaties zelf nooit volledig ontwikkeld.
Als de applicaties in lagen zijn ingedeeld, blijkt meestal dat alle specifiek voor het bedrijf ontwikkelde applicaties in de differentiatie- of innovatielaag horen. Standaard applicatiesuites zijn primair ontwikkeld om met minimale input maximale productiviteit te realiseren, bevatten SQL-, NoSQL- of big data-databases die zijn gebaseerd op standaarden, kunnen nauw geïntegreerd worden en zijn het meest geschikt voor stabiele bedrijfsprocessen. Dergelijke applicaties zijn bedrijfskritisch, maar brengen ook hoge kosten met zich mee.
Om bedrijven in staat te stellen zich echt te onderscheiden en te innoveren, moeten ontwikkelaars de beschikking hebben over technologie en tools die ze helpt om echt richting te geven aan hun activiteiten. It heeft behoefte aan agility en met de Pace-Layered Application Strategy kunnen zij dit realiseren.
Het is natuurlijk maar een semantische discussie maar naar mijn opinie staat Systems of Record (SoR) veelal voor databases, de gestructureerde dataopslag die nodig is voor de governance. Dat hierin de Systems of Engagement (SoE) nu steeds vaker voor problemen zorgen met de Chain of Custody (CoC) door alle experimenten in het digitaliseren van de papierstroom waardoor dus de bonnetjes SoEk raken komt doordat Gartner telkens naast de pot poept en vervolgens die hoop stront definieert als het nieuwe werken. De Babylonische spraakverwarring die vervanging verwart met vernieuwing zorgt namelijk voor de Bipolaire IT.
Voorbeeld hiervan vinden we in de krant, de digitale façade van de overheid blijkt op drijfzand te zijn gebouwd waardoor – zie rapport WRR – er een semantische waarheid is ontstaan die veelal niet blijkt te kloppen met de realiteit. Elke Enterprise Architect (EA) weet dat Agile kleuters in de Sandbox nog wat moeite hebben met governance, de meeste applicatie suites kennen hierdoor het nodige maatwerk om ze geschikt te maken voor lokaal gebruik zoals dure ERP implementaties of je moet de organisatie ombuigen naar de mogelijkheden van het pakket wat veelal dus weer tot non-compliance leidt.
Ondanks bovenstaande ben ik het echter wel met de auteur eens dat een bedrijf de innovatie zelf in de hand moet houden. Hierbij dient eerst en vooral gebroken te worden met de hiërarchische lagen, identificeer je value chains op basis van de Theory of Constraints (ToC) voordat je weer de ‘innovatie’ van gisteren koopt. Zeker verlaagd commodity je CapEx maar als je hiermee de OpEx verdubbeld omdat je achteruit automatiseert dan wordt je operationele performance bepaald door de kosten van arbeid.
Wat Gartner even vergeet te vertellen is dat een architectuur welke veel op verschillende snelheid draaiende schijven heeft een vorm van Chinees variété is. Je weet wel, die act waarin iemand het hele servies draaiend probeert te houden op stokjes.
Martin Healey met pensioen.
Ga jij het overnemen Ewout ?
Briljante reactie met lekker veel vaktermen die ik 3 maal moest lezen om te begrijpen dat het nog waar is ook.