woensdag 9 november 2016

StartupInc, De Innovatie expert: Door slim aan architectuur te werken, kunnen innov...

StartupInc, De Innovatie expert: Door slim aan architectuur te werken, kunnen innov...: Grotere organisaties die willen innoveren hebben natuurlijk vaak al IT systemen . Het komt vaak voor dat het implementeren van innovatie...

Door slim aan architectuur te werken, kunnen innovaties snel gerealiseerd worden!




Grotere organisaties die willen innoveren hebben natuurlijk vaak al IT systemen . Het komt vaak voor dat het implementeren van innovaties in bestaande omgeving te lang duurt en te veel kost. Workarounds oa door inzet van nieuwe systemen en / of oplossing (oa Cloud) versnellen de innovaties en maar vergroten ook de druk op beheer. Door de ideeën uit de ideation fase als basis te gebruiken voor een beknopte architectuur studie, kunnen ontwikkel trajecten vroegtijdig bijgestuurd worden om op tijd klaar te zijn voor innovatie.

Beginpunt

Innovatie binnen bedrijven die al producten hebben is eigenlijk altijd lastig. Dat komt eigenlijk altijd omdat de (IT) architectuur gericht is het optimaal bedienen van de huidige diensten, terwijl de innovaties vaak iets anders van de IT vragen. Het is mogelijk om te anticiperen op de innovaties. Het beste start moment hiervoor is het moment als er een overzicht ontstaat van allerlei mogelijke innovaties. Dit is typisch in de zogenaamde ideation fase. Afhankelijk van het bedrijf kan die een incidentele of jaarlijkse exercitie zijn, maar het kan ook een continue proces zijn, waarbij er altijd een overzicht is van mogelijke innovaties. Ergens in deze fase ontstaat er een geprioriteerd overzicht van mogelijke innovaties. Met de top 5 gaan de innovatie managers natuurlijk aan de slag om deze met de Eenvoudig Innoveren aanpak iteratief verder te valideren. De architecten kunnen deze top 5 als de wensenlijst voor architectuur ontwikkeling beschouwen.

Architectuur ontwikkeling






Omdat de architectuur ontwikkeling in deze fase vooral onderzoekend is, zullen de producten beperkt zijn. Binnen de industrie standaard voor architectuur TOGAF worden dit artefacts genoemd. De artefacts zullen voor deze architectuur ontwikkeling bestaan uit een overzicht (meestal een matrix) en de vastlegging van de requirements. Ik kies er voor om een iets andere benaming voor de artefacts te kiezen als in TOGAF staat. Overigens is de keuze van de artefacts per bedrijf verschillend.

Stappen in de innovatie architectuur ontwikkeling:


  1. Vertalen innovaties in Business Services, met de eerste gedachten van de requirements. Vaak zullen de innovaties direct één business service zijn, maar het kan ook zijn dat een innovatie meerdere Business Services omvat. Het komt ook voor dat op innovatie lijstjes een idee staat waarbij geen logische Business Service past. bv als het om een technisch idee gaat. Dan is er de keus om dit idee op te werken tot een business service (wat eigenlijk meer bij de innovatie manager hoort) of om het idee (als idee) door het architectuur proces te halen totdat er een stap is waar deze wel verder geanalyseerd kan worden.
  2. Analyseren Business Services en benoemen Information Services en de relatie vastleggen in de BS - IS matrix, met het documenteren van de verwachte requirements.
  3. De Information Services worden geanalyseerd en een lijst met IT componenten wordt benoemd. Soms zijn de IS hetzelfde als de IT Componenten, maar soms ook niet. Nadat de IS IT martix gemaakt is, worden weer de aangenomen requirements vast gelegd.
  4. Nu kunnen de relaties tussen de IT componenten opgetekend worden. Zelf vind ik dat er zeer veel aandacht besteed moet worden aan de focus op ontkoppel punten en API's om de flexibiliteit zeker te stellen.
  5. Mapping van de nieuw bedachte IT componenten op de bestaande architectuur. Naast de nieuwe componenten, zullen een aantal erg lijken op bestaande componenten. Als de requirement van beide niet al te veel verschillen, dan is het component herbruikbaar. Het is ook mogelijk om naast de bestaande oplossingen nieuwe te realiseren; dit verhoogt vaak de snelheid. Voorwaarde is wel dat de koppelpunten (die er meestal toch moeten zijn) voldoende stabiel zijn. Op deze manier kan de impact van de mogelijke nieuwe diensten ingeschat worden.


Deze exercitie lijkt wellicht wat omslachtig maar is is uiteindelijk essentieel in het ideation proces omdat de IT impact een van de mogelijke overwegingen kan zijn bij het kiezen aan welke innovatie te gaan werken.

Als er sprake is van technology push of als technologie een zeer belangrijk onderdeel is van de innovatie moeten de innovatie architectuur stappen vooraf gegaan worden door een stap die recht doet aan het belang van de technologieën en de mogelijke business services die daar uit kunnen komen. Dit is eigenlijk het creatiefste gedeelte van het architectuur proces. Een goede aanpak hiervoor is om eerst de mogelijke technologieën te benoemen en daarna te brainstormen over de mogelijke producten / diensten (Business Services) die hiermee te maken zijn. Hierbij hoeft geen rekening gehouden te worden met consequenties en impact, want die worden vanzelf duidelijk in de innovatie architectuur stappen.

Uit de bovenstaande exercitie zal blijken welke IT componenten cruciaal zijn voor innovaties en dus als eerste aangepast moeten worden (o.b.v. de verzamelde requirements) om innovaties snel mogelijk te maken. Als op voorhand duidelijk is dat ingrijpen hierop niet mogelijk is (bv i.v.m. lopende ontwikkelingen), dan kunnen de interfaces is duidelijk welke interfaces van de aanpalende componenten aangepast moeten worden om alternatieve invullingen mogelijk te maken. Als er nieuwe componenten naar voren gekomen zijn, dan kan de technology / product scan hierop plaats vinden om de innovatie te ondersteunen. Aangezien het om innovaties gaat is het dan mogelijk om hier tijdelijke cloud diensten voor te gebruiken. Ook is helder welke interfaces aangepast moeten worden om deze componenten in de toekomst aan te sluiten.

Aanpak



Omdat de snelheid van architectuur ontwikkeling vaak een orde van grote lager ligt dan die van innovatie, zal er een project aanpak gekozen moeten worden die op korte termijn de eerste globale resultaten oplevert. Scrum ligt dan het meeste voor de hand. In sprints kunnen dan door door de architecten in het development team stukken van de oplossing voorbereid worden voor het uiteindelijke product. Tijdens de Sprint Reviews worden de resultaten met het innovatie team gedeeld. Deze resultaten in combinatie met de resultaten uit het Business Innovation proces, geven weer richting aan de volgende sprints en innovatie. Zo wordt op een robuuste manier zeker gesteld dat de IT geschikt gemaakt wordt voor de innovatie.

Over Ad Bresser


Innovatie adviseur, -mentor en -manager.
Voegt als waarde aan de maatschappij toe: “Innovaties sneller en efficiënter laten verlopen”
Geeft workshop: Van concept naar business
www.StartupInc.nl