The Idiom and the Idiot

The concept of, and quest for, an Agile Architecture is a hot topic these days, and as far as I can tell, it’s a debate that will continue for some years yet. Most likely the term agile will go the way of so many other buzzwords, and fall into disrepute, but I hope the premise that it’s good to work flexibly and reactively with your customers outlasts the current hype.

I’m fairly optimistic that it will because once you’ve tried it, more traditional prescriptive approaches can feel awfully limiting.

But what of that agile architecture?

It seems the search is for something that has all the comfort and solidity of big approaches like TOGAF or Zachmann but which can appear to be done quickly.

At least that’s my cynical view.

My other cynical view is that the opposing camp doesn’t want to do architecture at all.

My practical experience is that during agile projects it’s not uncommon for old-school architects to show up and generally get in the way and slow things down - creating both a clash of ideologies and a debate about what architectural approach would work appropriately.

This gives rise to terms like ‘emergent architecture’ - one that appears as you go (and I’ve heard that said in both positive and negative lights). So is anything architectural and strategic compatible with a delivery style that focuses on flow and minmising waste and responding adaptively to change?

There was a good question asked on infoq recently about whether SOA and Agile could work together. At first I thought the question was nonsense (I mean.. one’s a development approach and the other is an architectural concept), but on reading the article and the comments I could see that there is something interestingly philosophical to consider here.

SOA done thoroughly certainly suggests a lot of design and thought up-front (what are services? What’s the governance model? What’s the data model? How will re-usability be enforced? Versions controlled? Legacy applications behind services decommissioned?), and agile does suggest as little design as possible (or rather just barely enough.

Even if you stick to ‘just enough’ there’s plenty of scope for disagreements between developers and architects, because to not mess SOA up, data architects will always want more time to create a more sophisticated enterprise model than the development teams would like. However, to avoid service proliferation, you really do have to solve some of tomorrow’s problem today, or risk introducing tight-coupling to an inadequate and inflexible data model.

I’ve seen the worst of this happening where a whole bunch of api “services” are developed in haste and then just exposed as web services and the SOA boxed ticked. Then management wonders why the mythical reuse promise isn’t fulfilled on the next project.

So it’s clear that big up-front demands and delivering iteratively, whilst responding to changing priorities (with some requirements not ever being delivered) are in some conflict. And whilst I’m not sure that there’s a perfect answer to the agile architecture question, I do think there’s a better answer than those we have now.

And that’s thinking in terms of idioms.

Something is characterised as idiomatic if it’s peculiar to a particular group, individual, or style. An idiomatic architecture is one that operates exactly like the peculiar groups, individuals and styles of the business it supports would operate if there was no information technology there at all.

Many architecture discussions these days involve starting with the existing ‘application map’ and deciding where new functionality should go. That’s fundamentally the wrong thing to do. Equally, abstracting existing process functionality into services as part of adopting SOA (or messages for EAI) is wrong - because they start from what’s there now, not from what would be there if there were no tech.

A better way is to talk about the business in terms of its events and flows and desired outcomes and draw a picture of the idiomatic aspects of it. Then swap the typical comments on the left with the ones on the right.

Idiot	Idiom
Everything should be a ‘service’	Only make it a service when it’s already being reused
SOA means web services	SOA is anything that’s well-defined, reusable and discoverable
Expose a method as a service	Expose a service as a service, and make it consume a document not operate like RPC
We don’t work like that here	That’s what got you into this mess in the first place. Think differently to fix it
Architecture is different to business projects	Architecture is nothing without business projects, you cannot separate the two (except for specific infrastructure architecture changes)
We need a fully developed data model	You need interfaces that cope with versioned data models
We need a sophisticated architecture	You need an architecture that’s exactly as sophisticated as your business
We work like this here, that’s idiomatic.	Technology mirrors the business idioms, not the technology idioms. There’s no ideal architecture.
We must use tool X	You must model the business, then select the tool.
We must adopt methodology X	There’s no silver bullet. You must only do your best given what you know at any one time.