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.

Back when the earth was young and dinosaurs … uh, batch mainframe processing … ruled the world, you picked a primary vendor, usually IBM or Digital, and your vendor defined your technical architecture.

IBM’s whole business strategy, in fact, revolved around control of the architecture. Even if you bought an Amdahl mainframe, Memorex controllers and Telex terminals IBM still defined the architecture. “Technical architecture management” meant buying and upgrading the components IBM mapped out.

Then IBM missed the boat on LANs, or maybe it caught the boat while the rest of us went to the airport. SAA failed and we replaced our SNA WANs with TCP/IP. Open systems and rampant multivendorism has given you control of your own architecture. Now you have to manage it yourself. Be careful what you ask for …

Yes, we’re back to developing our integrated IS plan. An integrated IS plan, you’ll recall, covers three topics: Company Goals, Technical Architecture, and Human Factors. We covered company goals in June, discovering the company’s strategic, tactical, and operational goals in the process and how to translate them into systems concerns.

Now it’s time for technical architecture.

One of the hardest ideas to get right in defining technical architecture is thinking at the right level. Technical architecture describes your systems environment in terms of functional building blocks and how they interact, not specific items and wiring. If “functional building block” isn’t too clear a term, an example may help. “Systems to help us manage our information,” is too vague to be of any use, while “Sybase running on mirrored AIX servers,” has too much detail, locking you into a specific technology.

For data management, you want to say something like, “We’ll support a mainframe RDBMS and a distributed object-relational database. We’ll also support whatever other data management systems are built into our legacy environment but will take advantage of opportunities to align them with our preferred architecture. Under some circumstances we may also choose to accept non-conforming technologies built into turnkey or packaged solutions, but will give preference to those conforming to our technical architecture.”

Technical architecture divides into three major layers: Platforms, Information, and Applications. Taking the last first, applications are what deliver business value. They’re the point of it all, because the rest of the company interacts with applications, not with information or platforms, except for the PC’s keyboard and monitor and the telephone’s handset and touchtone pad located on each employee’s desk. The company goals you developed in the previous section of your integrated plan drive changes to your portfolio of applications.

Information includes everything your applications chew on to produce results. The subject includes databases, word processing documents and spreadsheets, scanned images, Web pages (whether stored in HTML or dynamically generated) … that kind of stuff.

Object-oriented (OO) technology doesn’t change this, even though OO designs wrap data and programs (methods) together into tight bundles. You still manage code with OO programming, and you still have a persistence layer to store every instance of an object … and it’s the information that’s unique in every instance of the object, not the methods.

Don’t count your database management systems in your information layer. A DBMS is a platform along with every other piece of hardware and software you use to build applications and manage information. The platform layer includes host computers, servers, operating systems, DBMSs, all networking equipment, your PBX, and the software you use to manage it all.

The split between the systems management programs that belong in the platform layer and business processing that belongs in the application layer can seem fuzzy. The rule is: If it delivers direct business value it’s an application. If it helps provide computing resources, it’s a platform.

Over the next month we’ll look, layer by layer, at how to manage your technical architecture. And you thought you were having fun now.