The other day I had a chance to catch up with Alec Sharp as he was visiting Wellington. Alec was here teaching a course on advanced business process modelling for Software Education, and we managed to catch up. I know Alec through twitter and we have had a number of conversations, debates and arguments virtually, so it was great to finally talk to him in person over a beer at the Little Beer Quarter in Wellington. We had a far-ranging discussion of matters as diverse as beer, history, philosophy, process and data modelling, software development and pacific islands.
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.