social objects

Architecture Work Products as Social Objects

Peter Cripps architecture , ,

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.

Making Smart Architecture Decisions

Peter Cripps architecture , , ,

Seth Godin whose blog can be found here, posted a wonderful entry called The extraordinary software development manager yesterday which contains some great axioms for managing complex software projects, the last of which is something I wish I’d written! Here is what it says:

Programming at scale is more like building a skyscraper than putting together a dinner party. Architecture in the acquisition of infrastructure and tools is one of the highest leverage pieces of work a tech company can do. Smart architecture decisions will save  hundreds of thousands of dollars and earn millions. We’ll only make those decisions if we can clearly understand our options.

As I’ve said elsewhere architecture decisions are one of the most crucial social objects to be exchanged between stakeholders on a software development project. For a very thorough description of what architecture decisions are and how they can be captured see the article Architecture Decisions: Demystifying Architecture by Jeff Tyree and Art Akerman. However you don’t need to make every decision to such a precise level of detail. At a minimum you just need to make sure you have looked at all options and assumptions and have captured the rationale as to why the decision was made. Only then can you move forward reasonably safe in the knowledge that your decisions will stand the test of time and, as a bonus, will be transparent for all to see and to understand the rationale behind them.

Good architecture decisions will form part of the system of record for the project and the system itself, once it is built. They will allow future software archeologists to delve deeply into the system and understand why it is the way it is (and maybe even help fix it). They also help newcomers to the project understand why things are the way they are and help bring them up to speed more quickly on the project. Finally, and possibly most importantly of all, they stop others making different decisions later on with possibly great financial implications to the project. If you can read and understand the rationale behind why a decision was made you are less likely to overturn the decision or ignore it all together.

Social Objects as Instruments of Architecture

Peter Cripps architecture ,

According to Hugh MacLeod a social object:

is the reason two people are talking to each other, as opposed to talking to somebody else.

also:

social networks are built around social objects, not vice versa. The latter act as “nodes”. The nodes appear before the network does.

In discussions around architecture there can often be much confused talk around what is needed, what an architecture looks like and what decisions need to be made in order to make it so. There are three useful architectural social objects that help cystalise our thoughts and  allow a network of related artefacts to be created. These are:

  • Use Cases or Scenarios – Illustrate what I am trying to do via real-world examples that use human actors to illustrate what we are trying to achieve.
  • Architecture Overview – The main architectural elements (components) that the system is comprised of.
  • Architecture Decisions – What decisions am I making, what options did I consider and why did I choose the ones I did.

These social objects seem to apply to all levels of architecture from the smallest application to the largest enterprise architecture. Of course they are by no means all you need but serve as a pretty good starting point for all that follows.