By Simon Field, Senior Enterprise Architect at Ardoq
I’ve often heard enterprise architecture teams complain that they are continuously fighting a losing battle. They’ve been asked by the CIO to build a model of the IT estate – documenting applications, how they are deployed, what technologies they use, how they link to each other, by whom they are used, and for what purpose. In short, how the IT estate looks, and how it supports the operation and strategic goals of the organization. But, I am asked, how can a handful of people document hundreds of applications that are evolving faster than they can draw?
Perhaps they shouldn’t even try, because the CIO will typically lose faith in them long before they’ll ever come close to catching up. Is this a reason why Enterprise Architecture (EA) initiatives so often fail to take off?
We need to take a different approach. One that can harness sufficient resources without imposing an impossible burden on the organization. And one that will be self-sustaining, and won’t immediately start to decay as soon as it is complete.
In other words: Enterprise Architects should stop trying to build their own models, and engage a wider audience in that endeavor. Andrew Koenig has described architecture as “a kind of abstraction” and said that “Abstraction is selective ignorance” [1]. There has been a resurgence of interest in documenting solution architectures, and doing so in a way that is sufficiently transparent to serve many different stakeholders. A good example of this is the C4 Model approach [2], which proposes four levels of “selective ignorance” to suit the needs of different stakeholders, among them enterprise, business, solution, technical and software architects.
In this article, I’ll explore how we can exploit the resources of autonomous development teams and their solution architects, and the abstracting power of the C4 model approach, to crowdsource a maintainable enterprise-level view of the IT estate. As we’ll see, the result is a win-win, with great documentation to support the teams developing and supporting solutions, and an enterprise landscape view that everyone has a stake in maintaining. And the enterprise architects can actually get on with the job they were hired to do!
Drop the solo modeling heroics!
Few development teams continue to believe the myth that their code is sufficient documentation to enable them to adequately support their solutions over time [3], [4]. The C4 model diagram approach brings consistency to the documentation of a logical view of a solution, with four different levels of abstraction to satisfy enterprise and business architects, solution architects, software architects and development engineers respectively. It is becoming widely adopted by development teams as an ideal way to communicate the logical architecture of solution designs. With a suitable architecture platform, this approach can go beyond maintaining a set of related diagrams, to maintaining a single common model viewable at different levels of abstraction and from different perspectives.
One key benefit of adopting an architecture platform, and having different development teams contribute and maintain their designs in a shared model, is that higher levels of abstraction can gain a wide-angled view of the resulting picture. At the context level, the view becomes enterprise-wide, with an abstracted map of the entire application landscape, and how it is joined up, both from an IT perspective, and to its consuming organizational units, revealing its contribution to business products and services, value streams and business capabilities.
The abstracting power of an architecture platform, such as Ardoq [5], combines with the consistency and integrity of the C4 model approach to enable the enterprise level view to emerge automatically from the distributed efforts of the organization’s solution architects. We can eradicate the frustrating and, ultimately, fruitless attempts by enterprise architects to separately document the entire IT estate.
Documenting the solution architecture
We can illustrate this by extending the example given in the C4 model website [2]. Let us imagine that BigBank.com’s new AI development team has added a SmartChat application to its Internet Banking System. The solution architect included a level 2 Container Diagram [6] of the application in their High Level Design document:
Subsequently, the lead software designer added their more detailed level 3 Component Design [7] of the Dialog Manager part of the system:
The solution architect added a deployment diagram outlining the cloud-hosted services and technologies that the solution will leverage:
Instead of these diagrams being independent but related drawings, they all form part of a single shared model. The software designer is able to pick up where the solution architect left off, adding the detailed software component design to the higher level breakdown of the solution that was agreed by the team earlier. Each “diagram” is actually just a constrained visualization of the same model from a different viewpoint, with the structure, layout and labels following the simple guidelines of the C4 model approach [8].
We can see that SmartChat has been designed for inclusion in both the Internet Banking System’s web page and its Mobile App, and that Customer Service Staff need to access chat history. By reusing existing elements (roles and applications and their constituent modules), the solution architect has identified the points of integration and dependencies between the SmartChat solution and other people and business systems.
Changes here can have wider implications: other teams may need to amend their software; customer journeys may change, sensitive information may be passed across application or even organizational boundaries. Developing solution architectures while sharing a common model helps to maintain the autonomy of different application development teams while identifying necessary points of interaction and dependencies early in the development.
Gaining a landscape view for free
The same solution can be viewed, using the same model, at an even higher level. Adopting a wide-angle lens, and enforcing a degree of “ignorance” on the collective knowledge of all solution architects, we can view a level 1 landscape diagram [9] from the viewpoint of the customer, rather than an individual solution.
We’ve effectively joined up the work of all the application teams and their solution architects and created an enterprise-wide view without even trying! As individual systems are changed over time, provided their solution and software design views are updated, the enterprise-wide view will automatically follow. Proposed changes can be viewed at each level of abstraction – small changes might only impact the level 3 Component view, while more significant changes will have a wider effect that might have implications far beyond just a software change, requiring the attention of business product owners, data custodians and customer service designers.
EAs can do their day-job at last!
Have I just eradicated the need for enterprise architects? No, but by combining the abstracting power of a modern EA platform with the consistency and integrity of the C4 model approach, I have removed from their workload the Sysyphean task of hand-crafting an enterprise IT model and replaced it with the “collective ignorance” of an army of supporters who will construct and maintain that enterprise view out of their own interest. Guidance and encouragement (and the right tool!) are all that is required. The model will remain consistent with the aggregated truth of all solution designs because they are one and the same model, viewed from different angles with different degrees of “selective ignorance”. And the EA team will at last gain the time and space to leverage the model to do what they were hired to do in the first place: informing key business decisions and managing continuous business change with the valuable and insightful knowledge they are now able to bring to the table.