As the SOA biz begins to become more mature, I'm seeing certain patterns emerging that are separating the good versus the bad vendors, and their technology. These are patterns that you should look for as a user of SOA technology, or if you're a vendor this is some good self analysis. Here are just 3, I have many more.

Pattern 1: The ability to be self critical.

Denial isn't just a river in Egypt, and I've seen SOA technology providers, time and time again, ignore the elephants in the room. These issues can range for failure of standards to not understanding the essence of SOA as a concept, but not addressing these issues quickly can lead to the failure of the technology, and thus the company itself. Typically, the causes here are culture as well as market forces. You know...that guy who never wants to hear bad news.

To avoid this pattern promote a culture of self criticism, and make sure the issues are understood and corrected before the market or the customer gets wind of them. Seems easy, but it's a systemic problem within many SOA technology companies today.

Pattern 2: Promote a culture of quality.

In my past lives at CTO, quality was always in the top of my list, even though many consider testing boring and a drain on resources better spent on building new functionality. The reality is that SOA technology, by its very nature is complex, and testing this kind of technology is problematic since you have to consider so many domains and usage scenarios. However, not testing means that critical information will be lost by the end user, or the stuff just won’t work as advertised.

To promote a culture of quality, quality must be an issue from the top down, and part of the overall culture of the company. This includes incentives, and allowing anyone in the organization to bring up quality issues at any time, even if it means delaying delivery.

Pattern 3: Be honest about the capabilities of the technology.

At this stage of the game SOA is not well understood by those selling it and most have never seen a problem domain that they don't like, and thus lead with the technology, not understanding the requirements until later in the sales process. This is a huge mistake.

The reality is that all SOA problem domains are different, and SOA technology is very different as well (governance, integration, orchestration, identity management, etc.). So, you must first understand the problem patterns before defining solution patterns, and thus technology to leverage. While your product may be a fit in some instances, in many instances it won't work. You need to understand when that fit is not there and learn to walk away, and spend your sales energy with customers who will find the technology valuable.

Let me know if you want more.

Posted by Dave Linthicum on October 9, 2006 07:10 AM