All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

A CIO of my acquaintance once described his priorities for the new megasystem his developers were busily constructing. “What I want is the database,” he said. Waving his hands disparagingly, he added, “I don’t much care about the applications that feed it.” Guess what? His system never got built, and he didn’t last two years in his job.

We’re continuing to develop the technical architecture section of our integrated IS plan. This week we home in on the information layer. The techniques for managing this layer are well understood. Instead, let’s elevate the discussion (elevate in the sense that snipers like high places). Our goal this week is to place information in the proper context. We begin by avoiding the mistakes of the aforementioned CIO, realizing that although information is the center of our universe, applications drive the business.

We made a horrible mistake when we changed our name from electronic data processing (EDP) to management information systems (MIS) back in the early ‘80s.

When we were EDP, we did something valuable – we processed something, and as we did so, we automated manual processes.

MIS managed information. Even worse, we declared that our purpose is providing information to managers. Helping employees do useful work became a byproduct.

We would be much better off calling ourselves “process automation systems.” We got offtrack because of database management technology. With the advent of the DBMS, we changed how we designed systems. We put information in the center of design. Information, we realized, is more stable than the programs that make use of it.

Next we figured out that because information is the heart of our designs, it must be at the heart of the enterprise. So far so good, but then we left the halls of reason and jumped to the notion that it’s information, not processing, that delivers the most value.

Take a fresh, hard look at this. IS delivers the bulk of its value through process improvement: lower unit costs, reduced cycle time, and increased accuracy.

This is just as well. If we really do think information is the point of it all, our efforts are way out of whack with the company as a whole. About 80 percent of an average company’s information is unstructured. (I’ve run across this estimate several times, and it passes the “feels right” test, too.) It’s text, voice, and pictures. A simple-minded feller might figure that if information is the point of it all, and 80 percent of all information is unstructured, well then 80 percent of our efforts should be devoted to the management of unstructured information. They aren’t, of course. Eighty percent of our efforts go to managing alphanumeric data – the kind we know how to process. Telephone systems and personal computers – the technologies that handle unstructured information – have been the poor stepchildren of IS, not because we couldn’t manage the information, but because we couldn’t process it.

We’ve been able to get away with this so far. No longer, though. Maybe it’s the influence of e-mail and the World Wide Web, but companies are waking up to this deficiency.

Want to know your future? Look at a modern call center. It records every conversation digitally, along with every screen visited during the call. It’s indexed and ready for online retrieval to help call center management assess individual performance. It’s also available for computing sophisticated performance statistics.

Today these systems are closed and proprietary. Tomorrow they’ll store everything in the same document management system that will store scanned images and word processing documents, all linked through a common index. That’s just one example of how you will have to manage and process information in the near future.

Thought your information layer was in good shape? Maybe for today, but you have some serious planning to do.

Comments

|In: Architecture|Last Updated:

Delegation is a difficult skill to master. Many managers confuse it with tossing work over the transom and forgetting about it until the deadline. That’s a weird mistake to make when you think about it, given the absence of transoms, not to mention doors, in the modern workplace.

One way to think about the role of IS in the enterprise is that the business has delegated management of technology to it. Most businesses have tossed the task over our virtual transom and wonder why in their eyes we often botch the job.

When someone uses your transom to delegate to you, your proper response is to insist on meeting to make sure you understand the purpose, scope, and time frame of the task.

That’s why, in our continuing development of an integrated IS plan, we spent so much effort learning about the company’s strategic, tactical, and infrastructure goals. That was our means of understanding the purpose, scope, and time frames associated with our responsibilities.

Now that we know about ’em, what are we going to do about ’em? We’re going to change our architecture to satisfy them, and our starting point is supplying applications that satisfy the company’s requirements for process automation. (No, not databases that satisfy information needs. They come later. It’s the applications, processing information in our databases, that provide business value.)

Your applications suite needs regular review and grooming. Especially, you need to go beyond assessing the current business value provided by each application. What you’re trying to do is determine how well your current mix of applications supports the future state of your business, and what changes you can make to support it better.

You can be as informal or structured as you want in making this determination. Here’s a framework you can use as a starting point.

Begin by identifying key business functions – major activities, like marketing and manufacturing – based on how you expect the company to be structured in the near future. (Don’t be too abstract. If you have multiple business units and each has its own manufacturing operation, count these as separate business functions.)

Next, inventory the application systems you support. That’s right, all of them, not just the ones you think are important. You’ll have to make some arbitrary decisions on what constitutes a “system” – is your enterprise resource planning solution one system, for example, or do you deal with its HR/payroll, manufacturing, and accounting modules separately? Rule of thumb: If you can’t replace it as a unit, it isn’t a system. If you can, it is.

Set up a matrix (you saw that one coming). The columns are your business functions; the rows are your application systems. Put two scores in each cell: (1) How important the application is to the function; and (2) How well the application fulfills its role. If you’ve implemented a GUI shell that shelters end-users from the underlying computing environment, set up two matrices – one that describes the end-user experience, the other that describes the underlying applications environment.

To use the matrix, look at how well your applications support each business function. How well each application fulfills its role has an obvious impact. The number of applications required is also significant—the more applications required (weighted by importance) the less satisfactory. Count each application’s market viability in your assessment of how well it supports a function – you can’t count on orphan products to survive compiler and operating system upgrades, so by definition they don’t support your future business.

The computations you use in your assessment depend on your appetite for mathematics – you can create a formula that takes all factors into account and behaves properly, but it won’t be a simple one.

Compare your computing environment to “perfection”: a single system that supports the entire enterprise and is perfectly adapted to your business requirements. That obviously isn’t achievable, but every step you can take that improves the fit between applications and requirements, reduces the number of applications with which end-users interact, reduces the number of applications you have to support, and minimizes the risk of conversions is a step worth taking.

Comments