Coding the Architecture - authority tag

Mind the gap again

Mon, 04 Aug 2008 16:12:46 GMT

I did some technical consulting/due diligence on a large software development project recently where I'd been called in to look at how the project team was dealing with some of the non-functional requirements. I'm not sure exactly how large the project team was, but it was somewhere over 50 people and the project itself was subdivided into a number of smaller teams, where each team was responsible for looking after a small subsystem within the overall architecture.

The summary of my review was that very little thought has gone into the non-functional requirements and that retrospectively performing some non-functional testing *could* expose a whole host of problems that are expensive to fix. One of the reasons for the lack of work on the non-functional requirements is that each of the subsystem teams basically doesn't have an architect. Instead, they have a Technical Project Manager and a Technical Team Lead, with definitions as follows (I'm simplifying this a little).

Technical Project Manager : a generalist rather than specialist, and somebody that has a technology background but doesn't necessarily understand technology in great detail.
Technical Team Lead : depending on the team, this person is either similar to the Technical Project Manager but working at a lower level of detail, or it's the lead developer.

This sort of team/resource profile isn't actually that uncommon and I see many project teams that are organised in this way. In essence, teams get in a Technical Project Manager because they think people in this role can successfully undertake the project management *and* architecture roles on the project. Unfortunately, my experience suggests that this isn't always the most successful approach.

In I Need a Technical Project Manager, Johanna Rothman talks about the dynamics of taking on both the project management and architecture roles. Specifically, she says that one of the roles usually has to give way, and I agree. Coming back to the project I was reviewing, the basic problem was this - the Technical Project Managers didn't have enough experience of dealing with the architecture aspects (including NFRs). As for the Technical Team Leads, the same thing applies (their focus is generally at a lower level), but in addition they don't have the authority to make architectural decisions. Also, with both roles, it's hard to ascertain exactly who has the responsibility for something like the non-functional requirements.

I see this pattern crop up fairly regularly, and it's a variation of what I talk about in my Mind the gap essay, where key responsibilities fall down the gap between team members. The easiest way to fix this sort of problem is to be explicit about the roles/responsibilities when starting the project. And that means pinning those responsibilities on somebody.

Delegation

Tue, 22 May 2007 08:14:00 GMT

I briefly mentioned delegation in my post yesterday about authority and I wanted to expand on this further. I talked about delegation in the context of having the authority to make decisions - you don't actually have to make all of the decisions yourself. Other examples of where delegation might be needed include :

Design : You've come up with a nice logical architecture that defines a collection of components and their interfaces. Taking these to the next level probably requires some lower level design effort, which you might not have time to do yourself across the entire system.
Coding : Unless the system is very small, there's no way you can code it on your own. Furthermore, there's probably little chance of you understanding how the entire system works at the code level.
Quality assurance : In a similar way to the code, do you really think you can code review the entire system on your own?

Delegation is an important part of a software architect's role and there's a middle ground somewhere between delegating everything and doing everything yourself. Either way, it's worth pointing out that delegation is different to ignoring/not being interested in what other team members are doing. The key points here are to trust your team, delegate where appropriate and make sure you have a handle on what's happening in, to use an agile term, "just enough" detail.

Authority

Mon, 21 May 2007 16:13:00 GMT

Related to responsibility is authority. Having responsibility for making things happen is one thing but, if you're going to be successful, you must also have the authority to do it. If you're responsible for the overall architecture of a system, you must have the authority to make the decisions and define that architecture. Likewise for everything else you might be responsible for as a software architect, ranging from initial software selection through to defining and enforcing the coding standards. Of course, as Brian says :

... we have to be careful not to fall into the deadly cycle of becoming the decision authority for every decision.

I agree and, provided you do have the authority, you can chose to delegate the decision if you wish. That's your choice but you still hold responsibility.

If you're the architect on a software project at the moment and find yourself continually asking for permission, take a moment to ask yourself why this is. If you have the responsibility but not the authority, you could be in for a bumpy ride.