Complexity grows in the world we built today. The key to conquering complexity is understanding, which comes with knowledge. That makes complexity relative and dependent on those who look at it. In practice, a system is complex for some, but simple or simpler for others. It depends on who and education.
We employ specialists, experts, and people with experience. A team of them may cover the whole system. Each expert speaks for its own part though. So, complexity is mitigated as such by committees and meetings. But, the teams are often too large and members still talk in different expertise in different languages.
But, even for specialists the complexity is hard to beat when there is no proper description of the system. It is also the case today that we have lots of specialists, but still no big picture. And, the deeper the specialization the shallower is the big picture for an expert.
How can you manage complexity if you don’t even know what you have today, hence you have no idea what you can achieve? Besides, a target enterprise that fails to consider the current operation and technologies that deliver your products to customers would make your management cringe, to put it nicely.
Hence, what we need is a good description of a system. Graphical at that, because a picture is worth a thousand words. And, one that satisfies most, if not all, stakeholders and experts. For an Enterprise, this is the Enterprise Model or Enterprise Architecture (EA). But, EA is so much seen as IT today that it is hard to mention it without raising objections. How would you understand otherwise how your enterprise works if you have no schematics depicting it?
A high level logical picture of the enterprise would help all stakeholders see the same enterprise picture and components. Once agreed, experts establish responsibilities and depict, to the necessary level of detail, their parts of the enterprise.
How do you project the future states of your enterprise if you do not know how the current enterprise looks? How do you plot your way from point A to point B if you do not know where point A, the departure point is? How are you going to transform the enterprise to its digital future if you don’t even know what you presently have? How can you plan the enterprise transformation if you do not know the current processes and capabilities, systems and technologies to act on their strengths and weaknesses? Ignoring them means to abandon the current processes, platforms and investments. The enterprise evolves incrementally rather than in revolutionary cycles. But, even revolutions re-use existing structures.
Enterprise Architecture would describe that big picture for you in which the parts, depicted by experts according to guidelines, fit in. Architecture helps us, as such, manage complexity since it groups functionality, it encapsulates it in blocks, which can be independently managed like computer chips and it documents the enterprise and reduces chaos by reducing singular developments and platforms. The architect standardizes to reduce diversity and, as such, chaos and creates the high level target picture so that complexity would grow in a controlled manner rather than feeding on itself to result in even more complexity in more diversity.
If the business suggests a new application, of which the enterprise already has a few of the kind, the architect has to analyze it in the EA context so that the proposal does not introduce duplication, then suggests solutions for re-use. In fact, the architect has to automate that decision for others to do, by creating EA principles and standards that are agreed by and enforced by all stakeholders upfront.
The architect establishes the principles of organization, development, technology recommendations, and sets controls in development processes, effectively enforcing an EA governance framework, so that the architecture and its principles are employed. But, the architect does not stall the growth in complexity since this is inevitable, it just renders complexity manageable.
Enterprise Architects have to guide the enterprise evolution to manage its complexity. To do that, they employ the EA blueprint, principles, service orientation, and roadmaps etc. In the first place, the Enterprise Architecture discovers and documents the enterprise to enable the understanding of its structure, functions and relationships. To conquer its complexity, EA reveals and controls the structure of the enterprise. Then, EA facilitates the enterprise simplification through re-design based on architectural standards and rationalizes/orders the enterprise development along architecture principles that hold in check the growth of diversity and tangled connectivity.
Complexity is managed by such architecture principles such as modularisation, encapsulation, decoupling and SOA, principles that group functionality and standardize interactions through interfaces that hide the implementation complexity and technology. Chaos is reduced by eliminating singular applications and technologies and enforcing re-use. The evolution of the enterprise would be controlled by such principles as reuse, de-duplication, technology standards and selection guidelines that reduce chaos by minimizing the unnecessary diversity.
Taking in consideration the big EA picture, the enterprise evolution can be properly planned leaving no function or relation out or allow for functions to be duplicated. The EA enables, as such, a transformation of the enterprise that takes into account complexity management. But, while complexity is inherent in today's enterprise, chaos is what mars the enterprise because it grows by allowing for too many degrees of freedom and singularity that impede proper governance and change. And, the chaos grows indeed in the absence of the big picture, EA, since new developments may duplicate the old in very different ways, repeatedly.
It is true though that today, the current EA knowledge resides in people's minds. Often a strategic transformation starts, unfortunately, from this state of affairs. Mind you, the EA architects of today do IT. In fact, they are just hijacking the concept to the detriment of the future of the EA discipline.
Author: Adrian Grigoriu