How does a Business Architect work (2/3)

In the previous blog we argued that the business architect can make the connection between the strategic ambition and the operation of an organization, and not least do this in such a way that it is translated into the technical infrastructure. The other architects do this of course, but a path has to be cleared to achieve this. And that is where the business architect has a responsibility. How do I communicate the intention of top management so that the process designers, the information analysts, the application developers and IT engineers can get to work effectively?

A business architect likes two things: understanding how to achieve the goals of an organization, and communicating a lot. Every business initiative starts with a desire to achieve something or to solve something. But, how does he communicate this to the other disciplines. There are a few key concepts invented for that. These concepts are necessary to connect the abstraction levels in an organisational design, and to keep the designs manageable. The business architect actually translates the large context - read: the vision and strategy - into a number of small contexts - read: the capabilities, by some called business function. The small context is then sufficiently clear to be translated into people, processes, technology and information needs.

We did this for years, but it proved insufficient. Around 2010, there was dissatisfaction in the international working group at The Open Group. The gap between strategy and capabilities was too large. Apparently there was something intangible that created this gap. And that intangible gap is the mechanism by which you tell your colleague what the collaboration between those capabilities looks like. That's what the concept of competencies was invented for. Not the competence of a person, but of an organization. If you want to understand this concept properly, the article in the Journal of Enterprise Transformation is useful. The competences of a company are the mechanisms that enable the interplay between capabilities and thus the realization of strategic desires. This was the missing link for a mature profession. It is very useful to practice this concept during the training at the academy. It helps you as an architect to communicate how abstraction levels are connected and what the added value of interdependence is.

Take IKEA. The ambition of this company was 'Supplying design furniture on a large scale at an affordable price'. This means putting a lot of money in design, but mass production also makes demands on the design, and at low prices it requires efficiency in delivery. Eventually this led to interdependence between the capabilities Design, mass production and the do-it-yourself warehouse. In turn, these capabilities led to demands on volume and growth strategy. Try to discover these interdependencies in your own organization.

In the next and final blog, we'll give a look at the importance of a common language for communicating between the different abstraction levels and domains in a design.