Myth #7: “Architecture And Strategy Are The Same Thing”

It used to be that most hospital authorities could get by without employing ICT architects of any description. Now most of them have at least one or two solution architects, and increasingly many of them are starting to employ enterprise architects.

Proceed with care! One of the things I like to stress to our clients is that architecture is not strategy. Let me say that again. Architecture is not strategy.

One of the problems I have observed with some of the digital hospital programs around the country has been that an excessive focus on enterprise architect concepts (Zachman, TOGAF, etc.) has come through in many of the documents I have read from the planning phases.

I have yet to meet any enterprise architect who has actually worked at the front line of the hospital admitting patients, or on the wards; and while the last thing we want is just more of what we do now, anybody planning a new hospital has to at least understand what the current state is before they set sail with a new strategy.

You absolutely do need architects, but it is my firm view that your architecture department should not be running your strategy. Your ICT strategy ought to be a subset of your business strategy. And the best people to do the work are those within your department who understand the work practice challenges within the organisation.

It is valuable to also draw on external assistance from strategy specialists, such as my company, The Checkley Group.

One of the things that we would always ask our clients (and I am sure the other consulting firms would do the same) is whether they have an up-to-date picture of all their systems, and how they hang together.

In short, what we are really asking for is an enterprise architecture diagram. But we very rarely find one, and generally we end up helping the organisation build one.

A couple of years ago, I worked on a strategy for a local health District in a combined Metro/rural part of New South Wales. At the end of the process, we presented a summary of our findings to the Board. Included in our presentation was a one-page diagrammatic of all the key systems the organisation currently had, along with the ones they were in the process of implementing, and also the ones that they did not yet have, but that we would generally expect to find in any leading digital hospital.

In other words, it was a kind of “current state on a page”.

Immediately we put up the slide, one of the long-standing board members interjected: “I’ve been asking for this for years!”

I wasn’t surprised to hear this; I’ve had a similar reaction many times before. It never ceases to surprise me that most organisations (and not just in healthcare, by the way) cannot easily produce a summary of the major systems that they use.

Very often the ICT department can produce a list of all the servers they have, or a really complex spaghetti diagram of all the interfaces between all the boxes, with all sorts of technical terms scribbled all over it (HL7 and so on).

Nearly all of which is totally meaningless to the average executive.

Now, in my opinion, a good enterprise architect can help build this kind of current-state picture for an organisation, and keep it up-to-date and relevant on an ongoing basis. And this isn’t important just for the sake of showing executives how complex things are.

It’s really important for enhancing the organisation’s ability to integrate new developments, new systems, and new processes into its current practice. If you think about it, spaghetti diagrams only arise because people are joining things that were never meant to be joined together.