Category Archives: Agile & Architecture

In an interesting echo of my last piece (Why Software Isn’t Like Building Construction), Scott Ambler has analysed bureaucratic processes as a response to management fear about what can go wrong in software development. His conclusion is that these processes only give the illusion of addressing the underlying fear. His article is well worth reading.

Many software development and management methods are founded on a basic assumption – that constructing software is rather like building a bridge or a house. Once we’ve “done the design”, actually generating the software ought to be a completely predictable, relatively low-skilled process. However four decades of failure to achieve this vision might suggest that we should revisit
the assumption.

In a paper entitled “The New Methodology” Martin Fowler, the guru of object-oriented development, suggests a couple of reasons why this might be.

My article answers Martin’s, suggesting a couple of other considerations, and whether we have to completely abandon the physical construction analogy as a result.

I recently attended a day of the Butler Group “Application Development Strategies” Symposium. I’ve just posted a short report on some of the more interesting discussions and presentations.

Almost all of the presentations shared a reminder that we still have a “software crisis” – the vast majority of software projects fail to deliver to their original targets and estimates. The presentations suggested three independent, but not exclusive, approaches to try and resolve the problem:

• Adopting better, more agile processes to address fundamental weaknesses in “waterfall” processes,
• Adopting better tools and techniques to improve development productivity and the integration of the application life-cycle,
• Enforcing a stronger “enterprise architecture” framework for development.

This last one was surprising, with several papers echoing my view that a strong architecture is essential if agile development is to succeed on a large scale or in complex and critical applications.

There was also surprising agreement on things which won’t solve the problem:

• No-one was promising a technical or product “silver bullet”. This includes web services!
• No-one was suggesting that we should just “try harder” with old-fashioned tools and processes.
• There’s no “one size fits all” solution. For example it’s a mistake to force a formal, high-ceremony process onto small business systems developments.
• Excessive technical standardisation is also not the answer. The drawbacks include “lowest common denominator” technical solutions and inflated costs where the standard solution is “overkill”.

Read my report for more details.

In Extensibility Points, Gregor Hohpe describes architecture as a guessing game, trying to understand future changes to a business, and designing a system to cater for those changes. He’s written a good article on types of extensibility and where they can be applied.

But Gergor’s article doesn’t really touch on understanding the dynamics of business change, and how these should dictate the form of architectural extensibility. Neither does he discuss the problem of being an architect who understands what flexibility is required, but being unable to get either the customers, or the suppliers, to agree. I seem to spend a lot of my time saying “I told you so” when a problem I predicted occurs – this is frustrating, even if I’m being proven right.

If you want to understand more about the dynamics of change, you might look at my previous postings on the subject:

Architects – Masters of Order and Unorder

Business Flexibility

Strategies for Flexibility

In a recent article, Gregor Hohpe asks “Is SOA Like Drunk Driving?” In our attempts to address the shortcomings of component-based development have we “swung too far” and introduced new problems?

One recent experience suggests to me that we may well be at risk of this. Read about my first experience of Web Service development and judge for yourself: have we thrown the baby out with the bath-water?

I’ve recently been catching up on the Microsoft Architecture Journal. This is an occasional MS publication, which can be downloaded from the

.NET Architecture Center. It’s got a lot of good articles, with a software architecture and process focus.

Of particular interest, there’s an article in the first edition by Cap Gemini on “Enterprise Architecture Design and the Integrated Architecture Framework”. Obviously every consultancy has their own architecture framework, and they all share some features, but what makes this one a bit different is the strong focus on the contextual (business context), conceptual (vision) and logical (solution independent capability) aspects, with technical details relegated to a bottom physical layer. It also has one of the best discussions I’ve seen on the relationship and differences between enterprise and project architectures.

Inspired by an article on Richard Veryard’s SOAPBox Blog, this piece considers the business equivalents of expansion capabilities like the spare slots in a desktop PC.

Sometimes formalised modelling techniques like UML are not the best solution. Microsoft have recently started talking about “Domain-Specific Languages”, specialised modelling techniques for specific tasks. My Domain-Specific Modelling Techniques page outlines some useful DSLs I have developed or discovered.