Is your vendor the center of the universe?
A recent post from James McGovern reminded me about some thoughts I had after a few different meetings with vendors.
Vendors have a challenge, and it all stems from a view that they can be the center of the universe. A customer buys their product and builds around it, thereby becoming the “center of the universe” for that customer, exhibiting a gravitational field that attempts to mandate that all other products abide by its laws of physics. In other words, every other product must integrate with it, but that’s the responsibility of those products. For reasons I went into in my last post, that doesn’t work well. It’s a very inward-facing view rather than being the consumer-oriented view.
The challenge is that even if a vendor didn’t want to come across as the center of the universe, for some customers, it is required. For example, if a customer doesn’t have a handle on enterprise identity management, a vendor can shoot themselves in the foot if their own product doesn’t provide some primitive identity management capabilities to account for customers that don’t have an enterprise solution. In the systems management space, you may frequently hear the term “single pane of glass” intended for the Tier 1 operations person. Once again, however, every monitoring system that deals with a specialized portion of the infrastructure will have its own console. It’s a difficult challenge to open up that console to other monitoring sources, and it’s a difficult challenge to open up the data and events to an outside challenge. So what’s an enterprise to do?
To me, it all comes back to architecture. When evaluating these products, you have to evaluate them for architectural fit. Obviously, in order to do that, you need to have an architecture. The typical functional requirements don’t normal constitute an architecture. You can make this as complicated or as simple as you’d like. A passion of mine tends to be systems management capabilities, so I normally address this in an RFI/RFP with just one question:
Are all of the capabilities that are available in your user-facing management console also available as services callable by another system, orchestration engine, or script?
Now, there are obviously follow-ons to this question, but this does serve to open up the communication. Simply put, the best advice for corporate practitioners is to ensure that you are in charge of your architecture and setting the laws of physics for your universe, not the vendors you choose.
I agree in principal with this. Having an architecture and evaluating your software/vendor purchase against that is a very good idea. I think another big challenge a lot of IT shops face is a business group or a business need that drives a software purchase or vendor selection that IT does not have veto power against. I have seen that many times at a lot of different companies. At that point having a solid integration strategy pays off, especially when these seem to come and go quickly.
In most organizations, there usually is at least one vendor that is more equal than others and becomes the unofficial frame of reference. ERP systems, which become de facto “platforms,” are probably the most obvious examples. In most cases, it’s probably more an accident of history as opposed to some formal corporate standardization scheme.
Hi Todd
I like your RFP question.
Integration and orchestration would be much simpler if vendors’ products were more open but you can understand how this is threatening to their licensing model.
Conversley this merely drives enterprises to find new ways of integrating with “closed” products and this has perhaps resulted in the rise of new vendors with alternative integration approaches, like Openspan, Jacada, Blue Prism and others.
In fairness to the major enterprise vendors, however, not all are so bad and not all want to be centre of the universe.