Untitled Document
Is SOA dead, dying, hyped or shaken out? For a number of reasons, these past
weeks have really allowed me to solidify my thinking on SOA and recapture some
of the lost essence of why I initially was a big supporter of this approach.
After years of seeing the term SOA abused for purposes of being associated with
hype and popularity, I need to agree with Larry Ellison's view that the IT industry
is more concerned with fashion than GQ or Cosmopolitan magazine (http://blogs.wsj.com/biztech/2008/09/25/larry-ellisons-brilliant-anti-cloud-computing-rant/).
After all, IT transformation efforts today are seeking the elusive SOA skills,
with those on the buy side not really having the appropriate value proposition
in mind and those on the sell side just selling rehashed application-server
applications and component-based development experience.
SOA was supposed to be the language for alignment of business and IT in the
way that UML was supposed to be the visual representation of that communication.
It seems that both SOA and UML have been commandeered by engineering leaving
business to shy away. After all, nothing turns off the business more these days
than having to explain what they want to IT. Of note, the fact that SOA has
been commandeered by IT is not all IT's fault; business needs to carry equal
blame.
At this week's OMG SOA Consortium I likened the relationship between IT and
business to a dysfunctional marriage. Business takes the attitude that IT should
know what they want without have to fully communicate that, while IT often takes
the approach that the business is unhappy no matter what they do, so the best
they can do is just get something done.
SOA was supposed to fix this problem by allowing the business to define what
they desire as a set of business services. The business is supposed to be able
to ask IT to provide a service to provide financial reporting, charge a customer
for products and services, track an asset's movement, etc.
These services were to be defined by a service level agreement which includes
requirements for availability, policies for access, disaster recovery planning,
escalation procedures, etc. It should also include what inputs the business
will be providing to this service and their expectations for results. While
this level of definition still leaves out a lot of details of the How -- and
we know the Devil lives there -- it gave the business a framework for defining
requirements in a non-technical manner that could be easily mapped into deliverables.
1
Print this article
Email this article
Talk Back!
Write to Editor
