Boganmeldelse: Enterprise Architecture As Strategy: blogindlæg 2 om evidens

Jeg har tidligere skrevet om IT branchen som flosklernes paradis, og det er ikke helt forkert. Men når man befinder sig i et evidens baseret sundhedssystem, som jeg gør til hverdag, så giver halvsøgte modeller, metoder og til tider langhårede løsninger ikke genklang, hverken på direktionsgangen eller blandt klinikerne. Klinikerne kræver evidens, og hvis det ikke sker, så er det måske fordi den kliniske praksis ikke er ændret i takt med IT systemernes indførsel, og så er vi lige vidt. Men når jeg så køber bogen:

Enterprise Architecture As strategy,  Creating a Foundation for Business Execution (2006), 

hvor anbefalinger og konklusioner er baseret på 15 års studier (startede i 1995), og over 200 virksomheder deltog, så er der måske noget konklusivt og robust i denne bogs anbefalinger. Dette gør den, om ikke andet, så utrolig interessant i IT sammenhænge, da denne form for grundighed ikke ses så tit.

Bogen har jeg læst i sommerferien, og den handler om Enterprise architecture. Ikke som en teknisk disciplin, men som en ledelsesmæssig metode til strategi udvikling. Bogen er skrevet i 2006 af Jeanne W. Ross (principal Research Scientist. MIT), Peter Weil (director of CISR and MIT Sloan Senior Research Scientist) og David C. Robertson (Professor at IMD International).

Bogen omhandler hvorledes en virksomhed (hospital) skaber deres Foundation for Business Execution. Altså en virksomheds evne til, at eksekvere/gennemføre sine nøgleprocesser, på et kvalitetsmæssig højt og pålideligt niveau. For at dette kan ske, opstiller Ross, Weil og Robertson tre hovedområder en virksomhed skal igennem. Man skal definere og arbejde med følgende:

• Operating model (OM)
• Enterprise Architecture (EA)
• IT engagement model

Operating model defineres som: ” ..the necessary level of business process integration and standardization for delivering goods and services to customers” (s. 8). Med andre ord afspejler OM den vision og strategi som en virksomheds topledelse har besluttet. Påstanden er i bogen, at denne OM vil påvirke og dermed danne rammer og retning for en prioritering af IT indsatsen efterfølgende.

Enterprise Architecture (EA) defineres som: “The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company’s operating model (s. 47). EA skal beskrive sammenhængen mellem nøgleprocesserne, i en virksomhed, med systemer og data. De to områder: IT og forretning, er tæt forbundne, og forfatterne understreger i  bogen vigtigheden i, at IT løsninger understøtter forretningsstrategien. For at lette forståelsen af EA, arbejder man med et såkaldt core diagram, der repræsenterer et oversigtsbillede af arkitekturen, hvor nøgleprocessor, systemer og data som understøtter den valgte Operation Model, er vist.

IT engament model defineres som: ” the system of governance mechanisms assuring that business and It projects achieve both local and company-wide objectives” (s. 118-119). Altså et system af styringsmekanismer, så man sikrer at projekter realiserer lokale og overordnede virksomhedsmålsætninger. Tænker nogle her Benefit Mangement – så er man ikke helt forkert på den.

Ud over enkelte passager i bogen som oser af ”vi ved bedst”, og ”gør du som vi anbefaler, så går det dig godt i livet”, så er bogen veldokumenteret og i et sprog der er flydende og forståeligt. Bogen begraver sig ikke dybt i tekniske områder, men fokuserer på den ledelsesmæssige og strategiske planlægning af IT og EA, samt hvorledes det kan ses i sammenhæng til en forretningsstrategi. Bogen henvender sig til IT-chefer der er interesseret i en metode, figurer og rammer til at planlægge deres IT indsats og arkitektur, men den vil også henvende sig til studerende, da bogens teoretiske fundament er solidt og velbeskrevet.Selvfølgelig også til IT personer, der interesserer sig for EA.

Jeg vil gerne anbefale bogen, og med sine 234 sider, så er den hurtigt læst for de fleste. Jeg synes den giver et frisk pust, introducer nye veje og er nok tæt på noget, vi i IT branchen, vil kunne kalde evidens baseret. Om ikke så alene for den grund, læs den hvis du arbejder med IT i sundhedsvæsnet. Det skylder vi patienter, pårørende og ikke mindst klinikerne. De ydelser og systemer IT leverer, bør være mindst ligeså evidens baserede som dem klinikken leverer. 

Ellers ændrer IT ingenting, og bliver i bedste fald ligegyldigt og i værste ødelæggende for den forretning og kliniske kerneydelse, vi alle prøver at understøtte bedre.

Enterprise Architecture as Strategy: Creating a Foundation for Business Execution Jeanne W. Ross, Peter Weill, and David Robertson, 2006, Harvard Business School Pres

Status på Klinisk IT

Så blev det sommer, og det er tid til at gøre status. Min lille, noget niche prægede blog, har i omegnen af 50 unikke hits om dagen og har genereret en del henvendelser. Tina Bramsen (MF. Soc) var forbi for at tale om 3g/4g dækning på baggrund af mit indlæg i debatten eksempelvis. Der er desuden mange der skriver til mig løbende. 

Bliv endelig ved med det.

Ellers har jeg forsøgt mig med en boganmeldelse, og to store temaer: Teknologi i sundhedssektoren samt IT strategi arbejde i sundhedssektoren.

Det mest besøgte blogindlæg det sidste halve år var:

1. OO+NT=COO, blog indlæg nummer 3 om teknologi anvendelse i sundhedsvæsnet

2.Boganmeldelse: The Phoenix Project: A Novel About IT, DevOps, and Helping YourBusiness Win

3.Gevinstrealisering ved indførsel af ny teknologi (Benefits Management): blogindlæg nummer 4 om teknologi anvendelse i sundhedsvæsnet.

4. Management"The Tony Soprano way"

Efter sommerferien har jeg tænkt på flere emner som kunne være relevante. Jeg vil fortsætte med boganmeldelser og den første jeg tager fat på handler om Enterprise Architecture. Ellers kunne et tema omhandle barrierer ved indførsel af ny teknologi i sundhedsvæsnet samt et tema om modenhedsanalyser og deres relevans. Til sidst vil jeg selvfølgelig skrive en række blogindlæg som omhandler Nyt OUH projektet. 

Jeg vil gerne ønske alle en rigtig dejlig sommerferie. Vi ses til august.

Boganmeldelse: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

Jeg vil gerne anbefale jer en bog om IT drift. Den er skrevet som en roman, men indeholder væsentlige læringspointer og faglige elementer, som er relevante og tankevækkende. Bogen er skrevet i et flot og læseværdigt sprog, med mange aktion prægede afsnit, hvor IT drift som ofte sammenlignes med krigslignende situationer eller amerikanske aktion film. Jeg har flere gange blevet henført til min tid i militæret, når forfatterne taler om nedbrud i IT systemerne. Eksempelvis hvor IT driftschefen taler til sine sektionsledere om et massivt nedbrud i lønsystemet og efterfølgende et nedbrud i SAN:   

 

”First, the events that led to the SAN and payroll failure on Thuesday may not happen again. What started off as a medium-sized payroll failure snowballed into a massive friendly-fire SAN incident. “ s. 78.  

 

Man fristes til at råbe hell yea – Oorah. (udtryk fra marinekorpset) når man læser disse passager i bogen.

Samtidig sidder jeg ofte med et skjult smil over genkendelighedens glæde ved de små episoder som skildres i bogen. Disse episoder er nemme, at relatere til fra min egen tid i en IT driftsorganisation. Det gør bogen nærværende og morsom på sin egen let indforståede facon.

 

 Bogen starter med at hovedpersonen Bill Palmer bliver forfremmet to niveauer i IT afdelingen i en større produktionsvirksomhed der producerer reservedele til biler. Bill er tidligere marine soldat og sergent og dermed også eksplicit bogens helt store helt. Han går fra at være sektionsleder i en mindre sektion med 6 medarbejdere til at blive afdelingschef for hele IT drift. Samtidig er en række større forretningskritiske projekter forsinkede – specielt Phoenix projektet (del af titlen på bogen), som er et 2 år forsinket, 20 mill dollars stort projekt der skal vende nedturen for Firmaet Bill er ansat i. Desuden er IT drift i virksomheden kendetegnet ved brandslukning, dag til support og intet overblik over hvad medarbejderne reelt bruger deres tid på.

Bogens helt store tema beskrives ret præcist på side 53 hvor Bill Palmer selv beskriver de problemstillinger som IT afdelingen står over for. Nedenstående kan ligeledes godt betragtes i et generelt perspektiv for branchen, og derfor er bogens budskaber som oftest relevante og genkendelige.

The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.

The results are never pretty. Usually, the software product is so unstable and unusable that even the people who were screaming for it end up saying that it’s not worth shipping. And it’s always IT Operations who still has to stay up all night, rebooting servers hourly to compensate for crappy code, doing whatever heroics are required to hide from the rest of the world just how bad things really are.( s.53)

Bill Palmer og hans to sektionsledere bliver i første del af bogen kastet ud I det ene store IT nedbrud efter det andet, en ekstern sikkerheds audit samt indtil flere problemstillinger som kun få af deres medarbejdere kan løse (flaskehalse). Herefter møder Bill Palmer Erik Reid som tidligere har arbejdet i produktionen på en af virksomhedens fabrikker og nu er blevet tilbudt en plads i bestyrelsen. Erik Reid er Bill Palmers redningsmand og han introducerer en række værktøjer som Bill kan benytte for at få styr på sin organisation og produktion. Erik forklarer sin metode på en slags hippie/buddhisme kind of way:  

”The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that's what's between the business and the customer. The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework. And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery." S. 91

Bill Palmer arbejder efterfølgende med at rette IT afdelingen op og i højere grad sikre en konsensus med forretningen, sikre gode og u bureaukratiske processer samt at arbejdet ligeligt fordeles mellem medarbejderne.  Der arbejdes med at identificere og udbedre flaskehalse samt minimere ikke planlagt arbejde (læs akutte nedbrud og projektopgaver), at arbejde struktureret, strategisk og sammenhængende i en slags end-to-end proces. Alle vægge plastres til med Kanban tavler og LEAN begreber flyver frit gennem luften. Alt sammen meget dejligt når det lykkedes, men skildringen i bogen virker lidt frelst, og næsten for let og lykkeligt.

Bogen er desuden lidt arketypisk i sine personskildringer. Bill vores helt store helt, Patty er en ret firkantet change manager der elsker (lange og komplekse) procedurer, Wes som er driftsmand med alt hvad der hører til faget. Han råber op inden har tænker, han er lidt for overvægtig og elsker teknologi mere end mennesker, John er den over firkantede IT sikkerhedsansvarlige og Bren er IT nørden, magikeren, wizkid eller en slags Yoda der laver alting i IT afdelingen. Stort set intet arbejde i IT afdelingen, i starten af bogen, kan udføres uden Brent hjælper. Når Brent arbejder, går han ligesom i en trance lignende tilstand, manipulerer med kode på en intuitiv og uforståelig facon.  (“You don’t need to see his identification … These aren’t the droids you’re looking for …). 

Som andre passager i bogen, er personskildringerne lidt arketypiske og ordinære, men derfor er de også genkendelige fra den virkelige verden. Det er dels morsomt, men også lærerigt i forhold til, hvordan man får folk med forskelligt udgangspunkt og perspektiv til at arbejde sammen.

Implementeringen af Eriks Reids three ways kører nok mere gnidningsfrit i bogen end i virkeligheden. Der er bare intet der er så dårligt, der så hurtigt, bliver så godt. Men hvis man kan se bort for dette, så er indholdet i bogen stadig relevant. Bogen beskæftiger sig ikke voldsomt meget med de menneskelige eller kulturelle elementer i så store ændringer, hvilket nok er en væsentlig mangel. Men koncentrerede pointer, der er skåret ud i pap, står også tydeligere frem, og det er faktisk rart at en række ting er sat på spidsen for læseren.

Jeg synes bogen er fremragende og jeg vil anbefale den til alle der er i IT branchen. Bogen giver desuden et let tilgængeligt indblik i maskinrummet i en IT afdeling, samt illustrerer vigtigheden i, at få en IT strategi, prioritering af IT opgaver samt udvælgelse af projekter koordineret og konsolideret med forretningens vision og mål. 

Alene på den baggrund, bør bogen ligeledes læses af direktører, afdelings- og sektionsledere og udviklingsfolk i virksomheder, der alle er afhængig af IT, til at nå deres forretningsmål.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

Alle sidehenvisninger er baseret på Kindle versionen med en opretstående vinkel.