Manage Learn to apply best practices and optimize your operations.

Helping out the SOA vendors

David Linthicum discusses how many SOA project leaders are calling vendors out on their promises and gives advice to vendors in order to better respond to their customers.

When I wrote about vendor-driven architectures (VDA) in my first ZapFlash, I had a few vendors ask me to look on the other side of the fence. In essence, to consider how vendors can better address the needs of the customer, considering the new drivers with SOA.

So, why do they need help? In essence, vendors are now selling architecture, and not just a product. That seems to be freaking out the sales people and SEs who are used to pre-canned product pitches. Pre-canned pitches are the wrong approach, when taken in context of the larger strategic advantage of SOA. Basically, they are attempting to sell a strategic, systemic change to IT, but are attempting to do it as an in-a-box solution, which looks rather silly to those who build SOAs. Indeed, many SOA project leaders are calling vendors out on their promises, and the vendors don't know how to respond.

Truth be told, I can't believe the unsophisticated approaches many vendors have when selling their product. Indeed, I'm taken aback weekly by a vendor pitch that just does not flatter their technology, perhaps even making them fall a few notches in my opinion, and I'm sure in the opinions of their customers. But, while many already understand that problem, far too many vendors don't understand where they are going wrong.

Core to this is the issue that many SOA vendors can't explain their own product, or the core problems it solves. They do know how to list buzzwords they think will "wow" their prospects and existing customers. However, in many cases, the customers become further confused, or worse, don't even get the core concept behind the product, not to mention SOA.

That's a pretty drastic thing to say, and you would like to see vendors argue that point. Truth-be-told, many understand the shortcomings and are seeking direction in strategy and messaging in this emerging, complex marketplace. Those are the smarter guys out there, and chances are, they are going to be the guys who succeed. Those who continue to pitch product, without context, and lack a clear understanding of SOA, will lose the game before it really begins.

The trouble continues…many vendors, when asked about their closest competitor's products, have a very well rehearsed response, and point out (spinning really) the differences between their offerings. In essence, they explain how the other guys "are really bad" and we "are really good." Meanwhile, in another conference room far away, the same conversation is occurring in reverse.

Unfortunately, the sales teams, even those armed with the smartest SEs, fail to deliver more than a very canned and ineffective pitch and/or briefing, and end up looking bad and confusing people they should really not confuse. This is not a trend; it's an outright epidemic.

What's going wrong

There seem to be a few core issues out there that haunt most SOA vendors today. While the number of issues are complex and far reaching, I believe we can boil them down to a few key 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 problem domain that fit your definition, the truth is, enterprises are like snowflakes…no two are alike. 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 a 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 pattern of the products.

Let's just bolt something on, refers to the fact that most vendors attempt to sell "magical technology" that, when bolted onto the existing infrastructure, will indeed create a SOA. That never works, and, in many instances, they are actually making things worse by making the customer's existing architecture that much more complex. The hard truth is that SOA, as the "A" implies, is architecture. That means there must be a systemic change in the use and configuration of the IT resources. In the SOA world, this means abstracting things that are services and configuring those services into solutions. An ESB or a governance tool won't do that. It takes careful planning, execution, and selection of the right technology. There are many best practices and a true lifecycle to consider here; it's never technology driven. As ZapThink has been saying for some time, SOA is something you do, not something you buy.

Get smart now

So, what do you do? The right approach to this problem is something that many vendors don't even think about until it's too late. The core pitch should be around how the product solves a customer's specific problems, as well as a detailed, easy-to-understand approach to the "solution." Even (gasp!) tell them what problems you don't solve, and perhaps recommend other products that provide a better fit. Keep in mind, you're selling an approach/architecture first and a technology second. One won't work without the other. Many are missing that point.

You start with an understanding of the customer issues, including a quick and dirty intro into SOA at a holistic level, but narrowed eventually to their vertical. Then, drill down into their problem domain (a.k.a., project), and then and only then, identify pain points that your product could resolve, and how, specifically, you can do that…Step 1, 2, 3, etc.. So, that means spending the time going over their "as is" architecture in detail, including interfaces, semantics, platforms, integration approaches, etc., and then understanding their core objectives for the new architecture.

From there you can use this basic information to determine the foundation for any new architecture…the benefit to the business, or the ROI. You need to figure out the value of doing something different, and thus the value of the architecture and the value of the technology you're looking to sell that will become a component of that architecture. Are you getting the pattern here?

At the end of the day, it's just a matter of matching problem patterns with solution patterns, thus looking at what the core issues are that the SOA needs to address, and then determine which technology is right for those patterns. While many believe there are SOA-in-a-box solutions, there really is no such thing, and thus the architecture world in SOA needs to take precedence. Indeed, requirements that I see around SOA are all very different, and thus the technology solutions should be different as well. While it would be a nice world if a single vendor would always be the right fit, those scenarios are actually few and far between.

SOA vendors need to embrace a more consultative type of selling approach. So, the vendors who will succeed will have the heart of a teacher, not a salesman. They need to arm those who are going to sell the technology with a clear understanding of the attributes of SOA, and learn how to listen to the core issues around the business, as well as learn how to drill down on the real issues that the customer may not be telling you. For instance, I often hear how well their architecture is currently working, but upon further analysis, find that there are major flaws that need to be addressed, typically around the agility of the current architecture, or the ability to adjust to changing business requirements. The good news for vendors is that most existing enterprise architectures are dysfunctional and are in need of improvement, which is bad news for the architects who have to actually drive the fix.

Another factor is time, and thus the sales cycles. While short sales cycles are the nirvana for the technology sales team, the truth is that SOA typically means much longer decision cycles as many enterprise architects trod through this approach and technology for the firs time. In most instances, the sales cycles will be long and drawn-out, and those SOA vendors who learn how to work within that cycle will find they are best able to help their customer and help themselves. Consider the fact that SOA technology is strategic, and thus the relationship you're creating with your customer, if you're indeed the right fit for them, will last many years.

The ZapThink take

At ZapThink we think that many vendors are finding the "SOA Sell" very new. Most vendors have never sold architecture before, just tactical products that service some specific purpose. All architectures, inclusive of SOA, are really around the right configuration of technology and understanding, and not technology itself. That's a huge change for many, and I suspect most will fail when attempting to change their approach. Now is the time to get some help, figure out how you go-to-market, and learn to love your customers long term.


Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close