To add value by entering into a partnership should be a no-brainer. You strengthen your own commercial proposition by adding your partner's logo to the brochure, and you get access to their expertise, R&D input, product range and customer base. Unless those regular meetings blossom into love, you also get to avoid the cost, in time and money, and possible value destruction, of full-blown M&A. Partnerships only last as long as you like each other, and they're cheap to dissolve once the split comes.
That's the theory, anyway. The biggest "should" in any partnership is that the customer should get the same only better. We buy our IT from a vendor, fine. We buy our IT from a vendor who's in partnership with, let's say, a consultant, and we get the R&D benefit of all that market insight, market research, et cetera. If a specialist software developer is in partnership with one of the big names, the idea is that the compatibility is enhanced between the operating platform and the specialist application. Partnerships don't only happen between IT companies and consultants, and they come in a whole range of shapes and sizes, but the principle underlying all of them is: two heads are better than one, right?
The potential problem with partnerships is that they're marketed, and the potential problem with marketing is that the hype sometimes outstrips the reality. If an effective partnership brings together the eggheads of two companies, but an over-hyped but ineffective partnership just brings together the airheads, it becomes imperative to be able to spot the differences between the two. Sometimes, this is just a matter of asking, "When did it start?" A partnership that "just happened", or that was de facto in operation before anybody thought to promote its existence, is probably a true expression of synergy. It's a relationship that has evolved in the normal course of business.
Or you might ask, "What's it for?" A partnership of substance, if it was formally brought into being by the two parties involved, will tend to have a coherent purpose, and probably an end-date as well as a starting point. The purpose will be explicable in a way that passes the 'opposites test'*. These two partnership styles, evolved and purpose-driven, are then capable of being benchmarked against customer expectation, contract, delivery, functionality, response time, support. They are often characterised by openness, both between partners and vis-a-vis the client, with NDAs in place as a given. A corporate culture that is conducive to effective partnerships will not invariably express itself by being open, any more than an obsessively secretive company will always make a bad partner. But.
Finding the collaborative core
A third partnership style, which is a further de facto
elaboration of the 'just happened' approach, is that in which a
group of companies, none of which are deliberately partnering
with any of the others, find to their initial surprise that they
share a "collaborative core". Such a partnership is not
necessarily a sell-side or single-discipline phenomenon; it can
occur anywhere in the industry where a group of companies are
clustered around a core application provided by a third party.
And it occurs because, in the words of one contributor to this
article, "that's what programmers are like". Typically in such a
partnership, the core application has sufficient potential to
justify - according to the programming mindset - a collaborative
approach to realising that potential. Finding or not finding a
collaborative core can be a useful exercise in evaluating lone
suppliers as well as partnerships: if the product is good, it
will have its fan club.
This is, of course, to stretch the meaning of the word 'partnership' beyond its usual limits. They key point is that a "collaborative-core partnership" only comes into existence because of the enthusiasm of its members. And while enthusiasm is not an easily quantifiable factor in determining success over time, there is nevertheless something to be said for any solution that really fires up its users. As any human-resources director will tell you, at length and with a Powerpoint presentation to back up the message, you only get the best out of people when their morale is high. If only all partners could feel this way about each other.
This style of 'partnership' doesn't have to entail the sharing of commercially sensitive data; rather, it tends to be an informal or semi-formal augmentation of the R&D process in relation to the application in question. One example of such a partnership is the "customer community" at Kx Systems, which exists because customers can't just pick up a software package and walk away - or at least, if they do, they're risking leaving behind a significant part of their RoI. Kx Systems, briefly, delivers high-performance databases to customers who want to exploit the vast amounts of data they're collecting. Simon Garland, chief strategist at Kx Systems, says: "Every customer is more like a partner of ours. They have to be programmed, they're writing code, they're coming back to us and asking, how do you do this? They also join our customer community."
And the customer community, as Garland says, is where they ask similar questions of their counterparts in other firms. Garland adds: "New customers are often surprised that people who are nominally their direct competitors are actually telling them how to do this faster, that faster, and so on." Whether it's chatroom or blog-based, or occurs in the old-fashioned way in the bar at the end of the third day of the conference, such activity may not amount to partnering in any formal sense, no indeed, but it is significant. As markets, systems, solutions, pre-, post-, point-of-trading develop in sophistication/complexity/potential (pick a word), that maxim about two heads being better than one is going to matter. We can strain the latency out of our machines, but can we achieve similar incremental advances in the performance (enthusiasm, morale) of the people developing and driving those machines?
And whatever you might want to say about NDAs, would you buy a solution that didn't get the thumbs-up from a user group? If these arrangements offer a template for effective partnering, they're also an unforced demonstration of the really core issue. Rob Ciampa, VP Marketing at Tervela, puts it this way: "Any company that attempts to do everything, order routing, market data, ends up doing everything poorly. We're getting a lot more out of companies working together than we would if we just did things separately." Developing this point, Ciampa says: "One of the things we like to do with our partners is look at things holistically." And this is key: a single company, delivering its own slice of the whole, ends up leaving the integration risk with the client. Ciampa becomes almost messianic in his enthusiasm. "In financial services, it's the partnerships that are going to be the foundation for a lot of the innovation that we're going to see over the next three years," he says. "The companies that can effectively partner are the ones that are going to succeed."
There's something in that, isn't there? It's all getting too big, and too complex, for any of us just to buy a solution, plug it in and leave it. Getting back to evaluating partnerships, there's a neat formulation implicit here: the telling detail about a company would be its absence of partnerships rather than their presence, quality, effectiveness, et cetera. But despite his enthusiasm, Ciampa is categoric that partnerships can fail if they are not handled properly. Describing the nuts and bolts of Tervela's approach to partnering, Ciampa says: "First, we laid out a partner ecosystem. We segmented; we had feed handlers, people doing OMS/EMS, complex-event processing. We looked at where we were in our own corporate life cycle. A company that's been in business differently is different from one that's been in business three years." After that, it was a matter of spending time with peer companies, "getting a feel for their capabilities", and taking input from customers.
As this suggests, the prevalence of partnerships across the industry has triggered the development of a methodology of partnership. Ciampa says, for example: "Unless you set some goals for a partnership up front, that are somehow measurable, you'll get surprises later on. We go in with metrics." And the emergence of a methodology enables a further benchmarking process: just how clearly elaborated is the purpose of the partnership? What notions are there of a "partnership life-cycle"? However clear the purpose of the partnership, however apparent the synergy between the two partners' products/services, these are still two organisations structured not to let anybody else in on whatever they're doing that makes the money.
So, above all what steps have been taken to open up each partner to the other? One tactic for addressing issues of confidentiality is to ring-fence, more or less formally, the partnership activity. Such a tactic can bring other benefits as well. For example, Symagon (see also the box 'Polish programmers join the Q') is a subsidiary of consultants Nagler & Company that was formed as a vehicle for partnering with Kx Systems. Symagon offers consulting, training and the management of market-data infrastructures, with the provision of solutions achieved via the partnership, and thus, via Kx Systems' kdb+ database platform. Explaining the genesis of the partnership, Jens Rick, Managing Director of Symagon, says: "There were a number of projects in the market where kdb+ was used, and we were impressed. This was a technology we'd like to see many customers using. From then on, we started talking more intensively with Kx Systems to prepare what has now become a partnership."
Why go all the way into partnership, and why form a subsidiary company to do it? Rick says: "Given Nagler & Company's existing consulting business, we felt that there would not be room within the company for the special requirements of such a technology." And: "We wanted to show everybody that this was a serious move for us, and not just one more project added to our portfolio at Nagler & Company. We are serious about making this technology the base point of many of our products to come." The Symagon commercial proposition, as summarised by Rick, is: "What customers get is real expertise in the technology and in their business." We might also suppose that a vendor/consultant partnership would be well placed to deliver effective support through the implementation and ongoing operation of the technology.
One very familiar, almost traditional, form of partnership is that between a big-name, "generalist" company and a specialist further down the line towards the end user. These can be "masthead partnerships", in which the main aim, for both parties, is to be able to show the other company's logo on the masthead. But the rationale for such partnerships is more substantive: where an operating platform and a specialist application are developed with each other in mind, there is real potential for, well, synergy. As this suggests, the explicit rationale for such partnerships should be more than, say, "We've got a big/specialist name behind us." David O'Shea, Strategic Relationship Manager at Intel, says: "Our partnerships are driven in part by the customers we work with on Wall Street. They have companies that produce the products they deploy, like Kx Systems, and they are looking for those applications that take best advantage of our hardware. Every time we help the application run more efficiently, they get extra processing cycle. In today's world they need their applications to run as efficiently as possible." O'Shea adds: "These days, you just can't get enough trading performance." Which is a neat point.
The specific example O'Shea gives is where multiple-core processing power is available to run an application that was built for, and can only use, a single core. But he uses this to make an interesting point about partnerships. O'Shea says: "All the tools are available online. Companies can do it themselves. They can write their own multi-threaded programmes. Where the customers are looking for more performance, and it's appropriate for Intel to establish a relationship with a software company like Kx Systems, we offer to assist." Partnerships and other relationships arising out of such assistance vary acording to the specific customers and circumstances, of course, but what is implicit here and explicit in O'Shea's earlier comment is that such partnerships are a by-product, indeed almost an "optional extra", in the search for performance. They're "downstream" partnerships in the progression towards the client.
Jens Rick (left) and Dr Martin Nagler
Garland's take on the Intel/Kx Systems partnership is also interesting. Garland says: "Our partnership with Intel is much more traditional," and goes on to explain this in terms that echo O'Shea's: an intellectual (as well as formal) partnership aimed at marrying more closely together their respective components of the (effectively) joint commercial proposition. But Garland goes on to say: "I suspect that our partnership with Intel is different from what you might have with a lot of large companies." This is a passing reference to a very different kind of link-up: the "partnership" that consists of little more than an exchange of logos on the promotional literature and the adding of one more name to the long list of "partners" that is used to bolster the company's own sales talk. In the context of numbers, there is potentially something suspicious in numbers: if more or less everybody is a partner, being a partner adds no more value than everyone else is getting. The particular question to ask here is, how do you manage so many partnerships? And here, even more than elsewhere, it pays to go into detail on how the partnerships are managed. If you're feeling particularly nasty today, wait until the end of the sales pitch about the value of partnerships, and then ask the guy to name his opposite number at any one, just one, of the partner companies he's just mentioned.
That's about as useful as challenging that old phrase "Allow twenty-one days for delivery" by calling up and asking what happens on the ninth day, and let's say the fourteenth day. But it has been done, apparently, with results that at least gave rise to an anecdote, if not a(nother) partnership. The point is that lately, going into partnership has itself become a commercial strategy. The added value that a partnership potentially delivers has become the down-the-road justification for a marketing campaign rather than the here-and-now end result of working together. Companies become partners for the purpose of becoming partners. The inbox over there at the Automated Trader newsdesk is filled up every day with releases about partnerships, strategic alliances, companies working together to deliver some kind of enhanced value proposition. Sometimes, the problem is to work out why these people need each other; sometimes, the challenge is to work out how they think they're going to get to that much value by just holding hands. The giveaway, if it is a giveaway, is that they're promoting the fact of working together over the more important fact of what they're delivering together.
But that's simplistic, isn't it? Isn't it? We all promote the part that works best as promotion, and these days, getting into a partnership works as news. It does so because, cynicism aside, some partnerships do deliver results. And these days, partnerships can also be a way of sharing the pain of current commercial reality. Like drunks, partners prop each other up. There are also the more prosaic reasons for partnering: you've got Europe covered, for example, while I'm big in the US. But if it's the exploitation of such advantages that matters, rather than the advantages themselves, the challenge remains of finding a partnership methodology that will deliver some degree of added value to both parties - and to the client. This is partly a matter of looking at the planning process that is aimed at achieving the successful implementation of the partnership. But what about asking each partner what their own benefit will be? Why does a Europe specialist tie up with a US company? How do they address questions over whether they're giving away more than they're getting?
The vision thing
Let's turn to two examples of companies where partnership is presented as an integral part of strategic vision. Asked the simple question "Why did you do this?" Chris Momsen at Advent described his company's partnership with G2 Systems thus: "Early on we were focused on not doing everything ourselves. We saw that as key to our growth and we wanted to make sure that clients could always have the resources out there to make them succesful. At the highest level, the idea was, if other people were successful, it would help drive more software business for us. We're selling investmnent management software and the partnership is around people who can help implement and do things on top of our software for our clients." Pressed further on his own apparent corporate modesty - an attribute not always brought to the fore in interview conditions - Momsen continued: "There are a lot of things that we knew we couldn't do and we wanted to provide choices out there for our clients so they could come to Advent for this, someone else for that." This is reminiscent of Rob Ciampa's earlier point about trying to do everything and ending up doing it poorly.
And just for the record, George Michaels at G2 Systems started his own account of the Advent/GT partnership with the reassuringly simple statement: "I was a client." As a former hedge-fund CTO with experience of Advent, Michaels liked the solution so much he bought into the idea of going into partnership with the company. "My personal history with the product goes way back," says Michaels. And then there's the example of the Correlix/Endace partnership. Describing the partnership's raison d'etre, Shawn Melamed, CEO at Correlix, says: "Our products are very compatible, so the integration brings a unique offering to our joint customers. The robust network capturing hardware from Endace coupled with Correlix's advanced latency analytics software enables clients to create a truly complete latency picture of trade execution and market data flows with microsecond accuracy in real time." And Melamed goes on to explain: "Combining the entirely passive Endace monitoring hardware and the company's proven high-throughput capabilities with Correlix's powerful correlation engine gives customers the ideal solution for accurately measuring latency."
Which is reassuring. We also asked Melamed about the day-to-day mechanics of partnership. His answer delivers an insight into the size of the commitment that a partnership represents - or should represent. Melamed says: "A development resource was dedicated to learning about out partner's hardware, integrating it into a combine solution offering and providing ongoing support for product enhancements. In addition a relationship manager oversees the partnership and joint marketing and sales activities." As to support, Melamed adds: "Support for the solution is dependent on the client's needs and the complexity of the client's requirements. Both companies can and do support the solution as needed and as requested by either the client or partner. Our development team has hands on experience with Endace hardware. Since the new solution is an integration of hardware and software, we are able to quality assure that our software works seamlessly with it."
You get the impression throughout this feature, don't you? These people need each other. That's easily measured at the hardware/software level, but potentially less detectable at the human-to-human level, which might, let's face it, also be termed the partnership level. A partnership is not the same as a merger, or indeed an acquisition, not least because it doesn't nigh-on inevitably destroy value as soon as it has happened, and nor is it exactly a marriage, not least because there's no inevitability about the [perhaps it would be prudent to leave this sentence unfinished]. But a succesful partnership is necessarily founded on a human relationship rather than just a synergy between systems, solutions, operating models or any other accumulation of buzzwords. The arguments can be compelling, the solutions compatible, the programmers enthusiastic about solving each other's problems.
But if you don't find that enthusiasm at board level - maybe the bottom line should be, a partnership will only optimise its value-add if the two partners like each other's solutions enough to enthuse about each other's solutions. Ultimately, it's a human thing.
RTS partners with MATLAB
Also featured in our news pages this month, RTS Realtime Systems Group (RTS) celebrated the end of 2008 by entering into partnership with MathWorks Inc to integrate the MATLAB environment into its algorithmic development environment, RTD Tango. MathWorks was founded in 1984 and is, to cut a long and familiar story short, a leading global provider of software for technical computing and model-based design. MathWork's products MATLAB and Simulink are now fundamental tools at many of the world's most innovative technology companies, government research labs, universities and financial institutions.
This is useful information, and probably the best account of the rationale for the partnership is the one we found in the RTS newsletter, 'screenshot'. It goes like this. "With its more than 600 mathematical and statistical functions, MATLAB gives users immediate access to high-performance numerical computing. This functionality is extended with interactive graphical capabilities for easily creating plots, images, surfaces and volumetric representations."
In conjunction with RTS's low-latency execution engine, MATLAB's computation and visualization environment offer traders a new toolset to help identify and capture trading opportunities. Algorithmic traders can design, test, deploy and control their strategies from one integrated environment giving them the ability to go from idea to production in days rather than months.
The detail is compelling enough, but we've also been struck by the enthusiasm. These are happy times at RTS, clearly, and no doubt at MathWorks too. More at www.rtsgroup.net.