Wednesday

SOAs ‘nature’ and integration.

An interesting post from Joe McKendrick contains the views of some consultants, as concerning SOA and integration. The issue, deals with a Shakespearian quest ‘to be or not to be’ with ‘be’ as integration.

“SOA is integration. SOA is not integration. Got that?

There’s a  renewed debate raging about the relationship between the practices of service oriented architecture and integration.

SOA is more than EAI 2009, but where do we start? […]”

As Gartner analyst Yefim Natis states, few organizations have one comprehensive SOA — most organizations have multiple islands of SOA that will eventually need to be brought together. Ann Thomas Manes, pointed out that “Many organizations mistakenly perceive SOA as an integration strategy. But it is not. SOA is about architecture. To achieve SOA, you must re-architect your systems.” But Loraine takes more of a pro-SOA-is-integration stance, noting that “most companies aren’t getting into SOA for a complete rebuild. Most companies deploy SOA because it’s so darn helpful with simplifying integration:”

“…companies don’t want Extreme Makeover. They’re looking for a slight update, something that ties the room together, as interior designers like to say. … And here’s another hard truth: Although David Linthicum and others believe that agility is the ROI for SOA, many companies are realizing SOA ROI through integration.”

Ann Thomas Manes urges practitioners to look beyond integration when planning SOA efforts. “It’s fine to use service oriented middleware to implement integration projects, but then you need to readjust your expectations. Most organizations that I speak with say that the goals of their SOA initiative are to reduce costs and increase agility. Unfortunately, these organizations aren’t likely to achieve these goals if their projects only focus on integration….”. SOA should be about more than simply linking app A to app B, and so on. SOA is about innovation. Every SOA-related proposal out there should include the word “innovation” somewhere in the text. And, let’s face it, SOA would be downright boring (make that Boring with a capital B) if it was just another means of app or systems integration, and nothing more.

But, nevertheless, integration is still an essential phase in the evolution from soloed, proprietary systems to full-functioning service oriented architecture. In many cases, it can help provide the initial justification for commencing with an SOA approach. And for many SOA proponents, especially those facing organizational resistance, the key is to just start.

And, remember, SOA may involve integration, but it truly is about innovation.

Actually, the truth, or the need (with the Aristotelian notion) behind doing SOA is that the main goals of SOA initiatives are to reduce costs and increase agility. The getting out from silos and proprietary systems is just the good reason of taking SOA approach in projects and have the acceptance of CEOs. How many times the “monolithic-systems” overcome has been stated in such meetings and proposals? And of coarse, at the end, how many times did a true SOA solution broke that “monolithity”. Some will say always, in the context of the project. But the true SOA should guide towards “the standardization of the core architecture elements (…) and furthermore to establish an optimized integration approach for existing assets of the environment.” as stated in the SOA and the real Service Integration issue post. The problems of real life environment (both IT, infrastructure and financials) force towards an analytical solution, meaning solving one problem at a time. This is the main headache for considering SOAs in every extend you may wish to use it.

The most useful approach to SOA, is the change of the adopted philosophy. The ideal SOA, considered somewhere in the Platonian world of Ideas, as a successful concept, has to do with a non-analytical approach, but mostly with a holistic one. The web services and the integration (imagine behind that word how many systems/applications/business approaches/files/tools… might be hiding) the business needs and the time constrains are giving the first bird-eye view, or the context of the environment to be SOA-ised. But this is not enough. If it was, then correctly, we should be speaking about re-engineering and therefore reinventing the wheel. A solution of this type, is something like.. “drop everything out and put the new, SOA”. SOA should deal with ALL of these. According to the project at hand, an holistic view should be taken in every aspect of the analysis. We should thing with the duality in mind (this project, the whole enterprise environment) and in a time agnostic attitude (as-is and to-be in one context). Ok, the magicians are out of job nowadays, but none said that doing SOA should be easy. In the beginning.  After having a good and approved idea of the total-holistic SOA environment in the context enterprise, then the compliance rules are straight forward and therefore the base of the SOA for the project(s) at hand to start with. SOA is about innovation, integration and re-architecture. But more of all, is about the way considering the very same topics, issues, environments and enterprises with a new eye.

more to follow, stay tuned and if you would like help establishing a SOA strategy for your specific case, give me a shout!

No comments: