Is the "A" in SOA the Problem?

My discussion with Tony Baer at onStrategies the other day, along with Joe McKendrick's discussion with Ron Schmelzer, where Ron said (to paraphrase) "It's always a great time to invest in architecture," got me thinking; and that's always a dangerous thing.

There are a lot of people preaching the line "SOA is an architecture (not a solution or end state)."  And, yes, I agree SOA is not a solution or an end-state.

But, I've got to wonder whether the "SOA is an architecture" mantra is just a cop out?  Is it just a simple way to say "expect no measurable return in any time frame you'll care about so stop bugging me about it"?  The benefits of architecture are fundamentally unmeasurable unless you can do a direct A-B comparison... which you can't.  And, one thing I've learned is that if you can't figure out how to objectively measure something, you probably shouldn't be investing a lot in it.

The problem with focusing on "SOA is an architecture" is that architecture is perceived as needing to be complete before you begin building.  First, getting an architecture "right" takes a lot of time (probably time that an organization doesn't really have).  Second, things change - so what was "right" this year is probably not "right" then the next year.

There's clearly also a fallacy in saying "once we get the right architecture locked in, we'll be agile."  Why is this wrong?  Because if your architecture itself isn't agile (i.e. quickly changeable and adaptable to unforeseen circumstances), then fundamentally nothing you build on it can be agile in the long run either.  If this doesn't make sense, I've blogged on a closely related topic in the past that might shed some light on the subject.

If enterprise architecture is your thing, that's good.  I like architecture.  Some of my best friends are enterprise architects. But, instead of focusing on SOA infrastructure as key to your architectural success, maybe you should be thinking "How do I build an architecture that itself is agile?"  Maybe you should be thinking, "How do I build an architecture that will make it easy for me to adapt the next wave of architecture (whether it's EDA, RESTy, or unknown)?"

Now, on the other hand, if you're building applications to solve problems for your business, you should be thinking about how you harness the tools and techniques that are available to you to get your job done faster and better for the business stakeholders - regardless of what worked best on the last project.  "Horses for courses" as my Irish friends would say.

These two recommendations (one to enterprise architects and one to the project) may sound disjointed, but they come together: An architecture that itself is agile can easily fit with projects based on different architectural foundations.  Agility at both the project and enterprise level.  Nothing better!