Development Process

Development Process

The degree to which the development process affects the architect and architecture really depends on the type of process. If the project chooses a waterfall-type process, the architecture is likely to be defined well ahead of any development work and the role of the architect is to define the complete architecture, possibly with no direct communication with the people who are to build it. However, we have never seen a traditional waterfall process used successfully on an Internet technology project, although we've seen it tried on a number of occasions.

Internet technology projects, perhaps more than other types of system development project, must deal with rapidly changing requirements and technology (the technology used in Internet systems is still developing rapidly). In the early days of the ‘dotcom era’ the constant ‘requirements churn’ was due to the mad scramble for the hearts and minds of users (closely followed by the hearts and minds of investors) – plus the fact that a lot of people didn't really know what they wanted their systems to do because no-one knew what Internet systems were really capable of.^[1] Obviously we've moved on from that era but businesses are still learning how to use the Internet, and the ways the Internet allows businesses to operate frequently throws up new opportunities for partnership and cooperation that inevitably affect the Internet and extranet systems of the partner organizations. Just because the dotcoms no longer command the headlines or the investment community's interest doesn't mean that Internet technology projects are any less volatile than they used to be.

Many projects have responded to the volatility in requirements and technology by adopting some form of agile development process. The use of such a process brings a wealth of benefits for the creation of software components to be used in a system, not least the ability to rapidly re-purpose or re-engineer bits of the application as requirements or technology change. This ability to change the application rapidly is usually substituted for a formal software architecture phase, and the role of the software architect is down-played or completely absent.

So where does this leave the system architecture and the system architect? Hardware is, by its nature, much less easy to refactor. If you spend your hardware budget on one big server and then realize you really need two medium-sized machines, you can't just split it in half. Some fore-thought and architectural consideration is required. This architectural consideration also needs to be extended to how the software is spread across the system hardware, if not to the internals of the application itself.

Agile processes do not obviate the need for architectural thinking; the architecture and the architect role needs to fit in with the agile process. In an agile team, the architectural decisions will tend to be shared out between the more senior developers and those decisions will evolve over time (see [Fowler 2003a]). This is the approach to architecture that we have taken over the past few years – evolving the system architecture over several development phases of the system.

^[1]Perhaps the one exception to this was Amazon.com who really blazed the trail of Internet technology systems. Certainly in Europe they were seen as a yardstick by which to compare any Internet technology system, not just B2C e-commerce systems. Developers would know to expect a deluge of new and changed requirements for the system they were building soon after Amazon released a new version of their system or announced a major new feature.