Reference Architecture

I have had the pleasure of leading a team of architects recently on a migration project. What seemed like a small problem but quickly became a real leadership challenge was dividing up an architecture across multiple architects. I have been on projects with multiple architects in the past but this was my first time leading a team.

In the past on projects where we have had multiple architects, we have used one of the following ways of dividing up the work:

  • Assign a domain to each architect and write an architecture document for each domain
  • Have multiple people working on the one architecture document

For this project we ended up going down a slightly different path and came up with something that I will definitely put in my back pocket and use again. To start the process off we came up with what we referred to as the reference architecture. This was a high level component based view of the architecture. The example of a reference architecture below was evolved by an architect taking a component or service and doing the next level of design for the functions identified.

Despite the reference architecture giving us a great high level component based view of the architecture one of the challenges it presented was providing guidance on what each components did and didn’t do. We spent a fair bit of time putting together a pack that went with the reference architecture diagram to outline for each component what was in scope for it and what was out of scope for it. Despite out best effort we still ended up having quite a few discussions about areas of the architecture and what component was responsible for this. Just something to be aware of if you follow this approach.

Once we had the reference architecture in place we were able to assign services and components to individual architects. To go with this we produced a light architecture document that was completed by the architect and then formed the basis of a review process. The document captured:

  • Problem Statement (from the pack described earlier)
  • Context (Highlight the component on the reference architecture)
  • Issues and Risks
  • Logical View
  • Integration View
  • Dependencies
  • Alternative designs considered

Once all of these light architecture documents were completed the content of all of them was cut and pasted into the central architecture document for the project. This was a relatively painless process with things like standardised modelling and content making it much easier.

This process evolved but looking back on it, it definitely provides a different approach to firstly developing the architecture and secondly managing the workload of a team of architects.


Tags: ,

2 Responses to “Reference Architecture”

  1. Multiple architects but one architecture « What is an Architect? Says:

    […] defining the domains that people will work on. For the recent migration project I was on we used a reference architecture to do this. Once you have the break up of the problem space you then have to deal with how you […]

  2. Migration Summary « What is an Architect? Says:

    […] sharing was the Architecture Review Meeting. At the core of the whole project we developing a Reference Architecture to tie everything back to. Last but not least, we used a technique from the agile world called […]

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s

%d bloggers like this: