Agile Software Architecture: The smallest change with the highest business value

Maarten Winkels

Change is inevitable. In fact, this is the only constant. It applies to the evolution of species, human culture, technology and the weather. Apparently it is especially applicable to everything associated with software development. Agile evangelists want us to embrace change. I think what they mean is we need to plan for change and allow changes in every part of the system that is under development. This means that schedules should not extend too far into the future and that technical decisions should never be fixed or final, before the project ends. In effect this promotes a very constant change management, where changes are continuous but small in stead of big and interrupting.

Most big projects I have seen follow quite a different pattern. Early in the process change is promoted, even advertised: Your credit management has low accountability? Let's remodel your financial management system! You have too many separate programs in your system? Let's throw them all out and rebuild the whole thing! Your website is not user friendly? Let's redesign the whole thing with this new cool framework! Of course a lot of analysis goes into finding out which changes can be applied to the system, but once every possibility for change and improvement has been found, documented, considered and (re)designed, changes are no longer allowed. A contract is signed and for the customer, who has been bombarded with questions and proposals for change, the long silence begins. In this period, the system is being developed, according to the design that has been consolidated with the contract. Changes that the business might want will be very costly. And then, when the customer has forgotten all about this project and can surely not remember what exactly the problem was that was being solved: BANG! The business is hit with the full impact of the New SolutionTM.

I think this approach has harmed the software development business. Software development is seen as a painstaking process of implementing changes, where it should be about finding solutions to business problems. Business is being scared away by the high cost of analysing their "information problems", let alone the cost of implementing all those changes. This is where the agile business proposition is at it's full force: Agile software development promises the most valuable thing first and short time to market. I would like to add a slogan: The smallest change with the highest business value. In stead of looking for all possible changes and trying to achieve them all at once, we should start out to find the smallest technical change that we can make that will give the customer the highest gain. That will be the first thing we'll develop. This means we need to have a clear picture of the technological landscape that the customer is in. What programs are they running? What do their processes look like? What does their infrastructure look like? But as soon as small improvements can be made, development should start and delivery should be at hand.

This defines the role of an architect in agile software development: Always on the lookout for improvements in the context of the customer. As everything in an agile process, this is in parallel with the other processes: design, development, testing. The architect does not try to write a conclusive report on the requirements and needs of the customer, he tries to feed those into the agile process as they are discovered. His focus and priority here are (as always) business value and early delivery.

I think this is an important part of the Agile business proposition. In stead of building a new system where everything is improved, we'll start out with the existing situation, applying small changes to arrive at the desired situation. This will also provide the customer with means to steer the process when he feels that it is taking the wrong direction. The ultimate goal as the customer percieves it at the start of the process will be the same, but since the process is agile, the customer can decide at any point to change direction or that the current situation is satisfactory. In a way, the customer can sit back and relax: we won't try to change everything at once and the architect will be responsible for finding out what improvements should be made and when. This is a good counterweight against the higher involvement we demand from the customer with regards to requirements and testing.

In conclusion: There is a role for architects in Agile software development. The architect is concerned with integrating the system in the technological landscape of the customer. It's main focus is on determining which changes have the smallest impact and the largest business vale for the customer. This underlines one of the most important parts of the Agile business proposition.

Comments (2)

  1. Lars Vonk - Reply

    December 5, 2006 at 12:06 am

    Hi Maarten,
    Are you saying that it is the architects responsibility to determine which changes have the highest business value? I think this should be customers (or The Business) responsibility (e.g. the product owner in Scrum), the architect (or every other software developer) can help the customer by providing input if needed. Although I doubt if he can because in most of the cases the customer doesn't even know what the business value of a change is. Architects (or developers) can say something about the impact.
    Also I think it's too difficult to say that an architect should have a certain role in an (agile) project. This because I have heard too many types of architect these days (software architect, business architect, business process architect, functional architect, integration architect etc.) There has already been a lot of debate going on about what an architect is and should do, integration is one of the more important tasks I guess. But if you say the main focus of an architect is determining which changes would be best to implement, then a better term would be consultant. Or even better a business (:-)) consultant, because that is then his main job: Consulting the business what changes should be implemented.


    PS. Having all this said I am suddenly realizing that this is exactly what the BIA in Xebia stands for: Business Integration Architects. We have been Agile from the start!

  2. Maarten Winkels - Reply

    December 5, 2006 at 8:46 am

    Hi Lars,

    I agree that the term Architect is a bit fuzzy and overused these(?) days. What I try to do is point out a task in an agile project that could be assigned to the 'architect' role: Focus on small changes.

    As you point out, no one can better determine business value than The Business. Normally, they have a feel for what features are needed. What they normally do not have a feeling for is the cost of those features. This cost comes in two (or more?) forms: Implementation and Integration.

    Within an Iteration, it's the task of the developer to estimate the cost of implementing a certain requirement and discussing the cost/value with The Business. This will lead to an Itartion planning, that may span multiple iterations, as certain requirements will be pushed out to future Iterations.

    There also is the cost of Intergration. Determining this cost involves knowlede of the technologies used by The Business and the systems they run. What I try to put forward is the notion of the changes that have the lowest cost in this respect. Implementing these requirements first will help The Business bring the new system to production without large interrupting changes.

    Maybe this could be termed 'Scope Management' or 'Scope Planning'. The project should start with a small scope and gradually enlagre the scope. I would think of a 'Scope' as a grouping of requirements.

    This would mean for instance that the long term target of a new system is replacing the numerous old systems. While this is the long term target, it's scope is too big to handle at once. The project should focus on a smaller scope first.


    -Maarten Winkels

Add a Comment