Integrated IS Plan #5: Managing Technical Architecture (first appeared in InfoWorld) | IS Survivor Publishing

Previous Post: / Next Post:


Integrated IS Plan #5: Managing Technical Architecture (first appeared in InfoWorld)

Share

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 […]

By Bob Lewis | August 17, 1998
Topics: Architecture, Organizational Effectiveness, Policies and Procedures, Strategy and Tactics, Technology | Comments Off

Share

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.


Comments are closed.

my photo

























Visit our store to buy books authored by Bob Lewis.


















my photoBob Lewis is a senior management consultant with Dell Services. He has published these columns once a week in one form or another since 1996.

Disclaimer: All opinions, statements, representations, allegations, images (if published) and anything else that appears here is the sole responsibility of the author. Dell has and had nothing to do with it, other than saying it's okay to continue publishing KJR.

Recent Posts

Topics

Blogroll


Archives