Architecture – Just Who Are We Talking To?

Photo by Jason Goodman on Unsplash

I’ve spoken about the technical aspects of system architecture before (see Architecture and Agile – here), but there’s always more to discuss when it comes to architecture.

I’ve recently been reviewing a large system architecture for a client, which led to a conversation on the nature of architecture itself, as distinct from the technical design of the system.

When you start down that particular rabbit hole, you always have to frame the conversation by defining what architecture actually is. There’s usually some variation on the following themes – System Architecture answers two questions:

1. Is this what we’re going to build?
2. Is this going to work?

I like these points, but it’s easy to form the opinion that this is advocating some form of ‘Big Up-Front Design’. It doesn’t, but every project needs some form of shaping, which is what your architecture should provide. I didn’t decide these by the way, this is a sort of consensus opinion on a review of the internet (possibly not the best source I grant you).

But who is asking the question, and what are they actually looking to discover?

Architecture’s Many Audiences

First, lets accept that ‘Architecture’ is the start of the solution phase of a project. It captures ideas and is a means of communication. Even if you’re only a team of one, it is an ‘aide memoire’, where you’re communicating with yourself.

With that in mind, let’s consider who the architecture could be communicating with. I think there’s four different potential audiences. Each is looking at the same system, but each has a different perspective requiring the information to take on different forms.

Development Team & Technical Team

This is the most obvious audience, and let’s be frank, often the only audience that architects attempt to speak to. This is the least challenging audience for the architect to address, as the relationship is to a greater or lesser extent dictatorial; the architect is telling the technical team what they are going to do. You can tell a lot about the quality of the architect by how they deal with this communication.

The nature of the communication here should include standards, principles, processes and at at least component level designs. You should expect to see lots of technical diagrams, likely in the form of UML diagrams of some type or another. There are any number of diagramming models – C4, UML or ArchiMate to name a few – or perhaps Entity Relationship or Star Schema designs for databases that serve as templates. You should expect to see some supporting communication on the supporting standards and principles of the architecture.

For the development and technical team, the mark of a great architecture is the one that furnishes them with a good view of the concepts underpinning the system being developed, along with sufficient information to allow the team to make better design decisions.

Internal Stakeholders

This should be a fairly common audience, but the degree to which architects deal with internal stakeholders is variable in my experience. Architects should deal with the internal stakeholders all the time, in my opinion, but this doesn’t always happen. This conversation can often be delegated to a product owner or similar, which absolves the architect of the responsibility for maintaining a line of communication with the stakeholders.

The internal stakeholders tend to be the commercial side of the business and can include sales, marketing, finance, operations and so on. In short, despite what the technical staff might allow themselves to believe, these people understand the business domain better than anyone. The architect and the technical team should be working in conjunction with these other teams to produce a system that meets their needs.

The nature of the communication here is generally conceptual rather than technical, incorporating high level connections to other systems, and designs that demonstrate the capabilities of the system. One of the mistakes that I see time and again is presenting, for example, C4 models to a non-technical stakeholder audience. They meet almost none of that audience’s needs, and, for me, scream that the presenter isn’t really interested in imparting any real information. For this audience, it’s important that the architecture presented establishes a bridge between what they know of the business domain and how the system is satisfying those needs without requiring them to suddenly become deep technologists.

Partners and Integrators

Partners and Integrators is a growing commercial target for companies. The rise of the API first approach has opened new markets and new opportunities for business expansion that previously may not have been considered.

Partners and Integrators become external stakeholders to the platform, and sit at the intersection of your internal stakeholders and your development team. Typically the audience will comprise both commercial and technical people, requiring both to be addressed.

The nature of the communication here is much more of a balancing act. On the one side, there is a need to provide context for the integration. This requires exposing not just conceptual information, but, where relevant, deeply technical information that is necessary to complete the integration. On the other side, the partner is not part of the company. There are certainly going to be aspects of the system, or the company as a whole that is confidential and must be protected.

The final consideration with Partners and Integrators is that the architecture is part of a broader sales pitch. It won’t be enough for the communication to be accurate, it’s will also need to be engaging.

External Audience

Finally, there’s the external audience. Architects, particularly senior architects or CTOs are frequently called on to deliver technical presentations to a public forum.

The external audience may be prospective customers, or investors or maybe simply meet up groups or technical seminars.

The nature of the communication in all of these cases is simple, present the technical aspects of the company in the best light, engage the audience and build some excitement. Depending on the nature of the audience, the information will be both conceptual and technical. If the audience is an investor, they will want to get some idea of the intellectual property that the system generates, if its a prospective customer, it can include questions on security, data governance or numerous other aspects of the architecture. Finally, for industry groups and seminars, it tends to be highlighting some specific element of the system that is of particular interest to that target group.

Frameworks, Models and Communication

The major enterprise architecture frameworks, TOGAF, Zachman, FEAF DodAF and to a lesser extent COBIT all discuss Stakeholder engagement, but mainly from a requirements and project management perspective.

The modelling approaches, C4 and Archimate particularly, suggest that they are suitable for all stakeholders, but I’ve found that to be at best inaccurate. These are technical styles of communication, and whilst one might argue that architecture is a technical process so the challenge can’t be avoided, the job here is not to educate the audience on how we’re going to communicate, but rather to convey the information in a way that best suits their needs.

In short, don’t present C4 models to a non-technical audience in general, unless you want to spend a large amount of time explaining what C4 is, and then what UML is.

Conclusions

Many architects can shun the communication elements of their role. The internal engagement with developers and technical staff gets the most attention, but as communications move towards stakeholders or non-technical people, this responsibility is regularly delegated.

Organisations that are best aligned to deliver their outcomes have a close engagement between the commercial and technical elements of their business. Architecture is heavily responsible for building this bridge and must build the tools to support this communication. This often requires straying away from the formal frameworks and models and into a more engaging style of communication.