Where the SOA Technology Vendors are Falling Down

Where the SOA Technology Vendors are Falling Down

There seems to be a few core issues out there that are haunting most SOA vendors today. While the number of issues are complex and far reaching, I believe we can boil them down into a few key talking points, including:

• Let's talk not listen.
• We're a hammer, thus you must be a nail.
• Let's just bolt something on.

Let's talk not listen refers to the fact that many vendors are so bound to their messaging, collateral, and sales pitches that they don't seem to find the time to listen to the issues of the customer before proposing a solution. While it would be nice if everyone had the common courtesy to have a SOA problem domain that fit your definition of SOA, the truth is that enterprises are like snowflakes…no two are alike and in order to propose the correct solution you have to spend the time understanding what the native issues are. In fact, I would recommend an 80/20 rule. Spend 80 percent of your time listening, and 20 percent of your time talking. You'll be surprised how much better things go.

We're a hammer, thus you must be a nail, refers to the fact that most SOA vendors sell a particular product that does a particular thing. Thus, when looking at the unique issues of the customer, attempt to force fit the technology no matter what the architectural issues are. For instance, when selling an data integration solution all SOAs that they see are data integration problems, ignoring the need for behavior and transactional integration, even though they are needed, because those concepts don't fit into the patterns of the product.

Let's just bolt something on, refers to the fact that most vendors are attempting to sell "magical technology," that when bolted onto the existing infrastructure will indeed create an SOA. However, that never works, and in many instances they are actually making things worse by driving their existing architecture to be even that much more complex. The hard truth is that SOA, as the "A" implies is an architecture, which means a systemic change in the use and configuration of the IT resources, and in a SOA world means abstracting things as services and configuring those services into solutions. An ESB or a governance tool won't do that, it takes careful planning, execution, and selecting the right technology. There are many best practices and a true lifecycle issues to consider here, it's never just technology driven.

Source: http://weblog.infoworld.com/realworldsoa/archives/2007/12/where_the_soa_t.html