What's the hardest thing for a business architect to do? (3/3)

A business architect shows the relevance of needs and requirements by linking them to the strategic context. And that's the most complicated part of an architect's job. Understanding the connection is one thing, but communicating it to developers and designers is another. You don't do this with a few reports describing the functionalities or use cases. You do that through communication. But, as an architect, what should I communicate about the vision or strategy to developers? I don't think this can be achieved through technology, but through communication in the design process.

It is good to first understand how a design process works. I do not have in mind a product investment, but the design of an operation with new technology or tools. It starts with an idea, triggered by new possibilities and the assumption that these will eventually deliver more quality or revenue. During such a process, there is no escaping the minimum number of disciplines that must be involved. First, the idea must be supported by the various executives. The idea is then described in half an A4. What is the big idea? What is the reason? Are there any showstoppers? What are the expected results?

Whatever the idea, in the present time technology (new machine or digital tools) cannot be ignored. In addition, a financial consideration is required and change and implementation processes have become more complex due to fragmentation of processes and operations. In a larger company, five people will be making decisions at the start, and soon more than ten professionals will be called in to prepare the decision. You have to do this methodically if you want to make progress. You can also do it without a method, but it takes much longer and is often accompanied by delays and extra costs because not all disciplines are involved. In such a design process - I would call it transformation cycle - the method and communication between the various disciplines is critical.

It is the main drive of a business architect to use a limited number of concepts to simply explain the connection between the strategic context and the design questions, especially during the decision-making phase. Everyone in design has experienced that at the end of the project two or three persistent issues remain. I have always been able to trace them back to a strategic requirement, and usually that is already half the solution.

So which concepts are needed in a controlled language? In the first blog we already saw that almost all companies are struggling with the first part of transformations in which a strategic context in all its facets has to be done justice in the design of process or technology. This problem used to be called 'business and IT alignment'. Now, the complexity is the alignment of all the fragments in a process. Usually it is easy to come up with the capabilities needed for the future situation. But the complexity always arises in the translation from strategy to capabilities. Which priorities, and which consequences does the strategy have for technology, personal skills, process design or tools that together shape such a capability? The concept that makes the transparency clear for everyone is the concept of 'competence'. Competencies have thus become the link between strategy and skills.

If you are curious about the set of 20 concepts that a business architect needs, check out the Open Business Architecture preliminary standard from The Open Group. Good luck with your next step to becoming an excellent business architect!