Clearly we are looking at SOA a bit differently than we did last year and the year before. What was once promoted a the savior of poorly planned architectures is now really what it always was: a pattern of architecture that needs some commonsense approaches to work correctly.
While many sought out shortcuts through technology, the reality is there are few ways around the work that needs to get done. In other words, Real World SOA.
[ Take a slideshow tour of InfoWorld's 2009 Technology of the Year Award winners in Applications, Middleware, and Data Management | Application Development | Platforms and Virtualization | Systems and Storage | Networking and Security ]
I wish I could tell you that it's just a matter of focusing on this technology, or this standard. But the fact of the matter is, as always, that SOA is something you do, not something you buy, and it's not a standard.
The shame of this fact is that many projects, had they focused on the fundamentals a year or two ago, would have been resounding successes today. However, making many of the mistakes that are more clear to us now, many of those projects have been shut down, delayed, or are in trouble. There are success stories out there -- I'm just saying we could have had many more.
I am optimistic. In many respects, the return to the fundamentals of SOA, as we've been focusing on recently, is a good thing, and become the "real-world SOA" going forward.
So a common question I'm getting lately is about the changing patterns of technology acquisition around "real-world SOA." There are indeed changes to come, if not occurring now.
The core change will be around the more sophisticated design-oriented technologies, such as design-time SOA governance, and other tools that deal more with the softer aspects of SOA. I've been here before, and based on the feedback I've received, my original accretions are correct. Again, it's not disputing what the technology is all about; it's being realistic about the need.
There are many derivations of design-time tools and technologies available, but few solve any of the practical problems that entrenched SOA architects need to solve this year, and perhaps next. In essence they are so high-level they are not relevant, given the needs of the more practical approaches to SOA we are leveraging today.
Going forward, the technologies employed will be focused on solving particular issues around the SOA solution, once the requirements are understood and the architecture defined. Thus, things such as service mediation, security, service development, and runtime SOA governance will be at the top of the shopping list.
It's just part of returning to the fundamentals.