All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

Electric fish are fascinating critters (at least to me — regular readers will remember I spent years studying these suckers). One of their more remarkable features is their electric organ – the gadget they use to generate electricity. It started out as a muscle. Aeons of evolution eliminated its ability to contract while increasing the amount electricity its cells generate.
That’s how evolution works — it grabs whatever is convenient and adapts it for whatever use is called for.

We do a lot of this in IS as well, continually adapting and evolving our legacy systems, databases, and computing platforms to whatever new requirements pop up. And this is a good thing to do.

Eventually, though, we find ourselves in evolutionary dead-ends, where our adaptations, kludges, shortcuts, and patches turn into barriers that prevent further change. Mother Nature handles this situation through extinction. You’d probably prefer a different strategy.

The alternative to evolution is design, and design is what distinguishes architecture from gluing a bunch of stuff together wherever it happens to fit. In this, the final article in our series on technical architecture (hey, don’t cry!), we deal with design.

Architects, whether designing IS infrastructures or office buildings, have to be both technically and artistically inclined. So far we’ve talked about the analytical, technical aspects of architecture.

Good designs, though, are as much a matter of art — aesthetics — as of technical prowess. Aesthetics pays off, because ugly designs turn into unreliable, clunky, nasty implementations. It can’t be logically proven, but it’s so nonetheless.

Defining aesthetics is more or less impossible, though, because aesthetics is mostly a matter of taste. You still need to make consistent design decisions, though. To do so, develop a set of clear, consistent principles designers can use as a starting point. And to develop good design principles, you need to understand the important design issues.

A design issue is any technical problem you need to solve or computing function you need to deliver on a regular basis. For example, physical connectivity is a design issue. You have several design principles to choose from: One connection per end-user device with network gateways to resources as needed; multiple end-user connections (for example network, modem and desktop TAPI); or ad hoc decisions as seem appropriate for each situation.

I’m a big fan of a single connection to the desktop and doing everything through the network, but that may not be the right solution for you.

Take another design issue: How to handle data redundancy. You have several design principles to choose from. You can: modify your systems to eliminate redundancy; define master/slave relationships among your data stores and periodically resynchronize everything; build technology that propagates update transactions to all redundant data, keeping everything synchronized in real time; or live with the mess and not worry about the redundancy. Pick one and don’t lose your guts.

In fact, for each design issue the most important thing is to pick just one design principle and live with it — and also, make sure your design principles are consistent with each other.

Which brings us to standards. Many design principles establish the need for a standard. In fact, every standard you establish should stem from a design principle — otherwise you don’t need it. For example, you may establish a design principle that all data will be stored in a single mainframe RDBMS, accessed through standard ODBC calls. This principle calls for selection of a standard ODBC-compliant RDBMS.

Now the really hard part: Your design principles are important, but they aren’t religion. You’ll sometimes have to make pragmatic decisions that violate a design principle or standard. Figure a way to mitigate the impact, and do what’s right for the business.

Your company’s strategic, tactical, and infrastructural goals drive the applications, information, and ultimately the computing platforms you provide. These define the design issues you need to resolve, which in turn cause you to select a set of consistent design principles.

It’s these design principles that lead you to choose specific technical standards.

Otherwise, your standards are just red-tape.

Comments

|In: Architecture|Last Updated:

Years ago, I used to tell a joke with no punch line. It went, “How many vendors does it take to print a memo?”

For us, at the time, the answer was 10: (1) IBM – PC; (2) Microsoft – DOS; (3) Automenu – DOS menuing front end; (4) WordPerfect – word processor; (5) Synoptics – Ethernet hubs; (6) Anixter – Ethernet cable; (7) Novell – NOS; (8) Compaq – file server hardware; (9) Hewlett-Packard – laser printer; and (10) Pacific Data – font cartridge.

“Imagine,” I was fond of saying, “how many vendors we’d need to do something complicated.”

Understanding what computing functions are involved in addressing common end-user tasks, and what products deliver those functions, is an important goal in managing technical architecture.

This is our 10th article on creating an integrated IS plan and the sixth on technical architecture. We’ll be done soon. I promise. We do have a few more topics to cover, though, and managing your technical architecture well is awfully important.

As last we left our heroes, they had just finished mapping platform-layer products to computing functions, scoring each product in terms of how well it serves its purpose and also looking for redundancies and incompatibilities. Let’s see what they’re up to now … .

Our product/function grid doesn’t address integration and design; that is, it doesn’t ensure that anything actually works.

To do that, some drawings will help.

The first drawing is a physical connectivity map of your enterprise. It shows, not every device on your network, but every class of device that connects through your network.

Your goal in creating this drawing is ensuring that electrons can flow between any two devices that need to communicate, so next to each connection, list the types of service or session available through it. For example, you may have a mainframe connection that only supports 3278 terminal sessions (LU6.2 sessions, to be precise) through the network.

That’s important to know, because that means your connectivity will have to change when you start using the mainframe as an application server. If your mainframe connection supported TCP/IP communication and T3270 sessions, on the other hand, it would work just fine for the new requirement while still supporting the old one.

The second drawing, really a set of drawings, is a client-centric view of your platform environment. Create a drawing for every device that hosts at least one client process or acts as an end-user workstation. Put that device in the center of the drawing and around the periphery depict the resources – server processes – that device must access.

Then, for each resource, list the client process needed to reach it, where that client process runs, and what protocols and connectivity are required to achieve the connection.

(Remember that “clients” are software processes. Although many clients run on desktop computers, that doesn’t make desktop computers clients, and client processes often run on server hardware. A commonplace example: When you fill out an HTML-based form on your browser, the browser isn’t the client. The client process runs on the Web server, perhaps in the form of a Perl script. That client process interacts with a host computer in the background, formats the results, and sends them back to your browser.)

Your goal in creating this second set of drawings is to look for opportunities to simplify. The more commonality between different connections, the simpler and easier it is to manage your architecture.

Don’t, however, fall into the trap of equating “simpler architecture” with “that’s what we need to do.” When simplifying your architecture reduces the level of functionality you provide, be careful.

It may, for example, seem attractive to use a browser as a universal terminal and Web servers as universal clients. It may to you, but browsers make for second-rate interfaces when compared to a full-featured GUI.

As with the rest of the process of managing architecture, keep the purpose in mind at all times, and that’s making sure you know how to connect resources to the processes that need them. Don’t get lost in the technique, because if you do, you’re just painting by numbers.

Comments