12.19.07

From time to time I like to blog about the work GXS is doing with partners, especially SoftwareAG webMethods and Microsoft (because I am involved in those).  Every so often, I’ll get asked why we partner, and why we don’t “build our own technology”, so I thought I would share something of our philosophy around technical partners and why it is important to understand the partnering philosophy of the software and services providers you use.

Firstly (mostly because I work in engineering and hope my colleagues will continue to return my calls), we do “build our own technology”, quite a bit of it in fact.  We have hundreds of engineers around the world working on software and services to make doing B2B easier and more productive.  In just the last few architecture reviews I’ve led, I’ve seen a new generation of technology to do translation more easily and efficiently, a completely revamped system for tracking the flow of XML data through our services, and a set of shared services that enables companies doing Global Data Synchronization to synchronize data (data pool management, or DPM).  Some days there is so much going on that it is challenge to keep up.  What I did not see — and had better not see — is someone building a database, an application server, or a new publish and subscribe bus for generalized messaging.  The reason is that if we are building core general purpose technology like that, we are not building the specialized technology that has made us successful.  There are too many opportunities to add value to our customers’ operations to squander them on proving we can build a better web serve than the Apache Group or Microsoft (which we can’t…).

Secondly, everyone partners, they just call it “sourcing”.  Last time I checked, ERP systems needed operating systems, databases and networking software.  You can call it sourcing, but when you decide to build your software on a given database technology (for instance), you have a new partner whether you like it or not.  Independent companies usually leave OSes, database, etc to the major players because those products can now be more efficiently provided, and it enables them to focus on the pieces where they can bring extra value.  I don’t know too many companies that would buy a software product that required its own, proprietary operating system these days (full disclosure, GXS once helped create the time-sharing era — working with Dartmouth — by writing an operating system, but only because the ones we could buy didn’t support time-sharing…).  Even folks marketing “software appliances” are tending to build on either a Windows version or a Linux distribution for this reason.

But it goes beyond the traditional economics argument — aside from the partners we need to run “on”, there are partners we need to run “with”.  Most iPod owners would be less ecstatic with their devices if they didn’t work with the computers that they owned, or did not work with non-Apple headphones, speakers, etc.  Likewise, nobody upgrades to new operating systems like Windows Vista of Apple’s Leopard if their software is not going to work — thus partnerships are caused by the customer’s irrational insistence that products work in their world, not just the nice demo center where everything is made by one company.  I feel strongly about this because our best partnerships today share one key element, customers that want to use the partner’s products together.

GXS’s partnering philosophy is simple, we are in business to help companies share data and conduct business processes with their partners (customers and suppliers) — and we work with partners that help us accomplish that.  Sometimes we work with technology partners like BEA, IBM, EMC, Red Hat, Egenera, etc because it is far less expensive to our customers than us doing it ourselves; and sometimes we work with firms that have already earned our customer’s business, like SAP, Oracle, SoftwareAG and Microsoft.

But we don’t partner with everybody, and for a very good reason.  In truth, it is often “easier” to build your own solution from scratch than to work with partners, because you have complete control down to the code.  Partnering at a deep technical level (like the various web services APIs to the GXS Trading Grid we offer) is a long-term commitment, and embedding someone else’s technology means integration work which is harder than straight development (though usually faster and less expensive).  Years and years of integrating with customers’ systems has given us the confidence and experience to select and integrate key partners.  Not every company has the skill and experience to work with technology partners, but I would encourage most companies to stick with those that do.

If you hired a contractor to build your new house, you might be alarmed if he or she brought an ax or starting making his own bricks — and relieved if instead you realized he or she showed a knowledge of the best “subs”.  It’s my hope that the people asking me why we partner will start asking their “technology contractors” why they don’t…