Whent to Australia to learn about POSIWID

I have just returned from Sidney for the first Australasian Enterprise Architecture Conference, where I was invited to speak. I had some concerns on the long journey, but I must say that the program, the level of the speakers and the nice people I met – just made up for it a 1000 times. I was blown away and the only regret that I have was, that I did not speak to more people or the conference were a little longer.

I would like to quote the Chair Darryl Carr when he writes:

High-quality speakers
Our international and local keynotes did not disappoint. Whether it was Tom Graves and his insightful view of Big Picture Enterprise Architecture, Craig Martin's take on the design of businesses in the age of Digital Disruption, or IASA's President Paul Preiss with his incredibly passionate view of the future of the architecture discipline, attendees were treated to an amazing amount of information and experience.
 
Here are just some of the comments from attendees:
•    Superb!
•    Fresh and insightful approach to the development of the architecture profession.
•    Very high level of speakers.
•    Great real world stories.
•    Thought provoking and challenging the current paradigm.

Sometimes you are truly surprised. For me it happens not that often. Last week it did several times. Thank you all for making my trip worth to remember. 

Ohh yeas POSIWID: (The) Purpose Of the System Is [expressed in] what It Does. 

It is generally not a good idea - but in my line of work it is often the case. I will explore the theme later this week because in the healthcare sector we tend to do that a lot.

New Concept for the Digital Hospital – English version

Today an empty field of 78 hectares in the 3 largest city in Denmark. In seven years a new University Hospital (Nyt OUH) complete with 714 beds and 52 operation rooms of various types. A major building and development project regarding clinical processes, organization, IT and technology is underway. TOGAF, as a framework, is the driving force of this planning process and will ensure a coherent and up to date IT architecture when the hospital is finished in 7 years.

The hospital will collaborate with the University of Southern Denmark in order to bridge the gap between research and clinical treatment. As part of the major building project, the Region of Southern Denmark and the project organization will work on describing, analyzing, acquiring and implementing IT and technological solutions that will redefine the healthcare delivered, support the clinical vision and make day to day clinical practice operate in the new building. We call it “The Digital Hospital”

The digital solutions that are the building blocks of the digital hospital must accommodate the opportunity to support the best possible patient treatment, as well as support new working procedures and processes. To further a desired progression towards New OUH, the visions must necessarily affect the hospital's core business - patient treatment - by making the digital field unique.

When dealing with IT everybody in the organization have an opinion on how to do it, how to implement and what to buy.  Therefore, it is easy to miss the strategic and analytical perspective and focus on day to day deliverables and small adjustments according to the user needs. Not that they are insignificant – on the contrary, but they are minor adjustments that will only lead to small changes in the business or processes and probably not deliver a strategic significant change. IT planning, enterprise architecture etc will get you there. However, it is more challenging, and some will argue more time consuming. In a big organization like ours, it is the only way to go.

The Digital hospital as a concept for Nyt OUH was sketched out 3 years ago. The Digital concept where more of a method than an actual concept.  I decided therefore to write a new one, which clearly marked the road we are on and point us in the right direction. The Region have a set of architecture principles and I made sure that our Concept was aligned with those. You can always argue that a set of IT principles or the Concept is flawed and is not covering everything. It might be too superficial or to focused on detail. We will adjust our concept regular and make sure it provides us with the needed frame and direction for the future.

 

Link: Concept for The Digital Hospital
Link: Digital vision (Danish, english will be uploaded shortly)

The planning of IT – is it a necessary evil ?

What if you are in charge of a centralised IT department with infrastructure architects, solution architects, business consultants, account managers etc. And lets say the company is huge and has large departments all over the world. Again lets imagine that the departments are in charge of implementing and administration of the It systems for the entire organisation. So they have, so to speak, divided the systems and projects among themselves leaving the centralised IT department with architectural consulting and Infrastructure as their only areas of responsibility. To govern the IT they have established a kind of Architecture board, where decisions of a strategic level are made as well of decisions of how and which projects to proceed and fund. An important board that if respected and used have the ability to align the decentralised organisation in and around a common business strategy.

I guess with the above organisation,  IT is closer to the business it is supposed to support, it might get the process of funding to run more smooth, because the local management knows exactly where it hurts. It is very agile and can react to imminent issues that may arise as small or medium business can do. The problem, or positive people would say challenges, are of course, to align all the IT initiatives, IT management and operations, IT projects and the overall IT planning process, of the organization as a whole.

When power and decision making are decentralised people tend to decide and use that power. Often not for the greater good of the whole organisation and not for the long term planning – actions are often isolated decisions based on local knowledge, local challenges and therefore short term IT planning.

So no system or organisation is perfect – but maybe we have a solution where we can have both local knowledge and business integration at the same time as long term strategic IT planning.

It is called Enterprise architecture – and it fucking rocks if it is implemented and respected by all the participants in the organization. The video below quickly explains the concept of enterprise architecture way better than I can, so please take four minutes to watch it.

I am certified in TOGAF 9.1 Enterprise Architecture and that is just one out of a handful methodologies regarding enterprise architecture.  The real issue with the TOGAF framework or more precise the Architecture development method (ADM)

The open Group (opengroup.org)

is to gain enough speed in the administrative process, that implementing EA will not result in a standstill of the IT within the business.  If that happens, the business units will just circumvent the EA processes and acquire the IT themselves. The more the individual departments operate on their own – the more short termed and individual are the IT planning – but then again it is closer to the business needs. On the other hand the more centralised IT is planned, the more administrative and bureaucratic everything can tend to be and then it will of course be further away from the eminent business challenges.

I guess I don’t have the answer except that short and long term planning is necessary. The TOGAF EA is a great way to handle it – It just need all to respect the processes established and it needs to be tailored to the organisation it is supposed to support – otherwise the resources are lost and we might even be further away than when we started to plan for IT in the first place.

By the way - good people will leave in all the parts of the organization if you do not respect the craft of doing IT properly. Especially the enterprise architects will not tolerate that business and IT is done with no planning and with a little or no respect to strategies, business needs and the processes that have proven best. TOGAF calls that capability based planning - how the overall EA capability of the organization is established and maintained -  don't ever ignore that in your organisation either.

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

First published in danish here

I would like to recommend you a book on IT operations . It is written as a novel, but contains significant learning points and academic elements that are relevant. The book is written in an attractive and readable language, with many all-action sections where IT operations often are compared to war-like situations or American action movies. I have several times been thinking my time in the military, when the authors are talking about crashes in IT systems. For example, the IT operations chief speaks to his section leaders on a massive crash in the payroll system and then a crash in the 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.  

 

 One is tempted to shout hell yea - Oorah . (Expression from the Marines) when reading these passages in the book.

 

At the same time I often find myself smiling of recognizable elements in the small incidents portrayed in the book. These episodes are easy to relate to from my own time in an IT operations organization. This makes the book relevant and funny in its own light consenting shape.

 The book starts with the main character Bill Palmer being promoted two levels in the IT department of a large manufacturing company that produces car parts. Bill is a former Marine and a sergeant and hence the book's explicit big hero. He goes from being head of section in a smaller section with 6 employees to become Head of the entire IT operation. Meanwhile, a number of large business critical projects are delayed - especially the Phoenix project (part of the title of the book), which is a 2 -year delay, 20 million dollars big project to reverse the decline of the Company Bill is employed in. In addition, IT operations in the enterprise are characterized by their daily effort to fix a large number of issues and they have no overview of what the employees actually spend their time on.

The book's major theme is described fairly accurately on page 53 where Bill Palmer himself describes the issues that the IT department faces. The following may also be well regarded in a general perspective on the industry, and therefore the book's messages are often relevant and recognizable.

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 and his two section leaders are in the first part of the book thrown in one big IT crash after another, an external security audit and several issues that only a few of their employees  can solve (bottlenecks ) . After those issues Bill Palmer meets Eric Reid who has previously worked in the production at one of the factories and has now been offered a seat on the board. Erik Reid is Bill Palmer's savior and he introduces a number of tools that Bill can use to get a handle on his organization and production. Erik explains his method in a sort of hippie / Buddhism 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 works subsequent to correct the IT department, aligns IT with business, ensure good and u bureaucratic processes and distribute work equally among the employees. He tries to identify and address bottlenecks and minimize unplanned work (read emergency breakdowns and project tasks) , to work in a structured , strategic and coherent end-to -end process. All the walls eventually are patched with Kanban boards and LEAN concepts are flying freely through the air. All very nice when he succeeds, but the portrayal of the book seems a little saved, and almost too easily managed and to happy.

The book is also a little archetypal in its character sketches. Bill our biggest hero, Patty is a change manager who love (long and complex) procedures, Wes is operationsmanager with everything that belongs to the subject. He yells before thinking it through , he 's a little overweight and loves technology more than people , John is the IT Security Officer and Bren 's IT nerd , magician , WizKid or some sort of Yoda doing everything in the IT department. Virtually nothing work in the IT department at the beginning of the book, and it cannot be fixed without Brent helps. When Brent works, he goes like in a trance-like state, manipulate code in an intuitive and incomprehensible way. (“You do not need to see his identification ... These are not the droids you're looking for ...).

In other passages in the book, the person depictions is little archetypal and ordinary, but that makes them on the other hand very recognizable from the real world. It is partly amusing but also instructive in terms of how to get people with different backgrounds and perspectives to work together.

Implementation of Eric Reid's three ways runs more smoothly in the book than it probably would in reality. There's just nothing that is that bad and that rapidly becoming well. But if you can ignore this, then the content of the book is still relevant. The book does not deal with human or cultural elements of such major changes, which is probably a major gap.

I think the book is excellent and I would recommend it to everyone in the IT industry. The book also provides an accessible insight into the engine room of an IT department, and illustrates the importance of getting an IT strategy, prioritization of IT projects and the selection of projects coordinated and consolidated with the business vision and goals.

On this basis alone, the book should be read by managers, department and section managers and development staff in companies, which are all dependent on IT to achieve their business goals.

The Phoenix Project: A Novel About IT, DevOps , and Helping Your Business Win
All page references are based on the Kindle version with an upright angle.

Book review: Enterprise Architecture As Strategy

Was first published in danish here

I have previously written about the IT industry as a place were empty words and promises lives well, and it is not entirely wrong. But when you are in an evidence-based health system, as I am, so will half intelligent methods/model and as we say in Denmark, sometimes long-haired solutions not supported by either the boardroom or among clinicians, not result in praise. Clinicians require evidence , and if they does not, then it might be because clinical practice has not been changed, we still deliver healthcare as we always have done and then there is no clinical effect. Power to paper and nothing more.  So it is only when the clinicians want to discuss the change of healthcare, our IT system is having an effect.  But then I bought the book :

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

where recommendations and conclusions are based on 15 years of study ( started in 1995) , and more than 200 companies participated , so perhaps there is something conclusive and robust in this book's recommendations . This makes it, if nothing else, extremely interesting in a IT contexts , as this kind of thoroughness is not seen often in our line of work.

 The book I have read in the summer and it's about enterprise architecture . Not as a technical discipline, but as a managerial approach to strategy development. The book was written in 2006 by Jeanne W. Ross ( Principal Research Scientist. MIT ), Peter Weil ( director of CISR and MIT Sloan Senior Research Scientist ) and David C. Robertson ( Professor to IMD International).

The book describes how a company (hospital) create their Foundation for Business Execution . So a company's ability to execute / implement its key processes in a qualitatively high and reliable level . For this to happen, Ross, Weil and Robertson identifies three main areas a company must go through. You have to define and work with the following :

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

Operating model is defined as : " ...the necessary level of business process integration and standardization for delivering goods and services to customers” (s. 8).. In other words, OM reflects the vision and strategy as a company's top management has decided . The claim in the book is that OM will influence and thus provide a framework and direction for prioritizing IT efforts in the future.

 Enterprise Architecture (EA ) is defined as : "The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company’s operating model (p. 47). EA should describe the relationship between the key processes in a company with systems and data. The two areas IT and business are closely related , and the authors of the book emphasizes the importance of the IT solutions support business strategy. To facilitate the understanding of EA work they introduce a so-called core diagram representing an overall view of the architecture , with key processes, systems and data that support the selected Operation Model is shown.

 IT engagement model is defined as : "” the system of governance mechanisms assuring that business and It projects achieve both local and company-wide objectives” (s. 118-119) . So a system of governance mechanisms , to ensure that projects achieve local and overall business objectives. Are you thinking Benefit Management - well you are not entirely wrong.

 In addition to individual passages in the book that has a, for a Dane, a too straightforward message: " we know best " and " do as we recommend , then it will go well in life ," then the book is well documented and in a language that is fluent and understandable. The book does not bury you deep in technical terms, but focuses on the managerial and strategic planning of IT and EA , as well as how it can be seen in the context of a business strategy . The book is intended for IT managers who are interested in a method that shapes and frames their plan to align IT efforts and architecture , but it will also turn to students as the book's theoretical underpinnings are solid and well documented.

 I would like to recommend the book, and with its 234 pages, it is a fast read for most people. I think it gives a breath of fresh air , introduce new ways and is probably close to something we in the IT industry , will  call evidence-based . If nothing then only for that reason. Read the book - We owe it to patients, families and especially clinicians. The services and systems IT delivers , should at least be as evidence-based as those services our clinic supplies.

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

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