Jiri’s Notepad

This is a third post in the series on collaboration.

Organisation of work and work teams provides a powerful tool to enable alignment and collaboration between various stakeholder groups. The problem with organisation structures is that they are very often context specific and so you get as many different organisations as there are projects. Even though the particulars can vary, there are some common principles that apply across the context. The approach that seems to be working in regards to collaboration is to create blended cross-functional teams involving different stakeholders.

How such teams look like and how they work depends quite a lot from what viewpoint you look at and stage in the lifecycle. If you are building an EA organisation, or if you are a large programme in the early stages of the lifecycle, your organisation and the associated process will look a bit like this:

Architects Roles

During the early programme phases, the most sensible way is to organise architects by business stakeholder community. In this approach, you divide the problem domain into business segments for which you allocate responsibility to individual enterprise architects in your. This arrangement helps develop architects relevant expertise in the target business domain and also personal relationships with the key business persons. In this setup, business is the ‘customer’ but in some context also the first point of contact for development of business solutions.

Apart from the business managers, business and enterprise architects will probably work with solution architects. Solution architects initially assist enterprise architects in identification of technical solutions and in later stages work closely with delivery teams to scope out delivery projects. Whereas enterprise architects activities are mainly business-facing, solution architects focus mostly on solutions and projects and so probably the best way to allocate responsibility to solution architects will be by project or project portfolio. This will promote a sense of ownership over a concrete piece of work with identified business value and offset the occasional tendency to withdraw into an ivory tower.

Although I do believe there is a great value in architects being multi-skilled generalists, at a certain point during the programme an architecture team needs to be staffed by folks who have more specialist skills. E.g. would you as a generalist architect want to bet your career on the fact that middleware configuration you are putting in place will be support tens of thousands of concurrent users of your incredibly popular and important system on the first day of your go live? Do you really understand all intricacies of data semantics of the three businesses that are merging to tell where to engage the business? Are you sure you want to spend the time to work out what are the limits of the enterprise provisioning infrastructure to allow various systems use the same set of user credentials and authorisations? That’s when architects focused on domains that require high degree of specialist skill come useful.

Refining the Model

By now you are probably thinking: “All this looks interesting, but frankly it will not work in my case because of [fill in whatever reason]. And I don’t have money to spend on a dozen of architects�. Well, the chances are you probably do not need all the roles mentioned. What I described above is generic and probably biased towards big organisations. In reality you will need to pick and chose your staff depending on the focus of the programme:

• For an ERP programme you will probably need a few application / solution architects who will know all nooks and crannies of the software package, someone to look after integration, few people to look after the infrastructure and someone on security;
• Smaller programme may need only an enterprise/solution architects;
  On a data-heavy records management programme you may a combination of solution architect with few data specialists may be the right thing;
• A technology programme architecture team will probably need one or two enterprise architect, handful of infrastructure architects and some.

Second thing you need to take into account when customising the generic model is the project / IT organisation sourcing model. The above assumes that you either have your IT delivered in-house, or perhaps you are using multi-sourcing. In both cases you need to have strong in-house capability. In case you outsource development or operations, some of the architecture roles are likely to be delivered by your supplier, so you will probably have to scale down.

Conclusion
I am going a bit of off tangent here, so it may be better to finish this post and come back to my main points:

• To get a high performing architecture team that is adding value to the business and delivery, you need to get the right blend of people to cover various aspects of the probalem and solution domain.
• Secondly, when thinking about organising for collaboration, you should set up roles and responsibilities in such a way that they foster personal relationships with the most important stakeholders and development of subject domain expertise.