Over the past couple of days I have heard the phrase “pure SOA“. What is a “pure SOA“? Is it an SOA implemented with Web services, SOAP, XML and UDDI? Is it and ESB added to those things? Just what is it?

The standard definition of SOA, as defined by the OASIS SOA Reference Model TC, states:

“Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.”

I don’t see anything about an ESB, SOAP, Web services, nor UDDI in there. Could I use Enterprise Application Integration (EAI) as part of an SOA implementation? How about CORBA. Java Remote Method Invocation (RMI) or perhaps .Net Remoting? Do I need an ESB to have an SOA? What about Representational State Transfer (REST) services, are they pure SOA?

Truth be told, there is NO such thing as a “pure SOA“. All the things mentioned here are part of various adoption blueprints. An SOA implementation can contain of Web services, UDDI, SOAP, an ESB and RESTful services. Web 2.0 technologies, CORBA, .Net, and RMI can also be part of an SOA implementation. As a matter of fact not all services need to be experienced through software, I have discussed the notion of Hardware as a Service (HaaS) here a couple of times now (unconventional thinking).

Not every component in an SOA implementation will be realized as a service component, let alone a Web service. For those portions of an SOA implementation that are experienced as services, their interfaces to the service component must be standards-based at the bare minimum. Now those standards may or may not be Web service standards. There are certain types of SOA implementations that may not lend themselves to Web service and Web service standards, I call these “hybrid” SOA implementations because they support everything mention here at the same time.

So if you here someone say that something isn’t “pure SOA”, explain to them that beast doesn’t exists.

Some people seem to think that Web 2.0 is strictly for teens and twenty-somethings prowling MySpace and YouTube, they are showing their age.  Web 2.0 technologies, including but not limited to blogs, wikis and mashups, are growing up and are hard at work on the Web sites of major companies such as General Motors Corp., FedEx Corp., British Airways plc and Sun Microsystems Inc.

The difference between the early days of the Internet and the current Web 2.0 has been described as "a shift from destination to connection".  In the early days of the Internet it was all about one’s destination.. You’d go to places like FedEx.com, Amazon.com, or Ebay.com.  Web2.0 is about connectedness, relationships, and collaboration.  The Internet is becoming the Global Interconnect.  This emphasis on connection is translating into more blogging and more wikis, but is also transforming the way software applications are created in the form of services, particularly Web services.  Web services, the modular components that allow systems to interact and connect with each other over Internet protocols, are a primary enabler of this move toward more connection.

Mashups and other Web 2.0 capabilities as significant business opportunities for enterprises.  These new interfaces can make customer experiences with organizations more enjoyable, while making them more productive.  Ajax [Asynchronous JavaScript and XML] enhacne applications can provide users with that great WYSIWYG experience which could then call a Web service, could be an orchestration or worflow, to handle business logic.

Of course, these pockets of Web 2.0 progress can be found in many enterprises. But it remains to be seen whether companies can sufficiently rein them in to serve their most strategic business objectives. And can these disparate technologies work in concert to achieve broader corporate goals? There is some fear that doing so could destroy the transparency, spontaneity and simplicity that make the tools so valuable in the first place. At the very least, however, there is now an opportunity for IT departments to exercise a little more control over the dissemination of Web 2.0 products in the enterprise

Justifying payback on a service-oriented architecture (SOA) investment can be relatively straightforward and productive for organizations as long as they know what to expect from SOA and how to manage or govern SOA projects.  ROI needs to be analyzed through the lens of business objectives, not technology ones.

A big promise of SOA is that it enables affordable, consistent integration of heterogeneous applications across the enterprise using open standards, Web-based technology. Open standards not only make interoperability and reuse possible, but they also reduce development costs by opening interfaces and providing more options. The flexibility of SOA makes core system upgrades less risky, and more manageable, effective and secure.

However, measuring ROI on SOA is far from a walk in the park. Before embarking on an SOA project, companies need to have a governance plan that addresses decision-making, measurements and controls, and achievements from SOA.

Organizations must have a plan that integrates its people, processes, assets and business goals.  It is recommended that organizations must develop a strategy to create, deploy, maintain and enhance effective SOA governance for each stage of the project.

It is essential that organizations determine their goal of measuring ROI before they deploy an SOA solution.  Of course, not all SOA projects are created equal — some projects are easier to measure ROI on than others.

Some factors to help determine ROI on SOA include:

           Business Agility

          Organizations can compare the time required to modify or add a feature to a non-SOA application against performing the similar tasks to a service in order to determine its ability to respond to every changing environments and requirements.

            Shared Service Reuse

Determining the number of reuse instances of shared services can be an effective measurement of the ROI provided by an SOA.  Reusing shared services leads to cost avoidance or reduction of developing, maintaining, and operating services that are only useful for a specific purpose or organizational element.  For organizations to calculate ROI of shared services there are some additional fundamental metrics required:

• Cost to build/maintain/operate a shared service.  Cost of having a shared service

• Cost to build/maintain/operate pinpoint service.  If organizations have deployed an effective SOA ecosystem this should be similar to that of a shared service.

• Cost to reuse an existing service developed externally.  This cost is incurred by organizations when services, developed by someone else, are reused.  It is crucial that organizations control this metric in order for an SOA to succeed.  Reusing a service is in essence integration and an SOA must be structured to manage the costs of integration.

Web Services Adoption

          The number of Web services can provide an indication of the breadth of adoption for the underpinning technology for SOA.  It can also be a negative indicator as well, the larger number of Web services would indicate that the reuse of services is low and that the SOA effort needs to be revising.

            Consumers of Shared Services

The number of consumers reusing shared services can assist organizations in measuring the SOA adoption level and breadth.  This indicates the level of shift in the cultural, sociological, aspects of the organization.  While this metric may not be directly correlated to the business benefits for SOA, it is an important measurement nonetheless.

Justifying payback on a service-oriented architecture (SOA) investment can be relatively straightforward and productive for organizations as long as they know what to expect from SOA and how to manage or govern SOA projects.  ROI needs to be analyzed through the lens of business objectives, not technology ones.

A big promise of SOA is that it enables affordable, consistent integration of heterogeneous applications across the enterprise using open standards, Web-based technology. Open standards not only make interoperability and reuse possible, but they also reduce development costs by opening interfaces and providing more options. The flexibility of SOA makes core system upgrades less risky, and more manageable, effective and secure.

However, measuring ROI on SOA is far from a walk in the park. Before embarking on an SOA project, companies need to have a governance plan that addresses decision-making, measurements and controls, and achievements from SOA.

Organizations must have a plan that integrates its people, processes, assets and business goals.  It is recommended that organizations must develop a strategy to create, deploy, maintain and enhance effective SOA governance for each stage of the project.

It is essential that organizations determine their goal of measuring ROI before they deploy an SOA solution.  Of course, not all SOA projects are created equal — some projects are easier to measure ROI on than others.

Some factors to help determine ROI on SOA include:

           Business Agility

          Organizations can compare the time required to modify or add a feature to a non-SOA application against performing the similar tasks to a service in order to determine its ability to respond to every changing environments and requirements.

            Shared Service Reuse

Determining the number of reuse instances of shared services can be an effective measurement of the ROI provided by an SOA.  Reusing shared services leads to cost avoidance or reduction of developing, maintaining, and operating services that are only useful for a specific purpose or organizational element.  For organizations to calculate ROI of shared services there are some additional fundamental metrics required:

• Cost to build/maintain/operate a shared service.  Cost of having a shared service

• Cost to build/maintain/operate pinpoint service.  If organizations have deployed an effective SOA ecosystem this should be similar to that of a shared service.

• Cost to reuse an existing service developed externally.  This cost is incurred by organizations when services, developed by someone else, are reused.  It is crucial that organizations control this metric in order for an SOA to succeed.  Reusing a service is in essence integration and an SOA must be structured to manage the costs of integration.

Web Services Adoption

          The number of Web services can provide an indication of the breadth of adoption for the underpinning technology for SOA.  It can also be a negative indicator as well, the larger number of Web services would indicate that the reuse of services is low and that the SOA effort needs to be revising.

            Consumers of Shared Services

The number of consumers reusing shared services can assist organizations in measuring the SOA adoption level and breadth.  This indicates the level of shift in the cultural, sociological, aspects of the organization.  While this metric may not be directly correlated to the business benefits for SOA, it is an important measurement nonetheless.

There have been many books published that characterize the stages people go through upon learning that they are not long for this world.  One such set of stages, discussed in “Death and Dying” by Elisabeth Kubler-Ross, is Anger, Denial, Bargaining, Depression, and Acceptance.  What if there was a similar set for characterizing what people go through when adopting, not adopting, SOA.

Context

Paul, an architect, is sitting in his office, hard at work as usual, and in walks the CIO.  She sits down across the desk, and with a smile eerily dragon-like because of its toothiness, she says, “Paul, I’m sorry to tell you, but you have a terminal case of SOA.  We expect an enterprise-wide implementation in six months.”

Now, Paul knows that “ain’t gonna” happen, but he smiles anyway and says, through clenched teeth, “Ok chief”, as he remembers that he still has 12 payments to go on that  Maserati.  Now the clock starts ticking and he enters the stages:  Dumbfounded, Rationalization, Euphoria, Depression, and Acceptance.

Paul’s Reactionary Stages

Dumbfounded:  “SOA?  What the heck am I supposed to do with this? I can hardly spell SOA! Not only that, I’ll bet that the CIO can’t spell SOA, either.”  So he stares at the concrete wall for exactly 38 minutes, the arbitrary amount of time it takes for brain cells to begin to atrophy when an idea refuses to make sense, and then decided he needed a drink.  Off to the bar.   There, he found a host of IT folks staring into space while guzzling “fire water” and mumbling SOA under their breath.  He orders a drink and opened his laptop to study.

Rationalization:  Ok, so Paul began to figure out SOA after his fourth “fire water”.  Sure, we can do this.  Just build some services and put them out on the server and anyone can use them.  Yeah, that will work—won’t it?  We don’t need to throw out all our legacy middleware.  This might be the excuse we need to bring in a whole new generation of middleware, starting with those ESB “thingys”.  And business analysts to take the burden of defining the business processes.  Yeah, this just might work.  So, Paul kept scanning, ignoring the little man in his head screaming “it can’t be that easy”.  Woe to he who drinks and reads product literature at the same time.  That’s the prime time people encounter the dreaded vendor “markitecture”.

Euphoria:  The dictionary defines, “Euphoria” as “as feeling of great happiness or well-being”.  The little guy screaming in Paul’s head defined it as – “sucker!”  Ok, so that’s a little harsh but keep in mind, Paul’s buying into the vendor markitecture.  SOA will let you get your business people to design their own systems, they say.  SOA requires no change in your approach.  Buy our products and your SOA will build itself.  Services are just the same as objects and components, so we’ve been doing it for years.  We’re all about business transformation, so buy our widget library.  Paul goes floating on a cloud of this kind of markitecture and then……

Depression:  The cloud begins to dissipate and he is in freefall.  The ecosystem components that he bought are functioning fine but no one can get the service interactions to perform in accordance with the requirements.  Worse yet, he spent three weeks selecting and ESB, and now his team has sat around for another three weeks saying, “now what?” Oh, and don’t get me started on processes.  What are they, by the way?  Are services processes or are processes services?  Who owns these processes anyways?!  After a three month bout with depression, it has dawn on Paul that he can’t do it alone.  SOA is the responsibility of the business as much as it is his.  He establishes an SOA Competency Center.

Acceptance:  Paul decides to treat SOA as a discipline rather than simply an integration exercise.  He starts from a business perspective and the products come after.  The organization trains people to be service providers, to capture best practices, and to organize themselves with the right roles to manage and maintain processes.  He tracks the failures and monitors the successes — to learn.  SOA isn’t a technology innovation.  It’s an opportunity to make systems more agile by mimicking business processes rather than machine code.  The good SOA architect buys ecosystem components only after understanding how that will be utilized in specific scenarios.  He takes measured steps to ensure each service artifact is governed and the processes being used are under service-level agreements (SLAs).  He accepts that SOA is a long-term value proposition, not a short-term fix.

Moral

So, there you have it.  SOA stages to acceptance.  They may be depressing but they help depict what to avoid.  SOA isn’t something organizations will just choose to do— it is something that will happen to them.  If they approach it as a discipline, they may find it won’t kill them.

Note: The architect, Paul, in this fabricated story is simply a typical enterprise architect and is not meant to portray anyone in particular. 

 SOA and wearable computing?  While some people think this may be a bit too far fetched, then again maybe not.  There is technology to place a small screen on my glasses, perhaps put a keyboard on my arm and connect it to a satellite or cellular network.  There are applications for this type of technology today, including outfitting war fighters with complete information systems strapped to their bodies for use in combat.  It can’t be much more expensive that a pair of Diesel jeans.  Also, you have to love a technology where you can check your stocks, email, update your personal blog, and fire a round at an insurgence guy, all while running from building to building in Iraq. 

At the heart of this is the notion of ubiquitous computing.  Or as wikipedia define it:

“Ubiquitous computing (ubicomp) integrates computation into the environment, rather than having computers, which are distinct objects.  Other terms for ubiquitous computing include pervasive computing, calm technology, things that think and everyware.  Promoters of this idea hope that embedding computation into the environment and everyday objects would enable people to interact with information-processing devices more naturally and casually than they currently do, and in whatever location or circumstances they find themselves.”

People must admit that this day is coming, if not already here, including cell phone that are really small PCs, microwaves that can set there on time and calculate the cooking time for three potatoes, and information systems in the cars that we drive that not only us when the oil needs changing, but schedules the appointment at the dealer, and calls someone with you location to remove you from the wreckage when your airbag deploys.

Considering the notion of ubiquitous computing, the larger question is the paradigm for communications in and between all these different devices that no longer look like traditional computers.  The basic principles behind SOA are the most applicable here.  If you consider all these new devices as collections of services and abstracted data, then the level of service use between them will be the next logical step.

Considering this architecture, we simply deal with each device as a system unto itself with a physical data structure, abstracted data, services, composite services (mashups), and perhaps some processes as well.  From there the services in the device are available to other devices, computer systems, and most important to an orchestration or process layer where the interaction with all these devices and computer systems can be defined in terms of business solutions.

Thus, an replenishment service, executing on a small device say PDA or cell phone in size, could reach out and invoke a logistics service, as part of an enterprise SOA, in order to delivery a needed product.  The logistics service could in turn schedule a delivery by invoking services inside a fleet of delivery trucks.  In turn, another service on the PDA device could track could track the progress of the delivery, and estimate to the PDA user when the product would arrive.  I think you get where I’m going with this, including all computing power in an SOA to make the architecture more valuable.

This notion of ubiquitous computing is the larger paradigm that I’ve discussed a couple of time here when I talked about unconventional services and is doable today.  Our daily lives are filled with all sorts of hardware devices, which have become second nature to us (i.e. PDAs and cell phones) that could potentially provide service experiences I know of a company that is exploring similar applications of SOA technologies. And no I can’t you who it is so don’t ask.

Security Assertion Markup Language, better known as SAML, is a protocol for federated single-sign on, is being leverage quite heavily in the SOA arena, but what about agile wdevelopment world of Web 2.0?  In order for SAML, now in version 2, to work in the Web 2.0 it would have to "lighten up". Sun Microsystems has a project, Project Lightbulb, that is intended to provide a lightweight means of federating identities, so users can sign in with a single authentication key and move seamlessly between all sorts of mashed up and recombined Web services projects.  Poject Lightbulb is part of of Open Single Sign-On (Open SSO). The concept behind Project Lightbulb  is to have URL-based identity where the user is able to participate in blogs and wikis and other Web 2.0 collaborative applications without a pre-existing relationship with the application.  OpenSSO is designed to provide a way to create an federated identity via SAML 2.0 with very little coding. This would solve the problem developers of Web 2.0 applications have with the heavyweight nature of SAML 2.0 implementation. "Web 2.0 developers say SAML 2.0 would be useful because it’s widely implemented, secure and industrial strength," he continued. "On the downside people saw it as complex. XML signature seemed like a barrier to getting SAML. These were people using lightweight languages like PHP, Perl, Python and Ruby." [Pat Patterson Sun Microsystems] Many modern Web services seem to have settled on Linux with a lightweight language such as PHP and Ruby, the Lightbulb project (originally a pun because it was to fit into the LAMP stack) is intended to provide the security of SAML 2.0 implemented through a scripting language, Patterson said. This avoids the problem of having to maintain a repository of passwords and authentication data on a server for a simple developer blog. "Maintaining passwords in a repository was becoming siloed," he told the audience for the Webcast. "People wanted to get to a federated identity management system where the user can authenticate with a third party and access a variety of sites with one password. Effectively the PHP site forgets about passwords and uses authentication."  [Pat Patterson Sun Microsystems] Currently the Lightbulb project is only available for PHP, but Patterson said implementations with Ruby and other scripting languages are in the pipeline. He called for developers to join the project and extend it. He said Lightbulb is already attracting participation from developers in the U.S., Europe and even China.