Last month I wrote about vendor-driven architectures (VDA), and 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.
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 take a few steps back in my book, and perhaps in the opinions of their customers.
Core to this is the fact 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.
Case in point, 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, but 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 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.
You start, however, 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.
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 determining which technology is right for those patterns. While many believe that 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 so should be the technology solutions. While it would be a nice world if a single vendor would always be the right fit, those are actually few and far between.
SOA vendors need to embrace a more consultative type of selling approach. So, the vendors that 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 main point is that this is all very new. Most vendors have never sold an 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.
Subscribe to Eclipse Developer's Journal Email News Alerts
Subscribe via RSS
