You've heard it all before; technology should add value to a concept like SOA,
not control it. Lately I've run into SOA efforts that are not playing by that
rule. Indeed, the focus is on ESBs and governance layers, and not on getting
SOA right from an architecture standpoint. I thought SOA was architecture, right?
At issue are the multi-billion dollar marketing budgets that vendors bring
to the SOA world, and thus lead through sheer volume of sales. Those who promote
the architectural value of SOA, perhaps like yours truly, are not being heard
above the noise and flash of the SOA-in-a-box movement that's occurring all
around us. The end state is, and will be, a failed project due to the misuse
of technology, and project managers who do not understand their own issues before
pulling out credit cards and buying technology. Thus, too much focus on technology
is hurting SOA.
Don't get me wrong, I'm not attacking the vendors here. That's just too easy.
What I am doing is pointing out the fact that technology, while being very powerful
and necessary within the world of architecture, needs to occur as an outcome
of the architecture, and not drive it. While most of you will see that as a
logical piece of information, it's still a de facto practice to take an "ESB-oriented"
approach to SOA, no matter what the issues are at hand, or, perhaps an "App
Service-oriented" approach, or a "Governance-oriented" approach,
or... Okay, I'll stop.
The result, in many cases, is not something that does not work; it's something
that does not work as well as needed. Thus, many settle for sub-optimal solutions
that have to be redone every few years to keep up with business demands versus
solving the problem once and for all, maturing the architecture over the years
and not having to keep replacing it.
The approach is simple. You start with your core requirements, understanding
all aspects of the business, existing services, existing data, processes, etc.,
and then create a vision of the end state architecture and a complete map for
getting there. You understand patterns here, not instances of technology, and
once understood, back the correct technology into the problem domain, making
sure that the core requirements are met.
I would suggest following this processes, at the very least:
Print this article
Email this article
Talk Back!
Write to Editor
