Question

Some context upfront:

Imagine a 200+ developers company finally setting up a more or less independent architecture team/department. The software portfolio consisting of 20+ ‘projects’/applications of varying sizes in production was taken care of by team-leads/technical-leads, who were responsible for and in charge of the projects ‘architecture’ as well.

Out of the necessity to consolidate and control the architecture and enable certain needed large reworks on the systems as a whole, in addition of the all so needed knowledge exchange, the company decided to set-up an architecture department.

• What are the DOs and DON’Ts of such an undertaking?

• Who are the people making up such an architecture team?

• What should be their responsibilities?

• What’s out of their scope?

• What are the useful transition strategies for the company?

• How to prevent those wry looks every time someone even mentions ‘the architecture team’?

• Did your company undergo such a change already successfully?
  Why did it fail?
  Why was it successful?

That’s should not be a discussion on ‘What is architecutre?'(which is very closely related ;).

The really interesting points would be acceptable/realistic maybe even frictionless ways to install such a team, besides of course some warnings regarding battles better not to be even started.

Answer 1

Here are a few issues that should be thought about:

• What is the exact mandate for the architecture team?
• What is the architecture team’s deliverable? A framework, guidelines, implementation help… Or are they just Architecture Astronauts?
• Is this only for applications going forward, or will this be a backport?
• Who will be responsible for backporting? (And we mean budget here…)
• Will there be resources allocated to testing the backports?
• Does the Architecture Team have real muscle, or will management’s will fold when the first group grouses about the 4 months it will take to implement the changes…
• How will you deal with the friction between the individual project groups and the architure team (and there will be friction?). Opportunists will take this as a wonderful opportunity to jockey for position…
• Be aware that this will be primarily a political game…

My friend, you have a tough road ahead…

The first step is to be crystal clear on what the architecture team is supposed to achieve.
Why are you putting the team in place?
Are you trying to unify all the applications, develop a common framework, what?
What is the mandate and the vision for this team?

Whoever the lead on this team better have kick a** interpersonal skills.
It should not be the brilliant coder that can whistle the star wars theme song and make light saber noises… but he should probably be on the team in a technical capacity.

You should probably populate the team with people that are familiar with the majority of the projects. I would be wary of selecting all the current leads, as that might take a big chunk of knowledge from the current teams. And let’s face it, those teams have to be productive while the architecture team comes up with its own deliverables.