“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.