Having a passing interest in investing, I always have a chuckle to my self when the subject of economists putting out forecast for some economic indicator is discussed. There seems to be one of two approaches that economists take to ensure that their credibility stays in tact:
- Forecast that far in the future that people will forget what you said by the time we get there.
- Forecast frequently so that you can tune your forecast.
When I look at higher order architectures like enterprise architecture we are in effect trying to achieve that same as our economist friend and predict the future. Architects seem to adopt approach one(1) and create designs that are that abstract i.e. in the future that by the time the design is realised it could be a complete failure but still conform to the initial design. As great as this is for the architect in question, what benefit has it actually delivered for the enterprise.
The agile community at the coding level has adopted the approach that as we learn more we will adjust the application. Why can’t architecture take the same approach? To achieve this there are a couple of obvious things that need to be addressed to enable the process to be agile.
- As the business evolves these changes in direction need to be communicated to the architect for refactoring them into the design. This is probably the one factor that can make or break being able to actually deliver a design that meets the requirements i.e. success or failure.
- When you refactor code, unit test tell you if you have an interface or implementation dependency that has been broken, we need to be able to unit test our design when we refactor it.
- Being able to architect in an agile manner requires a process that is light weight and is itself agile. Unfortunately a word document has no teeth so creating a process that is self validating at the architect level may be a little way off.
- Following on from agility you also need to break down the problem into manageable chunk and solve them one at a time. Roger Sessions dives into this in his White Paper on A Better Path to Enterprise Architectures.
By applying the Manifest for Aggile Software Development to Architecture in general we can at least change the culture of trying to predict the Future. We can then focus more on trying to bring the practices and tools up to a level where they can support the new process.