Last week I attending the INTEROP conference in New York, I was somewhat surprised that they actually had an SOA track, with sessions, such as "SOA: Hype or Happening" and "Security and Governance of Online and B2B SOA Traffic". While I attended both sessions, I wanted to focus on the "SOA: Hype or Happening" discussion as a follow-up to my article SOA the Platform: Part 1.
This fast-paced, lively session included a panel of very senior-level technologists: Phil Fritz, Program Director SOA Management, IBM; Michael Stamback, Director Product Marketing, Oracle; David Pawloski, Vice President, Strategic Alliances; Prabhjot Singh, Vice President, APM Technologies; and Andreas Antonopoulos, Senior Vice President and Founding Partner, Nemertes Research (moderator). The agenda was simple but effective, and followed a standard question and answer format.
My main objective was to gain insight into the status of SOA, not just from the vendors, but also from individuals attending the conference. While the panelists, for the most part, represented organizations that sold cutting-edge SOA products, I did not hear any statements which attempted to tout one vendor's product versus another, which I thought was rather magnanimous.
Since all panel members supported the SOA platform, I did not quote individual members, but tried to state the essence of their responses. I believe that if there was any take away value to this session, it was not in the individual product strengths the panel member company's possessed, but their corporate philosophies on how to use, when to use, or why to use SOA.
Moderator: What is SOA?
Panel: What do you think SOA is? [At first I though this was a flippant remark; but, after some further elaboration, it was clear that the definition of SOA depended on an individual's interpretation.] SOA is a style of development, which includes application management and service reuse. Most importantly, SOA represents broad industry acceptance of a few common technologies.
One panel member stated that SOA is more of a methodology that promotes organizational change (CA). To define and disseminate what SOA is, he bought copies of SOA for Dummies for his staff.
While IT clearly looks at SOA as a product stack, the definition differs depending on who you speak to, with some individuals looking at it as more of a methodology than a product stack.
Moderator: How many people in the room were implementing Web services and SOA?
While the session was well attended, a minority of people raised their hands to indicate that they were involved with SOA-type projects. But then again, this was a sample of users paying to attend a session at a conference on SOA in order to gather information on the subject, not an SOA users group.
Moderator: Is SOA the glue, an integration mechanism, EAI 2 so to speak?
Panel: No, it is not the glue; it is pieces and parts of applications orchestrated differently, that is, business process management.
SOA is a different way of building applications, such as, the ability of a non-ABAP programmer to access an SAP application, which is wrapped in a Web service or a programmer using Google Maps API, which emit binary instead of XML.
Some financial organizations may have 47 different ways of integration with a single application. SOA can provide a smaller set services that can be reused and orchestrated both for internal and external consumption.
Of course SOA can support non-classic uses cases, such as, moving data between heterogeneous databases using an ESB, but there are alternatives to this type of requirement.
Moderator: At what point do you think big SOA, instead of small?
Panel: A large financial company started a project around the design and development of one Web service. This project required governance meetings regarding architecture, security, resources, design review, etc. By other subsequent projects, using the same model, it reduced the governance and planning phase, because they were essential reusing the same methodologies and technologies, this process began to move the organization into a more enterprise-wide approach.
In some organizations, trying to get funding beyond pilot projects can be difficult. SOA is clearly an area where business and IT need to be in alignment. SOA kept in a strictly IT context will go over the head of business leaders.
On a positive note, if you understand the business pain, establish an SOA project and are successful you will get sponsors. You need to talk to the business on their terms and understand their objectives, essentially a bottom-up approach.
It was recommended that a portal project is a good way to go from a small project to a large one. For example, a portal that includes affinity partners is a good project to start small and go big. Essentially, other than the portal itself, all portal services can be external Web services. You would also need to dictate SLA to your development partners, but they would be responsible for developing application (Web service) functionality. Also, security policy must be discussed with the affinity partner. In the absence of concrete security model at design time, it was further recommend that Observer and Decorator design patterns be used to drive out security behavior and serve as a marker interface or temporary stub solution until the concrete security model is specified. [Basically, the Observer design pattern is used to observe the state of an object and used mainly for distributed event handling, whereas the Decorator pattern allows new behavior to be added to an existing class dynamically.]
A SOA project needs to be iterative in its approach, but always include an interim working solution, until agreement on standards and policies can be established. The SOA project and possible COE should be multi-disciplined and include application support, since they have the budget and impact on shared infrastructure.
Today, CIOs are much more focused on cost than technology. SOA needs to be funded as a strategic investment, not a cost of doing business.
Another case study described an organization that did government regulations related processing where their software system needed to be significantly modified periodically. Reengineering the product using SOA reduced time to market by 50 percent. In this case, the business did see an immediate reduction in cost, because of shorter development lead times.
Moderator: Is server virtualization and consolidation (of web service) components onto virtual machines related to SOA adoption? Are there synergies between these technologies?
Panel: In general, there was agreement that this would be an ideal physical SOA architecture and that there are synergies between the technologies.
Audience: SOA is a way to align applications within an organization. However, isn't performance an issue when you need to rely on HTTP when there are other protocols inside the firewall you can use?
Panel: It is important to remember Moore's Law -- that computing performance per unit cost is expected to improve as the size of transistors shrinks, and that the speed at which machines operate will also increase. Additionally, from a time to market standpoint, flexibility usually wins out over performance expectations.
From an SOA perspective, you do not need to rely on HTTP:
- Google Maps API is a form of SOA and does it not rely on HTTP.
- The Navy is using an SOA model and methodology (without using SOAP) to build remote and distributed computing applications. WSDL and XML representations are created as design artifacts with the resulting implementation being delivered in a binary format.
- For organizations that have been using (IBM) MQSeries enterprise-wide, SOA conceptually is not a new concept at all.
Moderator: So, is SOA Hype or Happening?
SOA has been happening for quite some time now. It's not a silver bullet, but built on solid XML standards, which have a long history of proven industry usage.
Prima facie evidence of SOA's maturity was established by citing the shear number of SOA technologies already in use (i.e. ESB, BPM, etc.).
A recent SOA survey indicated that adoption rates were up 7 percent, with only 10 percent of the organizations surveyed indicating no consideration to moving to SOA.
With SOA appliances and advanced Business Process Modeling for SOA already in play, we may have already moved into SOA 2 even without necessarily broad acceptance of SOA.
For More Information