Helping out the SOA Vendors
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.