Perhaps you're concerned it's a misguided attempt to build
applications around generalities instead of specifics. Maybe you think
object-oriented (OO) analysis had it right -- that building a model of
the things that make up a business is better than building a model of its processes.
Possibly, you're among those who prefer informal conversations
between business managers and programmers, and think user stories and
use cases are blinders that limit developers' ability to design
creative solutions.
Whatever your objection, it doesn't matter. In theory, if you have a
need The Marketplace will satisfy it. In practice, the languages
marketplace doesn't work that way. SOA is in your future whether you're
shouting "hurray!" and leading the parade or grunting "harrumph" and
wishing you'd taken up welding instead. To understand why, list what
you want from a language.
The big four from OO-land -- abstraction, encapsulation,
inheritance, and polymorphism -- would almost certainly be on your
list. SOA's run-time binding? Probably. Recursion? Maybe, if you're a
sophisticate. Performance? Sure.
If you're a CIO or CTO running IT in a business that plans to be
around for awhile, none of these occupy the top spot. What matters most
is at least ten years of marketplace credibility. That's what drives
vendor support and a reliable supply of top-notch developers.
Like it or not, technology comes after this entirely logistical
consideration. It's why old-fashioned mainframe COBOL lasted as long as
it did in spite of its technical deficiencies, and why companies are
finally phasing it out.
Want ten years with confidence? It's SOA via .Net or Java. That's it.
SOA is a clear case of vendor push, not market pull. This isn't
necessarily a criticism: Vendors, not customers, should be the source
of product innovation. Where customers can help vendors is product
refinement.
My concern is that industry's visionaries bet the farm on an unproven theory.
The chain of logic began with Hammer and Champy's Reengineering the Corporation
-- the seminal work that first caused business leaders to think of
their organizations as collections of processes rather than as
collections of people, functional units, competencies, or what-have
you. (And kudos if you recognized the false dichotomy: Organizations
are collections of processes, and of people, and of functional units, competencies, and all the rest. Not or.)
While this was going on outside IT, object-oriented analysis and
design was taking over inside IT. The connecting point: IT's job, as
then understood, was to automate one or more roles in various
business processes. This made sense: Roles are things. Get their
behavior and interfaces right and you should be able to string them
together as necessary to automate some or all business processes.
If you really wanted to be cool you'd add business process management (BPM) software to the mix to handle the stringing.
SOA creates a deeper connection between the process view of business and how IT translates business requirements to software. Service is the software mirror of process.
To do SOA properly means having a solid understanding of the processes,
sub-processes and sub-sub-processes that make up your business and how
they fit together.
Once you have that understanding you'll be in a position to create
software that supports the process hierarchy. And, as processes evolve,
you'll be in an excellent position to track that evolution with changes
to service definitions.
It's a great theory. It's a really great theory.
It's also an untested theory. Very few businesses understand
themselves well enough to easily create a provable services model of
the enterprise; those that don't and dive into SOA first have to create
one, at considerable time and expense. And that doesn't take into
account the need to decide whether to normalize responsibilities that
can't or simply haven't yet jelled into formally defined processes.
Then there's the potential loss of flexibility. SOA can almost
certainly make companies faster. Speed, though, is quite different from
agility. Speed means doing what you do more quickly; agility means
changing what you do quickly.
Services are supposed to be loosely coupled, to facilitate agility.
That's the theory, at least. Maybe it will turn out that way. I hope so.
Lost in the shuffle is something basic: Programmer productivity.
Friends who are hands-on with such matters tell me the available SOA
development environments are less than half as productive as products
like PowerBuilder and Delphi were, back when they were viable.
It's an unnecessary lapse, and tells me those who are driving SOA need to spend more time with those who are using it.
