Browse

All Posts in Technology

|In: Architecture|Last Updated:

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

|In: Industry Commentary|Last Updated:

According to popular culture, we always have choices.

True enough. When a gun is pointed at your head, though, you should probably hand over your money: We may always have choices, but sometimes only one merits consideration.

Which brings us to the second in our two part series that asks the musical question, “Do you have to buy Microsoft’s products?” Last week’s column looked at operating systems and concluded that a typical CIO has two choices: Either use a mixture of Macintoshes and Windows systems — the Macs for general-purpose workstations and Windows for desktops running client/server business applications along with the standard word processor/spreadsheet/e-mail software — or simply standardize on Windows across the board.

This week we look at office suites. The contenders: Microsoft Office and Anything Else. (Astute IS Survivalists will conclude that this won’t be a detailed comparison of features-and-functionality.) The question isn’t whether Microsoft has a monopoly. In the case of office suites it clearly does not, since except for your perceptions and requirements (and probably a few hidden APIs that aren’t very important), Anything Else plays on a level field.

As we did with desktop operating systems, we’re looking at this architecturally. The question is, if you buy Anything Else, do you face technological inhibitors to business integration that can only be solved through unacceptably expensive or unreliable kluges. (“Kludge” has a lot of definitions. Here’s mine to add to your list: the paperclip attaching the bag to the box you already connected to the system with a Band-Aid.) In other words, it all boils down to file formats. We’ll look at word processors for this analysis; the same issues apply to spreadsheets.

If you don’t share files electronically you have complete freedom of choice. Use paper (and fax) as your medium of exchange and every employee can use a different word processor without causing any serious problems. Yes, I know how hard it would be to support. (The answer: Not Very.) There’s no significant impact on your architecture. You don’t need any standard, let alone making it Office.

If you share files only internally and not with your business partners, there’s no reason to choose one office suite over another except price. You won’t find all that much difference in functionality (unless you really like Mr. Paperclip). From a features and functionality perspective they’re all awesome.

So if you’re not using Office now, don’t waste your money converting. This is the perfect time to procrastinate, because a dollar tomorrow costs less than a dollar today.

What if you do exchange files with your business partners? Here’s the most basic rule in the systems integration book: Standard native data formats are better than neutral interchange formats, which in turn beat custom interfaces. Custom interfaces are sometimes, but not always, superior to manual re-keying. (They may cost more than the manual labor.)

For word processors, a standard native data format means both parties using the same file format, and today that means Microsoft Word. Rich Text Format, or RTF, is a neutral interchange format, which makes it second best even if it were perfect. If you’ve ever used it you know it isn’t — even automatic numbering fails to convert accurately. ASCII? Forget it — formatting matters.

So like it or not, if you’re e-mailing documents and spreadsheets to business partners in any volume, you only have one choice.

And Microsoft won this one in a fair fight, by betting on Windows when WordPerfect bet on OS/2 and Lotus bet on its lawyers.

Comments