Mind the gap again
You need to pin responsibility on somebody
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.
Experience should guide, not constrain
It's a hard lesson to learn
One of the things that makes an architect is experience, and in many cases an architect has got where they are because of the expertise that they've built up in their chosen technology; be it Java, .NET or whatever. I'm still of the opinion that it's perfectly viable to be an architect with a particular technology focus (e.g. a Java architect) but there is always a danger that everything will start to look like a single technology solution.
In a way, this is inevitable. If your experience is mainly in technology X, then you're going to feel comfortable designing systems in technology X. Of course, this doesn't necessarily mean that technology X is the best solution. An example that I always cite is that most of my background is in building Java systems; from client-server and web apps through to distributed systems and service-oriented architectures. A few years back, Swing would have been my first choice of technology for building a desktop application. Ask me know though, and I'd lean towards a .NET or RIA client, but ultimately it depends on a number of things. In this case, the influencing factors include the skillset of the team, existing vendor relationships, politics, supported desktop platforms, desktop deployment policies, operational/support requirements and so on.
Being open to other technologies is a hard lesson to learn and, as we've seen on the architecture training course, it's natural for people to stick to their tried and tested technology set. As an architect, you should certainly let your experience guide you in making the right decision. Having said that, you shouldn't let it constrain you.
Following the specification
How important are the standards to you?
Back in the days when J2EE app servers were the best thing since sliced bread, I remember having lots of discussions with people about the J2EE specifications and I don't mind admitting that it was always my goal to build a truly spec compliant application. For example, file access from the EJB tier was explicitly forbidden in the specification; because of reasons around portability, lack of file system transactionality, etc. Fast forward a couple of years, and I started to realise that a lot of this stuff didn't really matter. File access via the EJB tier actually did work and it was much simpler than writing JCA connectors. In addition, and in the same way that I have almost never swapped out a database during a development project, it didn't really matter if my J2EE application was portable or not. We'd develop on WebLogic/WebSphere/etc and we'd deploy on the same platform.
Earlier in the week I was talking to a group of people who were defining the architecture for a Java EE system and they started asking how they were going to access the file system from within their EJB tier. I'm curious ... what's the general feeling about specification compliance these days? Do you care whether your applications follow all of the recommended guidelines, or do you take a pragmatic view that just asks whether it works? How important is this to you as an architect?
