Met de zomervakantie in volle gang zullen er heel wat kiekjes worden gemaakt. Pa voor de barbeque, zoontje in het zwembadje, dochtertje met een ijsje, ma in een strandstoel, en nog veel meer. De fysieke en financiële beperkingen van een fotorolletje gelden niet meer, dus het schieten van plaatjes is onbeperkt. Maar dit terzijde. Mijn advies: maak eens een landschapsfoto. Een foto van uw applicatielandschap, wel te verstaan.
Onze applicatielandschappen zijn omvangrijk, complex en soms ondoorgrondelijk. Een cio, net begonnen aan zijn nieuwe functie, vertelde mij dat hij niet wist hoeveel applicaties hij in huis had. Er was niemand die hem een overzicht kon geven van alle applicaties. Ja, ze hadden SAP en Oracle, maar daaromheen en daarnaast een breiwerk van zelfontwikkelde applicaties voor allerlei doeleinden en een veelheid aan technologie en programmeertalen.
Maak eens een landschapsfoto. Door een inventarisatie van het applicatielandschap krijg je inzicht. Allerlei kenmerken van applicaties worden in kaart gebracht, zoals aantal gebruikers, geboden functionaliteit, gebruikerstevredenheid. Maar ook technologische kenmerken, zoals programmeertaal, database, interfaces, user interface en de hardware. En wellicht interessanter: welke bedrijfsfuncties worden ondersteund, wat is het (financiële) bedrijfsbelang, wat kost de applicatie (beheerinspanning), hoe robuust is de applicatie (aantal incidenten, aantal changes).
Het verkregen inzicht gebruiken we voor vier invalshoeken om het besparingspotentieel ten opzicht van een benchmark concreet te maken:
- In kaart brengen van die applicaties en infrastructurele componenten die een bedrijfsprocesketen ondersteunen om met behulp van ketenmanagement en ketenmonitoring de kwaliteit en kosten efficiëntie van het bedrijfsproces te verbeteren.
- Identificatie van applicaties die geschikt zijn om in de cloud te plaatsen of die kunnen worden vervangen door functionaliteit die al beschikbaar is vanuit de cloud.
- Als analyse voor een applicatierationalisatie en het inzicht vertalen naar een programma en aanpak om applicaties te ontdubbelen, elimineren van functionele overlap, verlagen van service levels (end-of-life) of gewoon uitzetten, omdat niemand de applicatie meer gebruikt.
- Ter bepaling van een adequate sourcing strategie en het inzicht vertalen naar een herverkaveling van leveranciers om de business beter te kunnen bedienen en schaalgroottevoordelen te creëren.
Dus, mocht je na de zomer verslingerd zijn aan het maken van foto’s: maak eens een landschapsfoto.
Niet echt een nieuw idee, genoeg ‘Mondriaans’ vanuit de verschillende architectuur groepen die zich bezighouden met dit soort ‘selfies’ waardoor ik me afvraag hoe dit de aansturing gaat verbeteren. Een foto is tenslotte vooral een moment opname welke zonder realtime input van wijzigingen dus compleet ongeschikt is voor de sourcing.
Helaas weer een auteur die niet reageert (gezien zijn trackrecord) als er een discussie gevoerd wordt n.a.v. door hem geschreven artikelen.
Ben namelijk wel benieuwd hoe hij deze foto ziet in combinatie met BYOS…
Hmmm ja Ewout, ik ga met je mee.
Maar anderzijds, als een CIO aan de IT-winkel vraagt wat voor spul ze allemaal in gebruik hebben en de afdeling moet het antwoord schuldig blijven, dan is er toch een fundementeel probleem binnen die organisatie.
Was het al niet wegens licentie flauwekul van aangekochte (of wellicht anderzinds aangeschafte) software,
Dan ook om te voorkomen dat een zelf gemaakte tool meermaals opnieuw bedacht wordt.
Verder gaan dan dat lijkt me weinig zinvol. Als blijkt dat een software product bakken geld kost en niets oplevert dat is dat zelden een reden om er van af te stappen.
Dit ongeacht of een ander stuk software langdurig een goede staat van dienst heeft bewezen. Voorbeelden te over.
@pascal
Configuratie management?
Voordat er nu weer een discussie over het middel gevoerd gaat worden, ik bedoel dus het proces zelf. Zal wel weer als de criticaster gezien worden maar dit is gewoon oude wijn in nieuwe zakken stoppen.
@Ewout .. configuratie management kan een oplossing zijn in deze.
Echter, configuratie management gaat hand in hand met change management.
In een gecontroleerde omgeving, waar IT beheer bepaalt welke applicaties waar uitgerold worden, en wijzigingen alleen aanbrengt na indien van een changeverzoek, kun je zo’n overzicht eenvoudig ophoesten.
Op het moment dat gebruikers zelfs software mogen installeren, upgraden en/of BYOS geaccepteerd is, heb je als beheersorganisatie geen controle meer. Dienen gebruikers nu telkens als ze iets wijzigen netjes een change verzoek in, dan lukt het nog vrij aardig het overzicht te bewaren, maar de praktijk leert dat het gedrag van de gebruikers nogal eens te wensen overlaat in deze.
Je zou nog eens in de zoveel tijd je omgeving kunnen scannen op wat er zoal draait, maar ook dit is niet waterdicht, en vooral achteraf.
Aangezien dergelijke omgevingen vaak zijn ge-outsourced en het technische beheer ervan is verdeeld over een groot aantal verschillende afdelingen, kon zo’n landschapsfoto nog wel eens een kostbare exercitie worden aangezien zo’n dienst meestal niet standaard is.
Sterker nog, in een groot aantal gevallen is (vooral bij grotere omgevingen) niet eens meer dergelijke informatie te achterhalen vanwege de enorme set gebruikersauthorisaties die daarvoor benodigd is.
Ook staan 3rd party applicaties die aan een SAP systeem hangen vaak niet eens in hetzelfde datacenter als dat SAP systeem.
Wie als bedrijf/organisatie dat inzicht niet heeft, doet klaarblijkelijk niet aan beheer.
Dat is ook zo een overbodig en lastig iets, een systeembeheerder die altijd nee zegt, maar je kunt haar/hem wel lekker de schuld geven van alles wat fout gaat . . .
Zonder gaat het natuurlijk nooit fout!
@pascal
Zoals je al aangeeft is het probleem de ongecontroleerde omgeving, hele BYO is een afwijking op de best practice van baselines. Zeg niet dat ik een kant en klare oplossing heb maar ‘configuration management by exception’ zou al veel kunnen verbeteren want een baseline is tenslotte ook een foto en afwijkingen hierop vastleggen een vorm van change management.
Nu is het in kaart brengen van infrastructurele componenten nog wel te doen doordat meeste CIM enabled zijn, Common Information Model is een vorm van standaardisatie dat de basis vormt van zowel Windows Management en Standard Based Linux Instrumentation. Afwijking hierop vormen helaas de applicaties, deze worden meestal dus niet gekozen op basis van beheersbaarheid.
De vragen die auteur stelt over beheersinspanning zijn dan ook precies het Trojaanse paard van Enterprise Architectuur, de non-functionele requirements worden vrijwel nooit gewogen. Maar ja, wat wil je als dit soort architecten – net als ontwikkelaars – de infrastructuur als een abstractie ziet.
Een van de grootste problemen bij dergelijke “foto’s” is het missen van het realtime gehalte (reeds genoemd). Het tweede lastige is het niveau van detail (granulariteit). Natuurlijk zou het een ieder van ongelofelijk hoeveelheid inzicht verschaffen als je vanaf de Business doelen, via de Business processen richting de applicaties naar de fysieke systemen zou kunnen wandelen. En dat op elk moment van de dag. Waarbij elke dwarsdoorsnede gemaakt kunnen worden.
Wat in ieder geval nooit automatisch gedaan zou kunnen worden is dat de bedrijfsdoelen en bedrijfsprocessen geautomatiseerd tot stand komen (grafisch gezien dan). Dit zijn verzonnen (door de mens) zaken en hebben (behalve de uitvoering van het bedrijfsproces) geen concrete tastbare tegenhangers. Applicaties, informatie/data stromen, interfaces, systemen etc…. zijn tastbaar en meetbaar.
Het mooiste systeem dat ik ooit gezien heb is (vreemd genoeg) een systeem van EMC Smart Discovery Manager. Het is een apparaat dat je in je netwerk hangt en naar een dag tot op enorm hoog detailniveau voor 90% je gehele applicatie/infrastructuur landschap visualiseert. Veel tools kunnen dit ook, maar “proben” alles was ze zien, m.a.w. vragen aan een Oracle DBMS of het er een is en welke versie. Dit apparaat analyseert al het netwerkverkeer. Er zit een soort DNA fingerprint database achter die van heel veel applicaties/systemen weet wat er voor pakketjes over de lijnen gaat. Ik heb hier ooit een demo van gezien (in een life omgeving) en het was wonderbaarlijk. Na de eerste keer, kan dit apparaat elke kleine verandering gemakkelijk op seconden niveau visualiseren. Het enige wat je dan nog zou moeten doen zijn die bedrijfsdoelen en processen koppelen aan de ICT. Gelukkig veranderen bedrijfsdoelen en bedrijfsprocessen niet op dagbasis. Dat moet je dan met de hand doen en kan ook deels geautomatiseerd worden. Het is allemaal exporteerbaar naar meer toegankelijkere tools als BizzDesign of ARIS.
Ik heb al veel meegemaakt, het maken van dit soort foto’s. Inventariseren is een tijdrovende bezigheid en terwijl je bezig bent veranderd alles continu. Je maakt dus een foto van een bewegende situatie en we weten allemaal dat dat niets verhelderends oplevert.
Maar je wilt die informatie wel hebben. Dus begin eerst eens vast te stellen welke informatie belangrijk is, wie bij deze informatie moet komen en hoe de informatie wordt bijgewerkt. Je zal zien dat er verschillende methoden zijn om snapshots te maken van systemen op basis van repositories die worden bijgewerkt door verschillende beheertools. Ik zou de scope dan beperken tot de applicaties die het primaire bedrijfsproces ondersteunen en dit niet voor alle applicaties te doen (20-80 regel).
Applicaties vervangen door cloud functionaliteit, ja dat is kort door de bocht een goed plan. Maar het gaat veel meer om de interfacing tussen applicaties, infrastructuur en dan een functie in de cloud zetten en dat kan nogal wat hoofdbrekens opleveren.
Mijn advies zou zijn dat je na de eerste snapshots een architectuur gaat vaststellen die je wil en vervolgens een roadmap om van de huidige situatie naar de nieuwe situatie te komen. Dit beleg je bij bestaande en nieuwe projecten die de betreffende applicaties raken. Vervolgens zal je na een paar jaar zien dat langzaam de contouren van de nieuwe architectuur ontstaat zonder grootschalige projecten met hoge risico’s.
Er is niet veel voor nodig om te zien of een applicatie wel of niet of slechts door een enkeling wordt gebruikt. Met de meeste bestaande beheertooling kun je dit snel achterhalen. Dit is laaghangend fruit dat snel kan worden geoogst. Vergeet vooral geen vigerend beleid op te stellen en af te tikken om applicaties uit te faseren.