The Purpose of Architecture

Very thought-provoking interview from MIT's Ross

MIT’s Ross on How Enterprise Architecture and IT More Than Ever Lead to Business Transformation

Particurily the following two points,

If you have all the money in the world, you’re not forced to make tough decisions. Architecture is all about making tough decisions, understanding your tradeoffs, and recognizing that you’re going to get some things that you want and you are going to sacrifice others

We really just need architecture to pull out unnecessary cost and to enable desirable reusability. And the architect is typically going to be the person representing that enterprise view and helping everyone understand the benefits of understanding that enterprise view, so that everybody who can easily or more easily see the local view is constantly working with architects to balance those two requirements.

Health IT Standards: Where went wrong

Over the past few years I have been facing people with two extreme views - one view is that 'standard is magic', the other extreme view is that 'standards never work'.

I am not going to address the second one here, since I concluded that it is primarily caused by the people who is holding the first view, as long as we address the root cause of the first view, hopefully we are able to help the second group of people see the benefits of standards.

To avoid confusion and set the context correct, the HIT standards I am talking about here is interoperability standards such as HL7v2, HL7v3 RIM, CDA etc, excluding terminology.

For those people who has the view of  "standard solves everything" tends to have the following characteristics

1. Lacks the mindset and experience of architecture design

2. Theoretical view of the world out there, and pursue the dream of  'silver bullet'

3. Not Invented Here (NIH) Syndrome


Let me share with you few real conversations I had in the past. Once I was asked about how we know that the interoperability standard developed is ready for implementation. Guess what is my reply, my simple suggestion is the following question,

"Do you know HOW to implement this standard if you are the one to implement?"

I continued to say that if the answer is "No", then I am 100% sure that there must be something very wrong with it even before I look at it.


In another situation, I was asked how the standard can help to churn good data out of low quality data, that's really amusing! How can it be possible that interoperability standard itself turn bad data into good data? If some data is missing from the received message, yes, the receiving system may be able to figure out the missing data, but that is not going to be solved by standards itself even if it is achievable.

For people who holds the view of 'silver bullet', they tends to misplace the use or application of one particular technology or standard, take the case of ISO13606 or openEHR, which I find it very useful for clinical requirement definition as I commented on this blog - Complexity of Standards, however if we are going to turn that standard into a universal data exchange and OLTP/OLAP model, that's where standard scares away the people who want to adopt standards in the first place.  This kind of debate is just as useless as arguing 'whether to use SQL or MapReduce', the right answer shall be 'Use the technology where it thrives'.

The last one - NIH syndrome, it is so pervasive, different people do have different views and opinions, I guess everyone wants to create his/her own thing so that we can leave some legacy behind, I am not exception. This can only be solved by the organization which shall enforce the rule of putting personal views and opinions behind organization's and extended community's collective objective. If you do not use the standards the industry already developed, and continue to enhance and extend, then what is the point of developing standards in the first place? It defeats the whole purpose of using standards.


So how to equip yourself with the architectural mindset to solve the first two problems mentioned above?

Lets look at the definition of an architecture used in ANSI/IEEE Std 1471-2000:

    "The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

The most difficult part of architecture design is reflected in the second part of the above definition, the principles governing its design and evolution to ensure that architecture's agility - extensibility, configurability, customizabillty, etc. It is extremely easy to design an architecture or information model without considering its evolution, however this kind of system is extremely fragile, I think this point will somehow relate to some of the projects you are involved, and you might be smiling. If so, please continue to read.

So how to ensure the architecture's agility?

1) Why? We shall ask the WHY question before you develop anything, whether it is interoperability standard or a piece of software, it is all about design. Only when you ask WHY, you will be able to uncover the real objectives. The tendency is that users give very vague requirement, and sometimes they are just clueless.

2) Anticipate! With the correct understanding of objectives, you will perform some level of predictive analysis. How far and deep you can predict is based on your experience, that's why architecture design is an art to some extent.

3) Tradeoff. Architecture design is all about trade-off, it is the design of different choices, you can use ATAM (Architecture Tradeoff Analysis Method) to help you on that.

4) Outcome. We shall think about outcome before we start to develop anything.


5) Engineering.  We need to have strong engineering discipline to do the work. I have mentioned this point in my previous post - Standards based Implementation

To conclude, interoperability standards development is architecture design activity, treat it seriously, realisticly and holistically

If you are in the middle of developing your own backyard standards, think about twice here! Are you on the right path?

Architecture should be as beautiful as Chinese poetry

I very much enjoyed Chinese poetry especially Song Ci (宋詞). The term ci simply means "word". ci poetry in fact is written songs. Most of the poems do not even have a distinct title but are named after an original melody. Composers and writers used this melody to write a new poem that could be sung to the original famous melody or tune pattern (cipai 詞牌), a technique called contrafactury. This is the reason why we often see the same title for a ci poem, like Dielianhua 蝶戀花 "Butterflies love blossoms", Mantingfang 滿庭芳 "Scent fills the hall", or Yu meiren 虞美人 "Lady Yu".

Below is one of the most famous Song Ci

念奴娇•赤壁怀古
作者:苏轼
大江东去，浪淘尽，千古风流人物。
故垒西边，人道是，三国周郎赤壁。
乱石穿空，惊涛拍岸，卷起千堆雪。
江山如画，一时多少豪杰。
遥想公瑾当年，小乔初嫁了，雄姿英发。
羽扇纶巾，谈笑间，樯橹灰飞烟灭。
故国神游，多情应笑我，早生华发。
人生如梦，一尊还酹江月。

One of the main reasons I enjoy this type of poetry is that it is very concise and leads to so much imagination which is extremely hard to describe in word, in fact too much description in word will only destroy readers' ability for imagination.


For example, in the above poetry, "乱石穿空，惊涛拍岸，卷起千堆雪" only few characters, yet it is so powerfully described the extremely dangerous red cliff site where the famous battle was fought between the Wei Kingdom (魏国) and Wu Kingdom (吴国) during Three Kingdoms era. I am sure that you will probably have such kind of mental image projected in your mind.



In fact this picture does not really convey the meaning of "乱石穿空", also it did not exactly convey the speed and power of the wave hitting the cliff, in the Chinese version, it is concisely described by one word in Chinese - 惊 (scared), we can imagine how hard the wave is hitting the cliff since the wave is described as escaping towards the cliff at full speed. I am sure now the mental image will be much more vivid and powerful.


So how is it related to architecture? In my view, two takeaways

1) Architecture should be as concise as possible, it will make easy and quick understanding for architecture users (the development team and maintenance/operation team), and ensure the architecture's efficiency without superfluous artifacts handing around to make the design complicated for the sake of complexity.

2) Architecture should be extensible internally for future ongoing enhancement.

It will be harder to achieve the second objective if the architecture has a lot of superfluous artifacts. Just like poetry, if you described with too much unnecessary words, not only it destroy the beauty of the poetry, also inhibits reader's imagination (future extension).

In fact this principle also applies to information model, try not to develop superset model, intead start from small and then expand (see another post about the fallacy of superset model). One of the architect who worked on UK NHS described this approach of "start from small and expand" in another more fancy term - develop just-in-time model.

Every few months, when you look at the architecture, if you enjoy and discover new potentials e.g you are able to plug in new capabilities without impacting the external facing services, that means you have achieved the above two objectives.

That's beauty and an art.