How to avoid bad IT architecture

Take a tip from the cloud vendors: Thinking in terms of services is a good way to ensure your IT architecture isn't accidental

First there was SaaS (software as a service); then there was PaaS (platform as a service), followed by IaaS (infrastructure as a service) and storage as a service, the other SaaS. Meanwhile, the Silicon Valley Rabbinical Society is reportedly experimenting with services as a service, and the Conjunction Society of America will soon offer "as" as a service.

Annoying as "as a service" has become, here's what's even more annoying: Instead of sneering at it, you should probably adopt it as a great way to get started with enterprise technical architecture management, aka ETAM. A services view can help you avoid having ETAM eat you alive with formal standards and practices that are academically pretty but have no practical merit.

[ Find out the 10 business skills every IT pro must master and beware the 9 warning signs of bad IT architecture. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld's 29-page "Mobile and BYOD Deep Dive" PDF special report. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]

Bad IT architecture: The symptoms

A recently published InfoWorld slide deck listed nine symptoms of bad architecture. In sum, the symptoms are:

  1. Manual rekeying, where humans serve as the interface between disconnected databases.
  2. Collections of point solutions that force employees to deal with multiple applications just to get their work done.
  3. Redundant applications that either overlap significantly or do the same job, and therefore have to be kept in sync.
  4. Redundant data that reside in different databases because applications that aren't redundant often need some of the same data.
  5. Too many interfaces connecting disparate systems, ranging from the traditional spider web to (as one client put it) a complete hairball.
  6. Faux-elegant integration that leaves the hairball alone, but hides it inside an enterprise application integration system, services bus, or other fully buzzword-compliant integration engine.
  7. Kludges and work-arounds programmers put in place because a problem had to be solved right now, but the promised time to do the job right never materialized.
  8. Obsolete technology that's no longer supported by the vendor but, sadly, still needed by mission-critical applications.
  9. White papers -- that's right, white papers, written by the ETAM team to be undeniably brilliant, academically admirable, and chock-full of terms like "ontology" and "reificiation."

CIOs establish ETAM teams to cure the first eight symptoms. Avoiding the ninth, though, often proves insurmountable, and done wrong, the ETAM cure can be far worse than the disease.

Bad IT architecture: The solutions

Done right, ETAM provides three forms of business value: remediation, extension, and maintenance. That is, it provides guidance for improving what's deficient, adding what's missing, and preventing deterioration.

To accomplish this, ETAM teams have to be able to:

  • Characterize the architecture
  • Inventory deficiencies with the current state (such as the first eight of the nine symptoms)
  • Understand the factors driving change to the current state
  • Design a target architecture
  • Integrate ETAM into every IT methodology and practice that affects the technical architecture (pretty much all of them)
  • Change the IT culture -- and to a significant extent the culture of the rest of the business as well -- so that good architecture is how we do things around here

It all starts with characterizing the architecture; if you can't accurately describe what you have and what you want, you'll have an awfully hard time changing what you have into what you want.

Thinking in terms of services -- really, a hierarchy of services -- is an excellent way to characterize technical architecture.

So what, from an ETAM perspective, is a service? Think of a service as a solution to a definable problem. The issue might be providing secure access to the company's business applications; storing and retrieving bits; storing and managing structured data; provisioning servers; calculating sales commissions; managing the flow of work through the company; or keeping redundant data synchronized. If you can state a situation as a problem, the solution is a service.

1 2 Page 1
Page 1 of 2