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.