All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

“Technical architecture” is one of those phrases that’s easy to use and hard to define with any precision. I’ve read a number of definitions and have drafted a few myself. Here’s the best I’ve been able to come up with:

Technical Architecture is the discipline of organizing a company’s suite of applications, information repositories, and technical infrastructure so as to encourage coherent design of the entire computing environment rather than dealing with the design or selection of each component in isolation.

Architecture is the highest of the three levels at which technology can be described, the other two being engineering (also called “specifications”), and as-built documentation.

Managing technical architecture (or “enterprise architecture” — a semantic escalation that takes the so-called “business architecture” into account) is a tricky business, because architecture teams can easily degenerate into either academic white-paper factories or bureaucratic barriers to project progress. Even if you avoid these pitfalls, you’re left with the challenge of explaining to project sponsors and the executive committee why investments in architecture … which usually take the form of more-expensive, longer projects than would otherwise be budgeted … are necessary.

Most explanations are eye-glazing, ear-numbing accounts of data redundancy, operating system incompatibilities, or the need for more business logic re-use. These are abstractions, and business managers justifiably lose patience when they hear them, because they don’t pass the So-What Test. As a better conversation starter, here are Seven Warning Signs of Bad Architecture — signs they can understand at a glance. They are:

  • Manual re-keying: End-users spend time and effort either re-keying data from printed reports into data-entry screens, or cut-and-pasting data from one data-entry screen to another. You don’t have to connect the dots for business managers to understand that this costs them time and ensures that bad data will creep into the company’s databases.
  • Collections of point solutions: When it comes to getting their work done, employees are almost always better off using one mediocre application than five separate, really terrific ones. With one client, the sales force had to consult five separate systems before making one sales call — a process that required a half hour and that illustrates the business impact nicely.
  • Redundant applications: Especially among companies that have grown through acquisitions, it’s very common to end up with more than one system that does the same exact work. Supporting them all diverts time and effort from value-creating activity, wastes money on software licenses, and often creates need for manual re-keying. And, it usually means IT has to maintain redundant platforms to run them all.
  • Redundant data: Often a consequence of using a collection of point solutions, redundant data means synchronizing data across multiple databases. This is difficult and error-prone. It leads to effort wasted in reconciliation activities, and to getting different answers to the same question depending which database is queried.
  • Too many interfaces: It’s called the spiderweb, the spaghetti diagram, or the hairball (when it’s entirely out of hand). It means you’re connecting point solutions, redundant applications and redundant data through a passel of custom-coded (usually batch overnight) programs. The result? An increasing fraction of project effort goes to maintaining interfaces and regression testing to make sure nothing breaks, while an increasingly tiny fraction goes to creating new features and functionality.
  • Kludges and workarounds: A kludge is when you solve a problem through the use of band-aids, chewing gum and duct tape. It works, but it makes everything more fragile and harder to maintain than would have been the case had you used a welding torch or stainless steel bolts. Kludges and workarounds are ugly inside and out.
  • Obsolete technology: Yes, I know people who still lament the demise of the original VW bug. Some readers of this column undoubtedly wish they were still programming in MUMPS or relying on PICK. Business executives don’t always grasp the hidden costs of relying on (I’m not making this up) systems built on dBaseV for DOS. If that’s the case, explain … patiently … how much it costs to write a custom printer driver for dBaseV for DOS so your programs can, for example, send reports to laser printers you can actually buy.

Be careful in using this list, though. Once you walk your company’s business executives through it, they’re likely to ask you what you can do to fix things.Before you prod them into asking the question, make sure you know the answer.

Comments

|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