Insights about SOA

From "Why REST, WS-* and technology are the problem, not the solution" by Steve Jones:

"...I'm really beginning to feel that IT, and most especially the software part, has some form of terrorist organisation going whose job it is to ensure that the business always looks on IT folks with disdain."

"Pitching REST, WS-*, ESBs etc is exactly what SOA should not be doing. Its about time that IT started looking at genuine business cases and signing up to explicit measures. Who cares if you use REST, WS-* or flying monkeys to do something, if you've committed to delivering a 10% increase in sales then the choice is yours."

"By continually pitching a technology centric view of the world IT will continual to marginalise itself and prevent any genuine progress being
made."

From "Whipping the QA Process Into SOA Shape" By Wayne Ariola:

"Provide visibility. When exposing business information internally, or by sharing data with partners externally, the businesses goal is to demonstrate that each part of its system is reliable. Visibility will ultimately promote trust. Trust will ultimately promote reuse of these business assets."

"Internally, the organization has a distinct goal of promoting reuse of business assets. The challenge of reuse is truly a cultural shift in the way that developers and architects have traditionally delivered projects. Given this long-standing cultural barrier, the quality metrics need to tell a very distinct story for the internal constituents. The data should give the internal organization the confidence and trust that the business asset is robust enough for the application. The negative case is also true: The architect should also be able to determine that the service asset is not robust enough for the specific application."

"Promoting trust for an asset must begin early, as soon as the asset is created. Visibility into asset quality helps drive the development cycle and promotes trust for later reuse. In order to promote trust early, the business must define policies that govern the different aspects of the services life cycle, runtime and design time."

From "What is SOA?" by Eric Roch:

"Many IT focused SOA efforts have become an easy mark those selling SOA products since SOA now requires governance software, registries, an ESB, a SOA Suite or what ever the particular vendor is selling. I recently did an audit of a company that spent $18M on software, hardware and services that had no service oriented applications after 18 months with none in sight. The enterprise architecture group designed it all and had it built but no one knew what applications were going to run on it. I was literally told by IT that when I talked to the business that I could not use the term SOA because they already viewed it as a failure. This is the disasterous results that occur all too often when IT shops take this type of approach to SOA."

"Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out." Well maybe these companies should have spend less time installing software and building frameworks and more time understanding what business processes could be impacted by removing poor interfaces or eliminating bottlenecks or providing needed information faster (just to name a few). That “stunningly beautiful SOA infrastructure” is worthless without business applications running on it!"