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

Page 2 of 2

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 Read more of Bob Lewis' Advice Line blog on For the latest business technology news, follow on Twitter.

| 1 2 Page 2