Credit: flickr/Eirik Newth
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 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.
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.
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.
Sign up for Computerworld eNewsletters.