New Year, New Thinking?

2010 is over and 2011 has arrived. We’ve all returned to work ready to push on with our commitments – but can we honestly say that we are producing better software now than we were at the beginning of the millennium?

In another great article from InfoQ, two seasoned IT professionals - Bruce Laidlaw and Michael Poulin – each with more than 30 years of experience, have compared their conclusions about the past and present of IT, focusing on what we are doing to make progress.

It’s a very pro-agile article and they do cover a lot of ground. However, it’s interesting when discussing certain aspects of agile methodologies they argue that…

“[The] Majority of agile methods are based on assumption that business cannot and will not work differently tomorrow than it does today; these methods do not challenge the way business works even if this way is contra-productive for the enterprise.”

I genuinely love agile projects, but its fair to say that on some agile projects in the past I’ve also been in the situation that they describe in their article where an agile development process fails to adequately deliver non-functional requirements adequately due to a preference to deliver perceived business requirements…

“It’s not a rare situation where agile teams promise to add an error handling mechanism, escalations, notifications/alerts, compensation logic, transactional integrity, security and operational stability “later on”.

All these technical things are Quality of Service (QoS) attributes that the business expects from the technology by default, not ‘next time’ or as a special additional feature.“

The article is a pretty convincing argument for a new kind of approach to enterprise software development where business architecture, technical architecture and governance discipline combine to  ’build-in’ quality and agility from the start, something that many modern developments often lack .

You can read the full article on InfoQ here.

Harmonising Agility and Architectural Strategy

It’s hard figuring out how to get a balance between agile development and strategic architectural goals, but its not impossible. It’s important to understand that you need both if you are to enjoy sustainable success over long periods. Too much emphasis on the here and now can result in brittle engineering. Whereas too much emphasis on pure engineering can often mean that not enough business value get’s delivered.

My advice is simple. Agile projects deliver functionality based on the requirements fed into the project as User Stories. The key to achieving harmony is to ensure you create user stories that capture both the functional and non-functional requirements of your project. Some agile authors refer to this as ‘building an architectural runway’ – the point being that its very bad to ‘run out of runway’ during take-off.

I realise that. In truth non-functional requirements are often better suited to the acceptance criteria of a story rather than being a story in their own right. However, when your running a programme of projects, committing to architectural evolution in this way will help you to ensure that you never get boxed into a corner. Your software should remain strong enough to support what you currently have, but will have enough headroom left over to accommodate any foreseeable requirements.