A Global Framework: The Cure for the Accidental Architecture
We know the answer to the country roads and local highways problem: the interstate highway system. It solves the problem with one grand step, tying all the little routes together into one massive shared route, simplifying every individual travel plan with a solution that all travelers share.
And that's the cure for accidental architecture: a global network overlaying the local connections that bundles all the little stuff together. The network would share services, exploit economies of scale, and bring continuity and uniformity of use to an otherwise convoluted environment.
This is by no means a new idea. If your organization hasn't moved to enterprise architecture and your role in IT includes planning or strategy, you've explored it at least tentatively. The question is, where do you start, and how do you keep it rolling?
When Dwight Eisenhower signed off on the construction of the interstate highway system, he was building on concepts that dated back to Franklin Roosevelt's administration, which called for a total of eight super-highways. How did it start? Like most great enterprises, a little at a time.
How can the applications you already have share resources? What about the apps that are on the drawing boards? Do you have a process in place for spotting the opportunities for resource sharing? Once you have this set up, economies of scale rapidly fall into place, and the trade-off between custom functionality and rapid development/deployment/modification begins to sort itself out.
Shared Services for an Enterprise Architecture
What resources or services are your users likely to want to share? To some degree, it's different for every organization, but here are some favorites.
Content Management. It's cheaper and less time-consuming to administer enterprise content from a centralized resource, rather than several different resources. A global content repository, with customized administration and security, is a major step toward enterprise infrastructure that saves a great deal of money and time. And those messy file shares? Put them all under a common security and administration model, and watch how fast the collective blood pressure falls.
Service Bus. While trickier to build and implement, over time a back-end service broker that functions as traffic cop to your database platforms (especially if you have quite a few) saves developers time implementing new apps and (properly administrated) results in faster, more efficient response time. And all of your apps will be more robust.
Data Warehousing. This granddaddy of shared services can both simplify and extend your reporting capability in ways that will make upper management giddy. You can spread the cost of building it around, because once it's on the table, most groups within the organization will want it. And it offers new ways of compiling and analyzing information that will take organizational metrics and analytics to the next level.
Centralized Reporting. You have dozens of separate reporting mechanisms. Imagine having just one, and everybody being happy.
Social Media. Email is right up there with texting, a reflex that keeps us in touch with our mothers and reminds us to pick up the kids from soccer practice on time. As an organizational tool, however, it just blows, and shame on all of us for doing business with it the way we do. We have much better tools available to us for communicating collaboratively, within project teams or hierarchical pecking orders. These tools are global, configurable, workflow-friendly and (ironically) well-integrated with the email we currently abuse. SharePoint, anyone?
Use What You Have in Place
If your application infrastructure isn't a mess, congratulations! You're in a vanishing minority. But moving to an enterprise architecture doesn't mean tearing out everything you've got and starting over. You can build that global framework one app at a time, and what you have in place doesn't go away -- it just points in a new direction.