We put knowledge to work

By combining hard and soft skills and fostering cooperation

  • Full Screen
  • Wide Screen
  • Narrow Screen
  • Increase font size
  • Default font size
  • Decrease font size


E-mail Print PDF

On architectures (Enterprise, business, IT, SOA, and solutions)

The first time that an IT professional showed me a plan of IT architecture, he shared a map of a plant on an A0 format (1 square meter). This map showed buildings with their IT infrastructure. This included the location of the servers, which software was running on which server, and even the cable layout. This map of IT architecture helped the poor man find his way around the servers that he had to administer. The plant in question was very big. His physical condition also deserved a lot of respect, because of this huge map roll that he had to carry everywhere he went, to save himself from getting lost. Compared to the Michelin guide you would use in a car, this man’s IT architecture map was hell (European city planning still seems to be popular as a framework for IT architecture).

I have been shown many similar drawings since then. Each time, the resemblance to a “still life” painting has struck me more. No measurements are given, so there is no sense of dynamics or scale. With a bit of luck, the colours are balanced and the representations might embellish the walls of a boring office. More often, however, they are hung on the walls of canteens. Canteens are places that are decorated so that workers will leave them as fast as possible in order to continue their work. Architecture have contributed considerably to that sense of functionality. Buildings have become more and more diverse with more and more landscapes, layers, perspectives, and views. Just as in art, we have seen realistic representations of infrastructure moving to more abstract representations. Likewise, just as with abstract artists, it seems inappropriate to ask what the piece of art represents. The answer to this question for IT architecture is also probably similar to the answer to an artistic question: one sees in the representation what each spectator wants to see.

Now you’ll ask: but was that when you started to read about architectural frameworks?

Well, indeed, after a while I did. But what I read did not put me at ease. It seemed that the layers of representation on these plans may have been standardized but they were still artificial. Strangely enough, these artists began by slicing the organisation artificially and then used a strange sort of “hocus pocus” to convince people to use the same tools to re-integrate the slices again.
Next, they “helpfully” introduced completely new vocabulary, which succeeded in confusing pragmatic people even more. I thought that I had seen self-perpetuating problems before, but these guys were the extreme. Standardization institutions, whose bread and butter it is to produce as many standards as possible, would have jumped for joy on the train passing by.

So at this point, my perception of enterprise/IT/business/software/SOA, and indeed any IT architecture, was that it was nice hype, that it had been promoted successfully, and that it ensured a lot of consulting revenues.

Until I met Ivo.

Ivo’s PhD work was on the subject of enterprise architecture (EA). He has original viewpoints with pragmatic approaches. More detail of these can be found at http://www.strategicstructures.com/?p=441

Strangely enough, he agreed with my objections to IT architecture. We had many diverging opinions in lots of matters, but the fact we agreed on this that was surprising.

Of course, I was intrigued to learn whether the “hype” that I have described could be of any use in solving the problems that really matter. Why was Ivo not angry when the object of my doubt was so close to what had been his daily concern for years?

It would have been stupid and stubborn of me not to take this opportunity to learn from a specialist.

Instead of abstractions from reality, Ivo focuses on the core of an organisation. Instead of being like a dead painting showing abstract concepts, an organisation can be represented by familiar concepts that are interrelated, so that their purpose is unveiled. Instead of layers of abstraction, layers of detail can be shown, so that the level of concrete applicability increases with each drill down. The architecture can be represented in three “languages:” a concept map, the narrative story of the organization, and the interoperable machine-readable .rdf and .owl files.

This is how I developed my appreciation for enterprise architecture (EA). This occurred to such an extent that today I am convinced that certain important matters of concern can only be tackled seriously through enterprise architecture that is applied in a pragmatic way.

What are the matters that I feel are of real concern?

  1. Tackling the organized inefficiency of resource usage;
  2. The lack of knowledge of the nature of products, including services;
  3. The lack of knowledge about the production of products/services.

These three concerns are interlinked and many lower-level issues are derived from them.


  • How can we state that we use our resources efficiently if the process costs and/or time and/or quality can be improved?
  • How can we state that our IT resources are efficiently used if there is no re-use, no interoperability, and no capabilities registered for those systems? Which processes do they support? Are those processes actually implemented and can they be improved, or are we being inefficient in our use of IT support?
  • How can we state that we have the control over risks if the services/products are not described, registered, and categorized in a way that fits the purpose of effectiveness and knowledge? Likewise, it is meaningless to claim that we have undertaken risk control unless there is a description of the processes—how the services/products are produced.
  • How can we state that IT services are efficiently rendered if a battery of different syntaxes is applied in the communication between “business and IT”? There are seven so-called UML diagrams, which seem to help in translating business requirements. However, given all of the levels of translation between the business and the final IT application, it is not surprising that the IT application that results often has "unexpected features".
  • How can an organization have a consistent approach to any individual client without some form of master data management in place?
  • How can we ensure that we have understood everything sufficiently and have things under control if we do not have a public vocabulary, and instead force every stakeholder to have his own vocabulary, semantic model, or even architecture in mind?
  • EVERYTHING that happens in the service industry or public service, from the registration of an official to the attribution of a grant, is related to information. The attribution of a grant, for instance, is done by passing information to a financial institution in order to transfer an amount from the bank account of the organization to the bank account of the receiver. Even the transfer itself is only information. How can we properly communicate, either internally or externally, if we do not reveal how an organization functions, including its main concepts and the relations between them? This needs to be the basis of any information system.

The specific EA approach that is presented by some enterprise architects can help to solve these and many other questions.

Therefore, I am convinced that it is worth spending time trying to understand the specific approach to Enterprise Architecture that has been proposed by Ivo. If we will pause to consider this option, I am quite optimistic that Ivo’s approach may be adopted more widely.

A link to the semantic description of one version of an enterprise architecture is here, the website of Ivo is here.

Related services: management coaching

You are here Home