I have recently been working on explaining in simple terms and at a high-level what a solution will do and how it will do it for a client. The task has several aims. Firstly, to communicate these key concept to non-technical audience. Secondly, to gain agreement with technical staff as to what the solution is trying to provide and what are the key concerns it must address, without venturing into the vexed issues of how we will implement the solution (different people having favoured technologies, biases and approaches).
The way that I have found works well is to create a conceptual architecture. The best approach to creating a conceptual architecture that I have found is the Visual Architecting Process from Dana Bredemeyer and Ruth Malan. There are several aspects of their approach that I like: the focus on architecturally significant requirements and system qualities; the method of describing of components; the emphasis on providing rationales for all parts of the architecture; and, the explicit use of architectural mechanisms to address cross-cutting concerns.
The conceptual architecture starts with identifying architecturally significant requirements. If you have previously gathered requirements, then this involves looking through them for ones that will have an impact on the architecture. If you don’t have formal requirements then you need to engage with business stakeholders and identify which of their desires and ambitions for the system will impact on the architecture and document those. In my case I had a mixture of both, some formal requirements which didn’t cover all of the desired behaviour, plus some statements of intent. From these I extracted a set of “requirements” that I believed would determine the shape of the architecture.
Once you have identified these significant requirements, you need to identify the desired qualities of the solution. These are the non-fuctional properties that the system must display, such as being usable or scalable. Identifying these qualities often means making trade-offs between different priorities, for instance it is often hard to get a system to both be flexible and have high performance – so which one do you really want the most? For my work, usability was the single biggest driver, with a lack of brittleness being a distinct second, and qualities such as scalability or performance being unimportant.
Describing the requirements and the qualities gives you the basis for creating the components of your architecture. I won’t go into how you decide what the components will be here – that’s a different topic altogether, and worthy of separate treatment. What I really like about the Bredemeyer’s Visual Architecting Process is the way that they describe components. Each component is described in terms of its responsibilities. collaborators and rationale. A component’s responsibilities are those pieces of work that the component executes as part of the solution. Its collaborators are the other components that it works with to deliver its responsibilities or theirs (in SOA speak, you can think of these as being the services that the component provides or consumes). The rationale records the reasons and decisions that have led to the component having the responsibilities and collaborators that it does. Throughout the Visual Architecting Process there is a great emphasis on documenting the rationale for all key architectural decisions and artefacts. I think that this is one of the strengths of the process. It avoids a lot of the second guessing and re-litigation that can occur, and also makes it clear when new information should lead to you changing a decision or architecture.
The final parts of the conceptual architecture are the architectural mechanisms that are to address cross-cutting concerns. These are things such as security that are not components, but that all components must address. In my cases the components needed to all address identity in such a way that users didn’t need to re-enter their details whenever they interacted with a different component.
Following this process, and especially using the Bredemeyer’s template for describing conceptual components (responsibilities, collaborators and rationale), is a great way to make sure you cover off all of the essential aspects of a solution at a high-level and to communicate them to technical and non-technical audiences.
Edit: I have provided a sample of a conceptual architecture here which illustrates some of the key ideas in this post.