As architects we clearly need to describe the architectures we are creating. Sometimes what we are trying to describe can be fairly abstract and it helps to have a common and well understood set of work products to describe and facilitate an understanding of the concepts we are trying to get across. I’ve previously talked about how architecture social objects can be used as a communication device that generates conversation and action around the object. This blog post by David Johnson suggests that all social objects have three things in common, which I think further reinforces the usefulness of a well thought out set of architecture social objects. According to Johnson the three things social objects have in common are:

1. Conversational: people want to talk and have conversations with other people connected with the social object.
2. Brings People Together: people want to be around other people that are connected with the social object. They feel part of a community, that they belong with each other.
3. Talk Worthy: people feel the desire to tell other people, who may not know about the social object, so that they, in turn, become part of the community.

Over time I’ve discovered there is a core set of work products that form the social objects which bring people together and can act as conversational pieces for architects to talk about. This is especially important when you have to quickly create a (partial) architecture that shows how a number of software components (both bespoke and off-the-shelf) can work together to address a set of requirements.

It’s especially useful to do this when there is little time to create such solutions, as when you may be responding to an invitation to tender (ITT) from a client for example. At such times requirements are often even more ill defined than usual and time is of the essence if you are to get in your bid by the deadline. There is usually no time for the niceties of ‘proper’ work products; the end game is to create physical view of the architecture which can be used for financial costing and other sizings. However you still need some level of discipline and process if you are to create something that can be understood by everyone. In other words you quickly need to come up with a set of architecture social objects.

Here then is a seven-step approach that is useful for creating social objects that can be discussed amongst architects and stakeholders. All of the social objects in what follows are stripped down versions of the work products we define in The Process of Software Architecting.

1. Use what requirements you have and create a System Context identifying key actors (especially other systems).
2. Try to break down what requirements into functional areas, ‘Customer Management’, ‘Facilities Management’, ‘Diary and Calendar Management’ etc.
3. Draw an Architecture Overview showing the functional areas from 2) as subsystems/large-grain components.
4. Use the Architecture Overview and match against known patterns to derive the technical subsystems/components. In particular this step should account for any non-functional requirements to qualify your choice of technical components.
5. Capture Architecture Decisions as to why you chose which components you did.
6. Create Change Cases that you can play back to the client as a way of validating the approach and further establishing what is out of scope but which the architecture can support.
7. Validate the whole thing in an Architecture Assessment. This will be used to identify issues and risks associated with the architecture and recommend actions and mitigation strategies to address them.

Whilst I’m not suggesting the above is in any way a substitute for a full and rigorous architecture process it’s definitely better than not following any process and will at least create a basic set of those architecture social objects that can be used to have the right conversations.