Good Architecture Is Needed

My purpose in this blog is to discuss architecture and architecture creation. I am not going to discuss architecture governance, requirements management or project management. They are important topics, but I let somebody else to write about them. I am now focusing on what good architecture includes and how good architecture is created. These viewpoints are based on my learnings when working together with experienced and knowledgeable architects in several architecture projects. I name two of them so that the credit goes to the right address: Kalevi Kontinen and Tapio Ypyä. All the criticism about this writing you can, of course, send directly to me.

With architecture in this context I refer to architecture regarding information systems and processes through which an existing reality of an enterprise or some other community is changed to target reality. According to my experience such change initiatives have a better likelihood to succeed where architecture work has been properly done. And on the other hand, the lack of professional architecture is quite often the reason for failures. This is why, I would recommend that you read this blog before you start to invest considerable amount of money on new information systems – whether they are national patient management systems or perhaps a bit smaller exercise in your own company.

Architecture is created through modeling

Architecture is about modeling a reality. A famous Finnish cosmologist Esko Valtaoja started his latest book ”Kaiken Käsikirja” (“Handbook of Everything”) with a statement ”It is quite possible that a reality exists”. This is a wise statement, because nobody has so far been able to prove that a reality really exists, but here I make an assumption that there is such a thing as reality and I can continue my story. The issue becomes even more difficult, because it is not enough for an architect to model the reality as it is but as it should be in the future. Architecture is needed to implement this change. The starting point for architecture work, i.e. the targets set to the change, are also models. It is, therefore, fair to say that architecture work is about transforming models describing business needs into process architecture, information models and application architecture and finally into technical descriptions and work instructions to implement the change. In any case it is important to notice that a model is a different thing than the reality. One should not fall in the trap of believing that a model is the reality.

It is, of course, self-evident although sometimes forgotten that an architect has to have knowledge and understanding on the piece of reality that she is modeling. It is also important to understand the boundaries of the reality that one is modeling and the essential viewpoints that one should tackle in this specific exercise. The purpose is not to model the entire reality from every viewpoint but the essential points that matter. One definition of architecture is that ”architecture is the 20% of the stuff that really counts”. This is a good definition. One just has to find this 20%. This means that defining the scope for the architecture work is very essential. Once the scope is selected, an architect should cover this problem domain as entirely as possible without leaving black holes in the architecture. A tight scope provides better results than a very large or loose scope.

Business oriented architecture

The role of business oriented architecture is quite simple. It has to transform a business need into tangible architecture models that can be used to guide one or many change initiatives. I have presented this idea in the picture below.

In order to be able to do this transformation, an architect has to understand thoroughly what the target of the change is, and what kind of boundary conditions and fact based restrictions there are. An architect has to recognize the architecturally critical things. These are not necessarily factors that will require a lot of work in the implementation, but factors that may jeopardize the whole change initiative if left unrecognized.

Architecture work – particularly in the problem understanding and target setting phases – is very intensive and interactive between the architects and those who are in charge of the business or are involved in it. It is absolutely important that the communication lines are direct without any middle men. In many cases this communication clarifies and concretizes the business need, which is a good thing for all the parties. My recommendation is that one should nominate a few experienced architects to structure the business problem and the change need immediately when this need arises. Once the architects have analyzed the impacts of the change on processes, information systems and even on the organization, it is much easier to start a program or programs to implement the change. To trigger the architecture work is not a heavy job from administrative perspective, and the work can in many cases be managed by the line organization only. So, there is no need to establish a big program immediately. And one should never try to solve an architectural problem through project management discipline although it might give you the illusion that things are under control.

So, understanding of the business need has to transfer from the need owner to the architect in an early stage of the architecture work. Otherwise the architect cannot transform the business problem into an architecture solution. How does this understanding transfer happen? All legal methods are allowed. Conversation is a good tool, drawing is even better, stories can help a lot. At the end it is about modeling the reality – in this case from the viewpoint of the business need owner. Extensive requirement lists are okay as supporting material, but they are not good for business need definition – particularly, if they have been put together following the principle “the more requirements and the more detailed they are, the better”. These requirement lists tend to reflect a solution to a problem as understood by the authors of the list. It is better to leave architecture work to architects.

Architecture models

In the picture below I have presented architecture models that have turned out to be useful for presenting architecture.

A process model, information model, application architecture and technical architecture are their own entities. They describe the reality from their own perspective. Process models are used to describe the structure of doings, information models describe the concepts and their relationships, application architecture tells about the roles of systems and their interactions when implementing various use cases. Technical architecture binds the logical application architecture and logical information model with the technology, i.e. with the servers and data bases that run in a data center of your own or cloud service provider.

These models have their own languages that an architect should use to describe architecture. It is not easy to define a new language. Therefore, it is better to use languages that are already available and largely understood by others. But, of course, a language is just a language. If you know how to write in English, it does not mean that everything you write is brilliant. But a common language at least gives you the possibility to communicate your brilliant ideas to others – in this case to people who can read English. There is one additional benefit in using formal modeling languages – and this is very important: A formal modeling language reveals the mistakes in your own thinking. It is much easier to fool yourself and others with PowerPoint presentations. But the purpose of architecture is not to fool but to model the reality.

Where to start the architecture modeling? There is not a black and white answer to this. It is in any case clear that it is worthwhile to think about the technical architecture only after the conceptual and logical models are in place. In a similar manner one should not begin from the application architecture although these architectures quite often interest technically oriented people most. My recommendation is that one should start from the processes and information models simultaneously and iteratively. Change initiatives very often deal with business processes, which means that these processes have to be described. But describing the business processes is not possible if the concepts (terms and their meanings) are not clear, and then we are immediately in the information modeling domain. Alec Sharp has written a lot about business processes e.g. in his column series “A Practitioner’s Perspective”. One of his messages is that common concepts have to be defined and agreed on in the very beginning of the initiative. It is worthwhile to read Alec Sharp’s columns.

Architecture work phases

Architecture work can be divided into the following phases:

1. Problem finding
2. Fact finding
3. Solution finding
4. Action finding
5. Acceptance finding and
6. Continuity finding

It is certainly possible to structure the architecture creation phases in some other way, but the framework above has in any case turned out to be beneficial and useful bearing in mind that in real life the phases are iterative and at least somewhat overlapping.

Problem finding and fact finding are particularly important. I have already discussed how an architect has to understand the business problem and the related boundary conditions. This is what the first architecture phases are all about. An architect should not start to solve a wrong problem based on wrong assumptions. Tight communication with the business need owner is necessary and a lot of step work is needed to gather and clarify the facts. The information flow is often so huge that you may feel “consultant distress”. But do not worry; this is how it should be. On the contrary, if everything seems very straightforward in the beginning, you have very likely forgotten something important and then you should worry for a moment. White boards, color pens and a camera to document the pictures are very useful tools in this phase. Use cases should be written and non-functional requirements documented as well.

Gradually you will move to solution finding phase. This phase means brainstorming, innovation and modeling. Use white boards, mind maps, color pens, camera for capturing the drawings from white boards, but also formal modeling tools – at least when your thinking starts to concretize. A good tool to free your own ideas is the so called “stretching to extremes” –method. Do not immediately try to find the golden mean, but take bold steps from one extreme to another, because this thinking may reveal something essential about the optimization task.

When the architecture model starts to get ready, one should map it to the existing processes, information models and systems, and analyze the required changes as a starting point for the implementation. This phase is called action finding in our framework.

As we have learnt by now, architecture work is about modeling. The models should capture your thinking process. But very seldom the models are self-explanatory even for other architects. It is better to describe the models by writing explanatory text. So in the end you quite often produce a Word document. I want to emphasize though that the key thing is the model. Once the model is ready, it is quite straightforward and fast to write the text and put the architecture document together. And of course, you have to produce a presentation package as well. It will be needed in the next phases of the architecture work, i.e. in acceptance finding and continuity finding.

The business stakeholders have been involved in the architecture exercise already from the beginning and there has hopefully been good communication between the architects and the stakeholders throughout the project. The key findings and recommendations should, therefore, not come as a surprise to the stakeholders. Getting an approval for the architecture should be a formality but necessary in any case.

Continuity finding is the final step in the architecture process. This phase is about knowledge transfer and coaching. If the architecture work is already included in an implementation project, it is, of course, very natural that at least the chief designer and process developer are involved in the architecture work, so that they can continue the more detailed design without information breaks. But a good architecture will also serve initiatives that will be started sometimes later. The main principles of the architecture should, therefore, be communicated to the architect community and to those who are in charge of the business. Good presentation material helps a lot in the communication, but never trust on the material only. Face-to-face meetings are needed if you really want to get your message through. And also think about the timing of the communication. People are motivated to get in-depth training if they happen to have a problem where this piece of information helps. Otherwise a more generic presentation is enough.

Modeling is the core of architecture work. Conceptual and logical models are developed first. Then the logical models are transformed to physical. These processes are not deterministic but require creativity and even innovations. If architects succeed in these transformations and produce professional architecture, chances are that the implementations and process deployments will get more straightforward with less hassle and will eventually tackle the original business need as expected.

Heikki Melama

The writer has versatile experience across organizational boundaries in the areas of sales and marketing, product creation, production and ICT. In recent years his interest and passion has been particularly in architecture creation and in the role of professional architecture in managing business and change initiatives.

ite wiki is the it-marketplace that improves it-acquisition and the marketing of it-solutions. Ite wiki is launched at first at the Finnish it-market in Finnish.

PS. A Finnish version of this blog is here.

Architecture expertise in ite wiki

Architecture references in ite wiki

Architecture content in ite wiki

Heikki’s article ”Arkkitehtuuri ja Digitalisaatio”

ite wiki company search

ite wiki reference search

ite wiki content search

ite wiki’s blog