Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Moving from Accidental Architecture to Enterprise Architecture

Unstructured, "accidental" application architecture creates long-term inefficiency and design barriers. Enterprise architecture with shared services can alleviate the problem.


advertisement

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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap