This article is an additional response to an excellent article written by Simon Powers here, where Simon discusses putting Architecture back onto the Agile roadmap.
Most functionality needs architecture to work. An obvious example to illustrate this fact are buildings. There was a famous case with London’s Millennium Bridge, which gained the nickname ‘Wobble Bridge’ because it was... a bit too wobbly. The problem was fixed with dampers, similar to shock absorbers on cars, without a rebuild or redesign of the bridge being necessary.
Since then, another problem has come to light with the Walkie Talkie building. Reflected sunlight coming from the building was damaging cars, and the problem was fixed with some simple solar shading.
How is this relevant to Architecture in the IT world?
Well, the examples above simply illustrate some of the key principles of ‘Architecture Design’ that are highly relevant to the IT world. Think for a moment about the scale of the architectural solution that would have been demanded to prevent the Millennium Bridge from wobbling at the early design stage. Or the ‘possible’ wobble that we would have to have engineered out, or the building design that would have been demanded to prevent reflected heating of the cars from the Walkie Talkie. Chances are that a pre-designed solution considering all those factors would have been more expensive than the solutions we ended up with, plus it would have probably delayed delivery.
In the section ‘Scaling Agile Architecture’ from his article, Simon refers to the “third philosophy of Agile Data Methods”, being:
“Enterprise groups exist to nurture enterprise assets and to support other groups, such as development teams, within your organisation. These enterprise groups should act in an agile manner that reflects the expectations of their customers and the ways in which their customers work.”
To achieve this, six basic approaches were suggested:
1. Focus on people, not technology or techniques. 2. Keep it simple.
3. Work iteratively and incrementally.
4. Roll up your sleeves.
5. Look at the whole picture.
6. Make enterprise architecture attractive to your customers.
These are excellent approaches in developing specific Enterprise Architecture. We find there are a few others that we would like to add. These are:
- YAGNI (You Aren’t Gonna Need It)
- Just enough, just in time
- Risk adjustment (failure risk)
You Aren’t Gonna Need It (YAGNI)
The challenge to architects is that they are prone to the death knell of architecture development and build, the famous “What if” scenario, “Did you cover that”, comments from everyone else. (This is further discussed in Risk Adjustment below). Inevitably if you plan for every scenario, then for most work items, this is both waste as well as an enormous drag on delivery / implementation.
Just enough, just in time
‘Just in time’ is an excellent principle for lean and agile delivery, and putting ‘just enough’ in front aligns perfectly with incremental delivery or a working piece of product / functionality. Alongside the other value of ‘shortest weighted job first’, which mixes cost of delay and Return on Investment into a useful prioritisation process, this allows architects to prioritise what is needed to deliver the architectural feature environment that supports an agile architectural development and evolving environment, as you can see here.
Risk Adjustment is related to the two topics above. The key is to decide what amount of time and effort to put into upfront planning e.g. technical ‘spikes’, traffic load, ‘atomic’ independence. The greater the risk of value loss and reputation destruction due to a failure of service, down time, non delivery, product feature failure, time wasted etc., the greater the demand /sense to undertake more planning upfront.
In the evaluation of a risk situation as an agile architect you are not the Product Owner. You need to understand your Product Owner’s acceptance of risk and what the balance is between risk mitigation and speed to product development / improvement that such architectural improvements and developments would provide.
What’s important is keeping the six principles mentioned above in sharp focus. You need to support the Product Owner to develop their understanding of the product and programme versus their appetite for risk. You need to be the specialist that advocates for architecture design and improvement as part of the agile world of ‘inspect and adapt’, develop and deliver the next increment and make your architecture lean and Kaizen.
Do you think that Continuous Improvement is an approach and a solution to Enterprise Architecture design and implementation, a keystone for the future? Share your thoughts using the comments box below and let us know your opinion.