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!
View all posts from dan foody on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You have the right to request deletion of your Personal Information at any time.
You can also ask us not to pass your Personal Information to third parties here: Do Not Sell My Info
We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.
Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.Learn More