Monthly Archives: February 2009

The Biggest Mistakes I See In SOA Initiatives

There’s a lot of FUD (Fear, Uncertainty and Doubt) surrounding Service-Oriented Architecture (SOA) in the IT industry. Some concerns are legitimate given the number of wide-spread failures have been documented and discussed. After all, would you want to be the IT manager better his/her job on SOA in this economy? Still, most of the FUD is undeserved.

To put things in perspective, there were more actual dollars spent on multi-year, non-operational implementations of SAP in the mid- to late-90’s, than all of the SOA endeavors put together. Still, SAP is going strong and still growing. Let’s face it when something is new, there’s going to be growing pains. The primary question businesses need to ask is, “is it worth the effort?” To that end, there’s lots of great literature on the value proposition for SOA that doesn’t need to be repeated here.

A root problem for SOA is a general lack of either understanding or agreement on a) what is SOA and b) the goal of the SOA initiative. This leads to the SOA initiative taking multiple, simultaneous paths, which if are not joined back together at some point, will appear as a failure. As far as an organization’s approach to SOA, all are valid as long as the process ultimately leads toward resulting agility for the business. Although, if questioned what a truly successful SOA initiative looks like, I would respond:

  • An agreed upon business domain service model that accurately represents the activities and characteristics of the business
  • Establishment of a common set of semantics for the business that are represented by the services
  • Implementation of an appropriate governance model to ensure the business domain service model and the semantics are properly maintained

Clearly, my perspective on SOA is definitely from an Enterprise Architecture perspective. Which is a great lead-in into the issue at hand, which is the biggest mistakes of SOA initiatives.

1.The SOA initiative is really nothing more than JBOWS (just a bunch of web services) focused on providing data to a presentation layer. This is not SOA, this is client/server but with PowerBuilder being replaced with an HTML/Ajax interface. It’s okay for the SOA initiative to have a technical focus, but the resulting services need to represent business capabilities and expose a matching contract.

2.The first step in the SOA initiative is selection of an SOA tools vendor. Forward thinking is great, but focusing on development and governance before the first service model is designed is getting too far out ahead. With SOA being a hot topic, it’s natural for IT personnel to want to sharpen their skills and keep their resume current, but, the can also be a death knell to the organization’s SOA initiative.

3.Allow services to become a battleground for power. In large organizations, there may be multiple groups building services. No doubt, a certain number of these groups will leverage this opportunity to take a lead in an ongoing power struggle. Services need to be thought of as Enterprise assets if they are to be a successful part of a successful SOA initiative. Services held hostage will lead to redundancy as a side-effect of the power struggle, therefore, undermining a key value proposition for SOA in the Enterprise.

There are probably other mistakes that can take an SOA initiative astray; these just happen to be the ones I have seen most often. As you can see, they really are not that different than mistakes associated with other IT initiatives we have seen in the past or we might see in the future. SOA does require at different set of skills for design than required for a typical IT application development effort and businesses should ensure that they agree on their goals for the SOA initiative from the onset.

If My SaaS Also Exposes an API, Am I Also A PaaS?

Here's a great example where an agreed-upon taxonomy of Cloud Computing terminology would really be helpful. Software-as-a-Service (SaaS) is fairly-well understood from both a business and delivery model perspective; that is, if we agree that SaaS is software hosted external to the user and billed on a usage basis versus a license basis. A typical SaaS application provides a user with a client to access the service and stores the user's data in the cloud. There are tons of examples of SaaS applications today, both billed and free models including, Facebook and Google Applications.

However, if a SaaS application, which provides a user interface that a human can use to access the service, also provide an application programming interface (API), does it also qualify as Platform-as-a-Service? The typical PaaS offering has been focused on a coupling of discrete technologies that can be deployed as an integrated offering. It typically has an operating system, some frameworks, a runtime facility and runs completely in the cloud.

Some might also consider a common aspect of these platforms to be that they are deployed and managed as virtual machines and the applications produced on them to leverage elastic computing capabilities. In my opinion, this crosses many aspects of Cloud Computing, including Infrastructure-as-a-Service (IaaS). Thus, another indication that there is lack of agreement on the boundaries between many aspects of Cloud Computing.

However, let's return to our key focus; the border between SaaS and PaaS, and let's look at a well-known entity that meets this criteria—Facebook. Facebook is SaaS. The application manages your social connections and allows you to communicate with your community via text and pictures, both directly and broadcast. Each Facebook account is essentially a unique community with a distinct set of users and connections.

Facebook is also an application platform. The Facebook API allows developers to provide additional services to each of these individual communities. However, Facebook does not host this application. Instead the developer is required to host the application for themselves. Facebook provides a portal to access the new service, provides a facility to allow its community manager to control if the application has access or not and what levels of access are allowed. It also provides an interface to allow each application to connect into community features.

If I draw clear boundaries around PaaS, such that it represents only those offerings that can be deployed as a complete entity, and does not include offerings where the platform is already deployed and accessed via a service interface, then Facebook is not PaaS. However, this means that PaaS is once again a poorly-named IT offering, because, it is a platform and it is offered as a service.

I realize that I do not have a good answer for this conundrum as of this time. I believe the answer lies in semantics and taxonomy, but it is not something one individual can drive alone.