Moving from Accidental Architecture to Enterprise Architecture

Moving from Accidental Architecture to Enterprise Architecture

Many — if not most — organizations with extensive in-house IT and a significant percentage of home-grown apps have followed a progression that has led them to a big mess:

  1. First came the app, which ran in a mainframe, which we gazed at from afar through a CRT.
  2. Then came PCs, and we could run the app at our desks.
  3. Then came the Internet, which gave us the best of both worlds.
  4. With Internet technology came tiered apps.
  5. Then came in-house Web apps.
  6. And then came … a big mess.

Let’s examine how this happened.

Scenario 1: A new in-house app is requisitioned by a department. The app is a distributed app that needs to access not only different databases but different database platforms. It also requires mobile access, and the workflow calls for segregated middle-tier logic.

The app gets built, along with custom pipelines hooking the tiers together and additional pipelines for the peripheral modes of access. Then along come another 10 or 15 apps built the same way, over a few years.

Scenario 2: The old M-drive has gotten popular, and there’s so much historical content in it that more and more departments are accessing it. This leads to more and more current content, leading to security issues, no version control, mass confusion and finger-pointing.

Scenario 3: Advances in Active Directory/Outlook integration have led to the establishment of a number of in-house groups that can be very conveniently addressed all at once with team-specific mailing lists that didn’t even have to be created. Before long, meetings are taking place in email, and these expand out into full-blown project documentation.

Now, draw all three scenarios on a white board. Take Scenario 1, diagram the distributed app described; then draw another one, without erasing the first one, and another one, and another one, and another one … and before long, you have a very real (and ugly) picture of the environment.

Step back and look at it as a whole. Squint and observe the lines. What do they remind you of? Try a map of county roads and state highways, a spaghetti tangle that makes no sense.

Scenario 2? It will look like the road around the Arc de Triomphe, a free-for-all where you just take your chances and hope you don’t get creamed. Scenario 3? A military convoy on a two-lane county backroad.

The problem IT managers and architects have is that they don’t take this global view. We tend to diagram our apps and systems individually, without layering them over the environment we already have. What we end up with, after a decade of distributed apps, is not a single global architecture, but many small architectures — leading to an accidental global architecture, unplanned and poorly policed.

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.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist