<<Speaking at an auto-industry-specific standards group supply-chain workshop this week, my role was to cover the role of SOA in modernizing supply-chain processes. Earlier that day, the group had a separate SOA Technical Committee meeting in which they focused on the charter for that group. After sitting through that TC meeting, I walked away with some interesting observations that I believe are consistent, industry-wide and pertinent to anyone interested in SOA.
1) Where SOA was successfully sold to upper management and invested in, SOA was sold as a catch-all for re-factoring and integration efforts. 2) The group that successfully sold SOA in #1 does not appreciate attempts to discern architecture from technology. 3) For some individuals SOA and Web Services are inextricably linked in their mind and any attempt to separate them results in complete confusion 4) Some individuals believe that SOA requires and Enterprise Service Bus 5) SOA discussions among architects is a very different discussion than SOA discussions inclusive of managers and engineers 6) A common definition for SOA is more than elusive at this point, its become a point of disruption 7) When queried why people believe they need SOA, responses centered around an attempt to a) develop reusable components, b) find an incremental approach away from their legacy environment and c) enable A2A and B2B. Of the above observations, there are two in particular I would like to expand on #3 & #7. With regard to #3 above, and the focus of my subject, I believe there is a danger to using Web Services and SOA interchangeably. Sure, a Web Service can represent the implementation of a service, but in the most simplistic manner possible. The contract (Web Services Definition Language or WSDL) modestly describes a machine-to-machine communications, but totally ignores many other critical aspects of delivering a service to market, such as service-level agreements, security and escalation policies. For the group that wants to operate at this level, I believe they would best served by just committing to Web-Oriented Architecture (WOA) and remove possible confusions that may amount from talking SOA. Using the term SOA to express the functional availability of Web Services layered on top of existing legacy systems dilutes the value of SOA to the market. While there may not be a globally agreed upon definition for SOA, there is a general consensus that the 'A' in SOA stands for Architecture, not implementation or integration. As for #7, I point to my blog entry "SOA is Dead, Long Live Distributed Computing", which is a rant on the industry's fascination with renaming or re-branding old stuff with some new extensions. One individual I spoke with at the event actually believed that distributed computing was a specific approach versus a category of systems design. DCE, CORBA, DCOM, RMI, HTTP, and AJAX are flavors of distributed computing. Anne Manes of the Burton Group used to write a research report for Patricia Seybold Group called, "Distributed Computing Monitor" and it reported on many of the same issues and information that we find surrounding SOA today. Is SOA bigger than distributed computing? To answer that question, we'd need a specific definition for SOA. We can say that SOA is an means for designing a distributed computing system, which is a fancy way of saying that we are trying to introduce as much transparency into system as possible and reduce dependencies which limit scaleability and are fragile. The reason I chose these two issues to expand on is that combined they cause unnecessary (or necessary depending upon where you sit in the IT food chain) problems for the industry. Client/Server is a design paradigm and does not intimate in anyway, shape or form that the components are tightly-bound. Clearly, at the time the client/server design pattern was emerging, there were not as many well-defined standards for messaging as there are now and early adopters had to create a proprietary interface, which translated industry-wide into client/server equals tightly-bound. Likewise, the introduction of middleware that created multi-tiered client/server is simply an attempt to do exactly what people say they need SOA for today as per #7. So, back to the subject of my blog entry, it is my belief that if SOA and technology are used in an interchangeable manner, that the associations and limitations of the underlying technologies will be branded onto the architecture forcing another round of renaming and re-branding in five years. Especially given the attention to the growing number of SOA failures that have been discussed, the likelihood of this happening increases significantly. Moreover, if SOA is bigger than just a re-branding of a distributed computing approach, we need to clearly spell out how this is different than what has come before and not just give lip service to the technology timeline slide that shows SOA as the next stage of evolution. For the record, I do believe SOA is different than just another distributed computing approach. I believe it is a framework (or should be a framework) for the creation, delivery, usage, maintenance and sunsetting of any service. Subsequently, this definition could also be used to answer the question, "Is governance required for SOA?" Since my definition basically describes lifecycle of a service, it would follow that lifecycle management would be required vis a vis some governance process/tool, but this is a topic for another day!>> You can read JP's blog at: http://www.avorcor.com/morgenthal/index.php?entry=entry080904-122516 Gervas
