Like federal highway systems, enterprise infrastructure is never quite complete and never quite ends up as planned. How can it be kept on track over the years?
It's a problem that's not nearly as abstract as it seems. With the best of intentions, an IT department might lay out a course for enterprise-wide infrastructure that might leave the business giddy, leave upper management feeling smug, and get IT more excited than kids on Christmas Eve. Isn't this what happened about eight years ago, when we were all turning everything into web apps?
You may remember what happened next: a couple of years in, we'd done a lot of cool stuff -- development in general was faster but also more costly (requiring greater skill sets among developers); the distance between what the business wanted and what IT delivered began to grow; IT itself became more modular and consequently required more internal management, and the original vision of a unified enterprise often went to hell.
It was very much the same with the building of the interstate highways (check out "The Big Roads" by Earl Swift next time you're surfing Amazon). Time and again, what was needed was far afield of what was built; more and more administration was layered on to keep things rolling; and the original vision was obsolete long before the job was done.
We could belabor the metaphor in search of remedies, but it's faster to just work backward: We already know several ways to fix these problems; it's a matter of teasing out how to apply them on our home turf.
Keeping everyone's eye on the ball. The planning and implementation of enterprise-wide infrastructure is the longest of long-term agendas. But just as interstate highways are joint endeavors between federal and state agencies, enterprise infrastructure emerges from local projects and mid-range objectives -- the creation of a content management system, for instance, to facilitate an out-of-control file share, initiated by the department that made the mess.
What's the fix here? Enterprise infrastructure governance. A long-term approach to enterprise infrastructure must include a guiding agency to keep it on track. Remember Asimov's Foundation? One group worked to rebuild human society, while a second group kept diligent watch, making subtle course corrections here and there to keep things going in the right direction. That same system works in this scenario.
How does it work? Such a governance board includes representation from all stakeholders, and in the creation of enterprise-wide infrastructure, that's a diverse group: upper management, finance, IT, and someone from every line of business. Every major IT project that might conceivably leverage present or future enterprise infrastructure receives review, not just by conventional governance, but by this infrastructure-specific body.
A new take on requirements. Enterprise infrastructure is built around shared services, so an essential step is to ask, with every new app and system, what can be shared here? This question gets asked when requirements are being compiled. We need the app to do this or that leads to we should store this data in the new CMS, or accessing both SQL Server and Oracle means we should use a service bus. Since requirements, too, are the purview of governance, it's not too big a step to build a shared-services filter into requirements review, to spot opportunities for adding to the infrastructure enterprise.
Where are these opportunities? As in the examples above, content-sharing and data-sharing happens through an enterprise content management system, accessing different data sources through a common broker. Others include the use of KPIs (such a metrics system could be useful to many departments or LOBs within an organization) or a centralized report server and associated data store. And the data warehouse, the granddaddy of shared services, certainly sits at this table. And the new kid at the table, social computing, is just a bundle of unrealized potential.
Paying a toll? Who pays for what, as enterprise infrastructure takes form? Many organizations, government in particular, use a pay-as-you-go model that leverages the budgets of the stakeholders-of-the-moment. Government can do that without much squabbling, as budgets self-renew. Within the typical business, however, there persists the feeling that whoever paid up front for it, owns it, and this makes it tough on subsequent users of the infrastructure. The solution? Charge each app that uses enterprise infrastructure for the usage, to spread out the costs without breaking anyone in particular. Back in the day, this is how we paid for data storage (and some organizations still do).
When the plan changes. Even with an enterprise infrastructure governance board, planning can be a nightmare. Why? For reasons we never think of, going in -- enterprise infrastructure, once we have it, changes the nature of our applications and can potentially alter our user community in ways we don't anticipate.
Easy access to multiple database platforms, already built and waiting to be used, enables applications that might not have been considered before; content-sharing across lines of business, enabled by an enterprise content management system, may attract hundreds of users who could not conveniently access the content before. And social computing can alter an organization more than any other single shared service, by offering new ways of working collaboratively.
There are mountains to blast through, rivers to cross, imminent domain to be declared, and petulant users chaining themselves to trees to cope with. But a journey of years, remaking your organization into something leaner, stronger, and far more efficient, is doable if you keep your eyes on the road. And after years on the back roads, it's a treat.