How to avoid bad IT architecture

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.

More accurately, the functional account of the solution is a service. When describing technical architecture, the service description is the first of three stages of standards-setting: the technology-neutral stage. Once you’ve defined a service, the second stage is settling on the class of technology you’ll use to provision the service. Only then are you ready for the third stage: thinking about specific products.

Services-minded solutions: A layered approach

Take secure access as an example. That’s the service. You have several classes of technology to choose from, such as traditional VPN, SSL-based VPN, streaming VDI, and IDV (what we used to call “local-mode VDI”). Once you’ve settled on a class of technology, you’re ready to think about the specific product to establish as the company standard.

That, of course, assumes it makes sense to settle on a standard. Often it will, but often isn’t the same as always. When the technology marketplace for a particular service is rapidly evolving, allowing for a few competing solutions to provide a particular service can make all sorts of sense. More often, when you’re tempted to allow multiple products to provide a particular service, peeling the layers a bit will reveal that you actually have two different but similar-sounding services to provision.

But we’re getting ahead of ourselves, because if you start by brainstorming all of the problems IT has to solve — by trying to just list the services — you’ll end up with an unmanageable roster, which is the polar opposite of an architecture. A better approach is to start by organizing your thinking and your architecture into layers. In our consulting on this subject we’ve found that starting with three basic layers works well: platforms, information, and applications.

The platform services layer provides everything needed for building and hosting: hardware, networks, operating systems, development tools, database management systems, and so on. The information services layer stores, organizes, manages, and delivers all of the company’s data, using various platform-layer services to do so. The applications services layer is developed and runs on platforms, and it processes information to provide various kinds of business value — mostly by partially or fully automating business processes and practices, but also by answering questions so as to support better decisions.

Please take note: In spite of the volumes of bytes strung together on this subject that claim the primary value we in IT provide is in the information we manage, from an ETAM perspective at least the information services layer provides no business value, other than its uses in supporting the application services layer. That’s because human beings can’t even view any of the information managed by the information services layer, let alone analyze it in any way, without using an application to do so.

Moving away from accidental architecture management

To get started on a productive approach to ETAM, divide your architecture into three layers: platform, information, and applications. You’ll find you next need to divide each layer into sublayers and sections. Within each section you’ll define services; for each service you’ll settle on a class of technology; and for each class of technology you’ll select a specific product.

Sound like a lot of work? It is a lot of work. It isn’t uncommon for an enterprise technical architecture to consist of a thousand or more services. That’s a lot of defining and selecting.

Here’s the problem: You have no choice. One way or another, you will establish solutions to all of the problems. Your choice is whether your enterprise technical architecture is accidental or intentional.

If it’s accidental, eventually you will be visited by symptoms Nos. 1 through 8. The trick is making it intentional, without it becoming impractical — dodging symptom No. 9.

This story, “How to avoid bad IT architecture,” was originally published at InfoWorld.com. Read more of Bob Lewis’ Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.