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
- 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.