Coding the Architecture - responsibility tag

Why aren't software architects held accountable?

Tue, 03 Mar 2009 10:14:00 GMT

Mike Walker has an interesting post comparing the architect roles across the building and software industries, entitled The Nemesis of Software Architecture. Comparisons aside, there's one point that I really wanted to pick up on.

4. Accountability Inherent - Building architects are accountable for there work when their specification fail while software architects are not. An example of this is the case of an architect stealing a design for the Freedom Tower or the example of MIT that sued well known architect for defective structures. There is clear accountability whereas I still haven't heard of someone getting sued for copy & paste...

I'm a big proponent of software architects having the responsibility and authority to ensure that the projects they are working on come to a successful conclusion, but it does raise an interesting question of why project sponsors don't typically hold software architects accountable. Perhaps it's because the dynamics and roles of everybody on the project team aren't well understood in most cases. For example, what's the working relationship between a project manager and an architect; or the developers and an architect? Or maybe it's because our agile approaches tend to favour sharing the responsibility throughout the entire team, which can end up with the project lacking a single coherent and consistent direction.

In order to address this, maybe we need to go back to basics. Why aren't software architects explicitly given accountability at the outset of a project and what incentive is there for them to accept it?

Becoming more architecturally aware - part 2

Tue, 28 Oct 2008 20:18:49 GMT

Last time I talked about how we need to understand how application frameworks are designed and work behind the scenes in order to produce code that is consistent and compliant with the overall architectural principles. The second aspect that we need to become architecturally aware about is the underlying technology.

Again, let's put this in context of my current .NET project. I have much more Java experience than .NET experience; I've written some C# and I've played with Silverlight, but ASP.NET is new to me. Thankfully, the concepts behind ASP.NET translate fairly directly with those behind JSP, so it's not as if I'm tackling this from a standing start. Having said that, I've felt that it's really important to get to grips with the underlying architecture of the technology so I can be sure that the code I write, again, integrates properly into the overall architecture. An example here would be the ASP.NET page life cycle. Like JSP, ASP.NET pages have a series of things that happen to them when a request is made, which includes creation of the request/response objects, page compilation, page instantiation, calling page event handlers and so on.

Knowing the finer details of a programming language is one thing, although using or not using new language features such as generics isn't necessarily going to negatively affect the architectural integrity of the solution. Not understanding something like the page life cycle of ASP.NET could. For example, it's important to understand the page life cycle so that you understand when objects can be shared/cached. Session management is another important thing to understand, and blindly throwing objects into the user's session can have architectural implications if your application needs to scale horizontally and you need to implement transparent session failover using session replication.

Being more architecturally aware doesn't necessarily mean that you need to understand the entirety of the bigger picture, but you should understand how to write code that is architecturally compliant. And that means understanding more about how the underlying technologies work.

Becoming more architecturally aware - part 1

Fri, 17 Oct 2008 09:06:00 GMT

In my Mind the gap essay and Why Software Projects Fail presentation, I talk about how we as developers should be more architecturally aware if we are to bridge the gap between the code and the overall design. I include myself in this statement because recently I've started adding functionality to an existing ASP.NET website and I've found it essential that I become as architecturally aware as possible in a short amount of time. Let me provide a couple of real world examples.

Although I'm adding behaviour that is in effect isolated from the rest of the application, my code is still a constituent part of the overall architecture. In addition, I'm using some of the utilities and frameworks that the development team have already produced. Clearly I need to understand the usage patterns in order that I can be productive as a developer on the team but, furthermore, I need to understand something about the inner workings in order that the code I write is architecturally compliant with the rest of the system. I'm sure you've seen this yourself, but give a few people the same framework and you'll see usage patterns that you hadn't even dreamed of. Some will be what you expected, some may be better than what you expected and some may break your framework in horrible ways.

If somebody on the team is taking responsibility for the architecture and undertaking reviews, it's possible to catch those instances where application framework code isn't being used as anticipated. Sometimes, it's even possible to automate these architectural conflicts with a set of automated unit tests. If, however, nobody is taking on this architectural guardian role and everybody is simply using what they've been provided with, then this is where problems start to creep in. Sometimes they creep in from people adopting a copy-paste approach to development (i.e. copying another class because it "works") and sometimes they creep in because people just aren't aware of the hidden side effects of their framework usage pattern. Either way, problems introduced because of a lack of architectural awareness might not show up during local single-user testing, but could prove critical when the system is rolled out to a wider user base.

The only way to get really productive with existing application code is to dive into it and understand how it works at both a conceptual and implementation level. Only then can you ensure that the code being written is compliant with the rest of the architecture, which is crucial for the quality and integrity of the solution. This is one way in which developers should become more architecturally aware and next time I'll discuss another.

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.