Organically grown architecture

For a long time the Agile movement has advocated that you shouldn’t anticipate future needs, and as such, you should defer important architecture decisions until the ‘last responsible moment’. Like a lot of the Agile principles it is based on common sense – you should do the minimum amount of work required to satisfy the current feature you are implementing. This may seem irresponsible, as we often consider architecture as the cornerstone of software development. I equate this to architecture being rigid and requiring a large up-front investment before we can demonstrate meaningful progress to our users and the business.

Architecture doesn’t need to be rigid, particularly when viewed in context with the other practices of Agile and Software Craftsmanship.

In a previous post I introduced the principle of experience-driven architecture, which unfolds from User Experience design. My motivation was not to replace one type of big up-front design for another form of big-up front design. When it comes to surfacing requirements, User Experience has the same flaws as traditional software development – we always surface more requirements than we can possibly deliver within the required timeframe. So regardless of the approach you favor – your software will evolve organically. So why shouldn’t your architecture?

It all boils down to one motivation. It builds trust and confidence (it also eliminates waste – more on that another time). Agile advocates that we deploy software early-and-often. The sooner our stakeholders and users see demonstrable software, the sooner we start building trust and confidence. The shorter the interval between deployments, the faster that trust and confidence grows. It eliminates the need for estimation and gnarly gantt charts, which are just tools for conveying trust and confidence, and exist to support rigid architectures. With an organically grown architecture we are able to demonstrate trust, rather than using tools that say “trust me”.

When we combine this with experience-driven architecture and User Experience we bring a laser focus to what really matters. We build the feature that matters most, we deploy the feature when it is done, we respond to changing priorities, and we act upon new insights. In short we get to our goals quicker. We can’t do this with a rigid architecture.

Advertisement

The anti-principle of architecture

If we look at architecture through the lens of User Experience then we should consider the following principle: the experience drives the architecture

To understand why this principle may be important we need to look at one of the limitations often encountered with Service Orientated Architecture (SOA), or any other approach that relates to big up-front architecture. When we build the architecture from the ground-up we are unknowingly placing constraints on the user experience. As is then too often the case, the limitations of the architecture are surfaced to the user. To state this as an anti-principle: the architecture drives the experience

The goal of User Experience is to consider the needs of the user, often in the context of the business needs. We put the user front and center – user-centered design. Our goal is to design the best imaginable experience and to allow the user to complete their task with the least amount of fuss.

As with all principles in Agile, it follows common-sense. I’ll continue to build on the principle of experience-driven architecture in future posts. In particular I want to discuss experience optimization and organic architecture.