9 Warning Signs of Bad IT Architecture

A sound IT architecture keeps your company’s technology strategy humming. From kludges to manual re-keying to redundant apps, these are the telltale indicators of an IT environment on the brink of collapse.
Chances are someone at some point spent countless brain cycles planning your organization’s IT architecture before handing the grand plan off to someone else to build it out, and then to someone else to maintain it as your computing environment inevitably grew. And, chances also are, somewhere along the line, best intentions faded in the face of expediency, departmental politics, and general mismanagement, eroding what was once a coherent architecture management strategy into an ongoing series of independent, case-by-base decisions about each technical component.

How do you know if your organization has strayed from the path? Here are nine warning signs that bad IT architecture has taken hold of your organization.

Manual re-keying

Manual re-keying might not be the biggest cost companies pay from bad architecture, but it’s certainly the most obvious one. Hiring human beings to serve as the interface engine connecting incompatible applications isn’t just expensive; it’s de-humanizing.

Architectural impact: Keying errors result in inconsistent data.

Direct business impact: Manual re-keying drains business resources away from value-creating activity.
Collection of point solutions

Everyone wants their work supported by a “best of breed” solution. Define “their work” too narrowly, though, and everyone has to visit so many applications to get their work done that there isn’t enough time to get their work done.

Meanwhile, unless IT spends a lot of time building interfaces to connect all of these point solutions, you’re back to re-keying again.
Architectural impact: Point solutions drive need for system interfaces and the number of platforms that must be supported. Collections of point solutions also often creates need for manual re-keying.

Direct business impact: Collections of point solutions slow down business processes and drive up training costs — in addition to re-keying issues.

Redundant applications

Every business application solves business problems. Solving business problems is good, so solving them more than once must be even better, right?

Of course not, and yet a lot of companies keep lots of redundant applications around, either because they overlap but still have a few unique areas they support, or because they’ve grown through mergers and acquisitions but aren’t very good at integrating everyone into one business after the papers have been signed.

Either way, the money spent to support all of this redundancy is pure waste.

Architectural impact: Redundant applications drive need for system interfaces and the number of platforms that must be supported.

Direct business impact: Redundant applications drain IT resources away from value-creating activity and waste money on software licenses that don’t deliver new functionality to the business – and they often create the need for manual re-keying.

Redundant data

Very often, different applications need the same information to get their jobs done. You have two choices: Point them all to the same underlying database, which isn’t always possible, or synchronize their separate databases, which is often pretty messy.

Or there’s always that manual re-keying option....

Architectural impact: Redundant data drives need for system interface and often creates need for manual re-keying.

Direct business impact: Maintaining data synchronization across multiple databases is difficult, leading to effort wasted in reconciliation activities and getting wrong answers depending on which database is queried.

Too many interfaces

When you have redundant data and you decide to keep it synchronized, you need to build an interface. Even if you don’t, you often have to feed one system with results from a different one.

Either way, the more systems and databases you have, the more interfaces you end up building. It’s better than not having them, but as they accumulate, your architecture becomes more and more fragile, and you spend more and more time managing the interfaces instead of building new functionality.

Architectural impact: The more interfaces you have, the more fragile your system, and the harder that system is to maintain.

Direct business impact: Building interface after interface drains IT resources away from value-creating activity.

Faux-elegant integration

So you decide to solve your interface dilemma with an elegant enterprise application integration system, or a services bus, or some other form of middleware-plus-metadata that keeps everything clean.

And then, your developers figure two things out: (1) what your cool new system does is make solving the easy problems even easier; and (2) it doesn’t solve the hard problems at all. So instead of arguing with you, they rebuild the same old spiderweb of interfaces, but hide it inside the EAI system so you don’t know about it.

Architectural impact: Faux-elegant integration is just as fragile and difficult to maintain as interface glut.

Direct business impact: Faux-elegant integration still drains IT resources away from value-creating activity — and it’s expensive, too.

Kludges and workarounds

Maybe you were competing with an outside developer who lowballed a project. Maybe the business sponsor insisted on too short a deadline. Or maybe building a solution well would have ruined the business case for the project.

Whatever the reason, you wake up one day to discover a lot of your systems are held together with Band-Aids, chewing gum, and duct tape.

If you’re lucky, nobody will notice until after you leave or retire.

Architectural impact: Kludges solve immediate problems by creating fragile systems.

Direct business impact: Your cost of maintenance increases with each unnecessary solution, as does downtime, the cost of staff training, and the complexity of every subsequent project.

Obsolete technology

It’s mission-critical! It satisfies the business need perfectly! What do you mean you have to spend money to maintain it?

When you’ve built something on a version of Visual Basic that Microsoft hasn’t supported in a decade, that can’t read and write from any version of SQL Server that isn’t at least seven years old, and the only versions of Windows they’ll run on don’t have drivers for any of the printers you have in production — that’s what you mean. You have to spend money to maintain it.

Architectural impact: The more obsolete technology you have the harder it is to maintain and interface with new systems and equipment.

Direct business impact: Obsolete technology leads to increased cost of maintenance, while increasing your inability to adapt systems to new and changing business requirements.

White papers

You see a bunch of warning signs. You organize an enterprise technical architecture management group. You hire an expert or two. And their productivity is enormous.

Enormous, that is, if you measure productivity in terms of the number of white papers they publish. Changing how work gets done in IT? Of course they’ll change it. So long, that is, as everyone reads their white papers, admires their business, and follows their instructions.

Architectural impact: None. Everyone ignores the architecture group.

Direct business impact: The cost of wasted salaries, paper and toner — and even more employee cynicism about yet one more management fad.
This Article Source is From : http://www.cio.com/article/3214406/enterprise-architecture/9-warning-signs-of-bad-it-architecture.html