The System Integrator’s Conundrum

My time in the industry has seen me in several roles and in several companies. Some have been pure in their nature. For example, one company was a pure managed operations service provider. It provided help desk and call center services, desktop service management, and some server management/administration. It did not develop software, provide consulting, or offer systems integration. Another was very much a pure systems integrator with related software development capabilities and a wee bit of managed operations for those contracts that started as systems integrator. (For the unfamiliar, systems integrators tend to be those that assemble capabilities/discoveries/inventions that are not previously formed into a reusable whole; an example would be the assembly of a national air traffic control system such as used by the US’ Federal Aviation Administration or the construction of a national health care statistical analysis system such as is needed by the US Center for Medicare and Medicaid. Well known companies that generally fit this model include Leidos, Perspecta, and GDIT.)

My time at IBM, on the other hand, was in a large, multi-faceted company that offered software development, hardware and software product, managed operations, systems integration, consulting or staff augmentation in contracts with one or more of these facets together or independently.

I have come to see that pure-play systems integrators are particularly challenged by the marketplace these days. Most industry sectors are not consumers of systems integration, except for national governments and those that are their providers.

Systems integration is by nature the packaging of capabilities to meet a need unaddressed in the marketplace. As such it falls between the discovery/invention type of innovation and the productization type of innovation. Productization assumes a market scale of more than one. In the US Federal SI marketplace, there is only one customer – the US government. Building an exa-scale computer for simulating nuclear weapons, developing a rocket to lift a trans-Martian spacecraft, or assembling a sensor system for evaluating global weather tends to be a one customer market. And with that one packaged outcome there is no intent to build a marketplace or even resell the outcome. That is systems integration.

Consequently, the business model for pure systems integrators focuses on assembling a portfolio and eco-system of capabilities – not products or offerings. They do not develop nor have a need to build the go-to market mechanisms in sales, marketing, competitive analysis, portfolio management, production, or even continuous improvement/innovation that characterize a product house or managed services provider (who sell “managed service” products) for a marketplace of even tens of clients, let alone thousands. Often their post-integration operations will be a struggle for them with some evidence from a lack of a true community of excellence and no years or even months of continuous improvement in their services.

By direct contrast, US state governments are many. They tend to behave far more like the private sector markets and want well-formed products and offerings that are successfully sold to large markets. There may be some unique issues in a state (how many private companies collect taxes?), but generally, states want best-of-breed/best-value as evidenced by a vibrant private sector marketplace for the capability/product they require. In short, they regularly have the same motivations to buy as private sector companies. US state governments will then need vendors that are more product/offering centric than a systems integrator’s capability orientation.

Certainly, there are systems integration requirements in state government. In the US, all need some sort of Medicaid system that has no other marketplace; however, even the 50 state marketplace is nudging vendors toward a product-oriented approach that will very heavily challenge the systems integrators in this market over the last two decades.

The point is to remember that systems integration and managed services are different. Each addresses different horsemen in your motivations to buy services. As a result, your service requirements require different types of vendors. Success with your procurement should align the vendor type to your requirements and strategy.

So, if you are buying systems integration, make certain that there is a demonstrable eco-system of new and cultivated capability in your vendor choices. If you are buying managed services, make sure there is an orientation to a well-developed and constantly improving set of managed service offerings. If you are buying both, you must make sure both are present.