Creating A Conceptual Architecture

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.

Advertisements

9 Responses to “Creating A Conceptual Architecture”

  1. Hi Doug,
    I read your post a few times over and looked at the Conceptual Architecture page you linked to (which interestingly had no sample diagrams, which I thought a Visual Architecting Process page might have had :)).

    I would suggest that a few sample diagrams would work fairly well with giving readers an understanding of what you describe.

    I do somewhat struggle to understand what makes this approach much different from any other often non-formalized way of creating a business oriented view as the goal is the same: To describe to the business on an appropriate level how their business requirements are met in a given solution. With the emphasis put on “appropriate level”.

    I must admit I only read briefly the content of the link you provided, but with a short overview was very difficult to see why this was something that they could claim to have invented (for the lack of a better word).

    Please note with my comments above that I have only spent about 10 minutes reading about this so can’t claim to have the understanding and expertise with this approach as I assume you have gained through practical implementation of the process. So very much a “first impressions” comment 🙂

    In any case, a sample diagram implementing this method would probably clarify the post significantly to allow for a quick validation of correct understanding by us readers.

    Cheers

    Kalle

    • Hi kalle,

      A couple of things about the Visual Architecting Process. (1) It seems more practical and results oriented than other frameworks I have seen (e.g. TOGAF, Zachman). (2) The conceptual architecture is just one step in the overall process from the highest level (vision and principles) through to executable architecture, and it’s this process that is more “their invention” (though the VAP is a synthesis of best practices, so none of it will be completely unfamiliar).
      You are right, however, that a picture would be a good idea – I was thinking of adding a sample conceptual architecture as a separate post.

  2. Verification versus validation: Verification sets out to discover whether a product meets the stated requirements and needs. Validation sets out to discover fitness for purpose and to uncover unstated requirements and needs. Putting an architectural description in front of a customer that they can understand is a vehicle for validating the architect’s understanding of user needs. It gives the customer an opportunity to ask those uncomfortable questions that uncover unexpected ignorance of the customer’s real requirements.
    I am not particularly familiar with VAP, but it looks to be more of a systems engineering approach than a software engineering approach. Systems engineering has made a number of attempts to influence the software world, and the software world has made a few attempts to influence things back. Overall I think that a systems mindset that focuses at all levels on why components exist, what they are responsible for, and what is most and least important about the components is a helpful part of the architect’s toolkit.

  3. Even though I like your post and understand what you are trying to accomplish, one nagging question remains: Why would we want to explain architecture to non-IT people at a conceptual level? People need a solution that works, they do not need to know what’s under the hood. Think about it as a car: I do not need to know the mechanics of it, I simply want to drive it. And when I want to get a feature, say, from 0-100 in less than 5 seconds, my dealer tells met that’s not possible. I do not need all the details to accept that answer, he is the expert. So why would the business need all the underlying IT-details instead of trusting that their IT-experts know their stuff? After all, that’s what they are paid for. I would really like to know your thoughts.

    • Hi Anita,

      This is a great question, and well worth addressing. The key thing here is that the conceptual architecture is not really the technical “how” of an architecture, it is more of the “what” and the “why”. What I am trying to achieve with the conceptual architecture is outline what the system will achieve, and break it into “chunks” that logically address both the functional business desires (i.e. the requirements) and the non-functional business desires (i.e. the qualities). Let’s take your car example. Say you (the business owner) want a car that is safe and reliable but don’t care about speed or style (qualities). You also want certain features, it should get you from A to B, an MP3 player and the ability to regulate temperature (i.e. functional requirements). As a car salesman/mechanic/designer my conceptual architecture says we give you an engine, which has the responsibility of getting you from A to B, and demonstrates the quality of reliability (but not speed); we have a cabin which has the responsibilities of playing MP3s and regulating temperature for passengers, and demonstrates the quality of safety (but not style!). Once both you and I agree that this is a good way of meeting your needs, I can then look into exactly how I will meet those needs with a technical architecture. This might include what kind of engine I will use, do I use ABS brakes, side airbags etc. This last part is where the IT details reside, and where the business owner should trust the IT staff – because we have agreed at a conceptual level what you want. You still might want this verified, but we will do this by tracing the technical details back to this agreed conceptual architecture, making further conversations much easier.
      Does that answer your question?

      Doug

Trackbacks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: