Do we still need systems integrators?
David Eaves argues that any modern IT system should be designed from the outset to talk to other systems.
Starting with the blog posted today, David Eaves and I will be initiating an occasional collaboration under the auspices of The Lectern.
David is a new colleague at the Kennedy School, who comes to Harvard from earlier work at Code for America, advising several governments on technology and launching a successful start up in the municipal government space. At the Kennedy School, he teaches a course in digital government and directs the Digital@HKS program. I have had the pleasure of working with David this semester on a course he leads called “Avoiding Digital Disaster” on Healthcare.gov.
David is smart and he is fantastic. I suspect that once every few weeks we will have a joint blog, and on occasion (as this time around) a blog will be posted on The Lectern under his name. His first post, “Do we still need systems integrators?” reflects his intelligent, sometimes-controversial approach.
Blog readers, please welcome my friend David. -- Steve Kelman
* * *
Here’s an overly simplistic statement but generally good rule of thumb about IT in government: Systems integrators are a symptom of poor systems architecture.
This is to say that today’s systems integrators, the people governments ask to create software that (usually) enables us to extract data from one software system and then restructure it or create processes around it so that it can be shared with another software system, are being asked to do work that shouldn’t exist. They are symptomatic of a failure to realize that any large IT system could and likely will need to be a platform. They also are a window into a massive opportunity to reduce spending on government IT systems.
This wasn’t always the case. There was, for many years (decades!), a need for systems integrators. Building and designing a large IT system (for example, one that tracked travel expenses) was an enormous project, but also one that was generally siloed. Getting the travel expense system to talk to payroll… that was a giant project in of itself. Getting one large siloed system to talk to another large siloed system was a huge effort.
Indeed, prior to 1990s it was hard to even imagine persuading these large complex systems to talk to one another. And then we began to see that getting these large systems to talk to one another might be possible -- and that’s when the system integrator become necessary and important.
But by the time the 2000s rolled around, we were living in a world of the web, and people could see that standardizing the structure of information meant that one didn’t need to build custom software to connect one system to another. Instead, the right application program interface (API) would allow any system to grab the information it needed without requiring a system integrator to build custom-software connections.
If, from the outset of any project, you accept that your system will need to talk to other systems, you will design it so that data and information can be accessed via API. If you believe that it won’t, then you opt to not design the system to share information easily via APIs.
The latter choice will save you some costs in development and project management in the short term, but will constrain you in the long term. The former will create some minor additional costs initially, but provide you with significant flexibility in the future. But the bigger point is, this is a choice -- an architectural choice about the structure of the IT systems we build. Making the right one requires intentionality and foresight.
It is also one that does not happen easily or automatically. Indeed, many private sector companies are not good at doing this. This is not a case of the public sector simply “not getting it."
To demonstrate this, there is a marvelous story about how Jeff Bezos realized this in the early 2000s and literally forced his entire organization to move from siloed entities that required systems integrators (sometimes the system in question was simply two people emailing data back and forth to one another, sometimes it was a lot more) to one that was extensible and API powered. Steve Yegge, a former Amazon employee now with Google, accidentally “ranted” about it back in 2011 in a piece that is so good, I try to read it every 6-12 months.
The key point of the article is that the ultimate systems architect, Amazon’s CEO, decided there was a good architecture now available because of APIs. As Yegge describes it:
So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.
His Big Mandate went something along these lines:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6) Anyone who doesn't do this will be fired.
It really is hard to describe how difficult and far-reaching this mandate was, but its impact and vision cannot be understated. Bezos effectively forced Amazon’s disparate systems to both work together and to serve as platforms for further innovation and integration. It represents one of the most dramatic shifts from a siloed organization structure to a networked structure. It is a key part of what made it possible for Amazon to scale and serve as a global platform for retail.
What it painful? Was it hard? Absolutely. But it enabled the organization to offer both scale and innovation in manner few others have been able to replicate -- all because of an architectural choice. If you think that government should be able to operate with the scale and flexibility of Amazon, then Bezos' mandate and its implications for government are worth studying more closely.
And this brings us back to systems integrators -- because after the mandate, anyone designing a new system at Amazon would know that system should be designed, from the outset, to talk to other systems. Hiring a systems integrator would be an admission that you had architected your IT systems poorly and would be seen as a waste of company time and money.
This is how it should be seen in government. We should be building systems with the idea of sharing data and services by design, not something systems integrators must create later.
Now if you are a systems integrator and you’re reading this, have no fear. There are, happily, thousands (and more likely tens of thousands) of legacy government systems out there that will require your services so that they can be integrated with others’ systems in the coming years and decades. There will still be plenty of money to be made. However, no new system being built by government should require a systems integrator. It should adhere to Bezos mandate number 1.
NEXT STORY: White House takes on technology revamp