In our work as business technologists we experience a constant struggle of architects to establish the correct level of detail in their design work. In many situations, holistic, high-level output seems to be the standard level of detail of the information delivered.
As a result, the output of an architecture design process very often is not so meaningful, as it is either too abstract for people to understand or, when it actually makes it through the first steps of enterprise governance, it doesn’t deliver enough details in order for the executive parties to do their work.
There seems to be a fear of touching the (technical) details, but why?
This is a question that has been intriguing us, as we think of it as a fundamental one that defines the existence of enterprise design and (enterprise) architecture. The impact of enterprise architecture work is rather difficult to assess, as there isn’t “one type of architecture”.
It has to deal with adequately addressing different types of questions by different types of audiences, each with different concerns and needs. We have the impression that the most common method to overcome this challenge is to keep matters high-level.
By doing that, you’re never “wrong” as you offer much space to interpret information, but you’re also never “right” as you don’t give concrete answers to specific questions.
In the end, nobody is really satisfied and we still have many unanswered questions, but at least there will be a common direction that people can hold on to (that’s the motto for architecture that you hear so often: "Creating that pole-star perspective"). If that’s enough for a specific situation, then of course that’s fine, but more often we don’t answer the key questions and the impact of the work will be low.
So, why don’t we try to deliver more concrete and detailed output? It can very well be that the questions asked to us are just not concrete enough. This could mean that we need to become more assertive and (repeatedly) ask the question of "Why".
This forces people to think about what they say a bit more profoundly and helps to create bridges between what people ask and what they actually mean. Architects are very much concerned with designing the “What’s” and sometimes also with the “How”-types of information, but they can only be successful if they understand the context and the drivers behind the questions. They should do this by creating bridges and relationships between pieces of information (Why-What-How). We could call this "Clarifying the purpose" as a way to deliver more meaningful content and creating more impact through design, using detailed information as an enabler.
Another reason is the difficulty that many people seem to have with conceptual thinking . This might sound strange to you, as we are talking about details which logically are the opposites of concepts, but this is not true. In order to define details one needs to use a kind of "network" thinking. Making connections between one element on a specific granularity level and one or several other elements on different granularity levels, helps to get to the right level of detail that will help to design meaningful products, that will actually help to solve the problem. Paradoxically by adding detail, you will see the full picture better.
There are also more behavioral or even "political" reasons to avoid detail.
Staying on the descriptive and holistic level, framing stuff, and not going to the prescriptive details, will help to stay away from things such as ownership and responsibility. You cannot be caught for things you didn’t say. This is the actual fear for details – to be held accountable for what you designed (yes, architects, we mean you). We think this kind of behavior is not seldom seen amongst architects.
And if you ask us, this is a serious problem, as this is the one and only real responsibility they have. Try to improve the quality of your input data as much as you can, but in the end, focus on the quality of your design. You can’t boil the ocean, but you can make sure that what you deliver makes sense.
At this point you might think that we are addicted to details, but that’s not completely true.
We are fans of adding relevance by using enough details, in function of a specific context and adding relationships between pieces of information, so a design becomes meaningful.
In practice this means that we need to ask more (and better) questions, think more about the real (latent) needs and add more useful details. That’s the essence of architecture – enabling decision making by understanding the bigger picture better, a bigger picture that is based on profound analysis–and details.