The 5 Keys for Business Computer Technology

Putting together the right set of technologies for a company is a very confusing process.  Vendors promise solutions which may solve one problem, but exacerbate another.  Islands of isolated technologies pop up which enable a process in one part of the company, but cannot be integrated into other processes in the company.  IT people often seem overworked, and in the midst of continuous fire-drills  fixing the same problems over and over again.

A well functioning company has systems that evolve with the changing business climate.  The computer systems stay up.  Different systems interact with one another.  And it doesn' cost gobs of money to maintain.  And IT people are able to work on improving systems instead of just struggling to keep them running.

The 5 keys below are just a few of the guiding principles for computer systems. There are others which may get described in a later set of papers, as well as a technology set which solves most of the common business problems,  using  standard technologies, which are available at low cost, or in some cases, free.   The goal is a minimum of maintenance, a minimum of IT personnel, and an appropriate amount of functionality.   Communication occurs using standard protocols.  Proprietary software is avoided unless widely available at low cost. 

The 5 Keys for Business

Use low maintenance systems.  A low maintenance system just works, and keeps on working for years. A system which crashes every week requires lots of IT energy.  An organization will end up with dozens, perhaps hundreds of systems running on its internal computers.  If every crash results in just 2 hours of work for an IT person, 20 systems alone will occupy one person full time just to keep the systems up.  This is very expensive, not only in maintenance people, but in lost work time by employees.

Plan for interoperability.  Not all systems have to work with each other, but many do.  Each time you double the number of systems, your quadruple the number of potential interoperability points.  A strategic plan has to be drawn up to deal with this issue.  You cannot build automated processes requiring multiple systems without interoperability. 

Use clear, easy-to-use, user interfaces. A system that is not easy to use may as well not be there.  A system that is not easy-to-use will require excessive training, and be error prone.  Easy-to-use does not mean lots of features.  In fact, an excess of features is that biggest cause of hard-to-use interfaces.  Your feature set should match what you need to do, and not anything more.

Don't sell your existing technology short.  Every day some vendor will come in and tell you why your systems aren't doing enough for you.  List to them, but always have a healthy degree of skepticism.  Does Office/XP really offer advantages to your company over Office/2000?  Why should you pay for an upgrade you don't need?  Do you really need to switch your website to use J2EE?  It's working fine as it is.  Is a 2.0Ghz Pentium really more useful to your secretary than 233Mhz system?  Most people can answer no to all these questions, although there are a few with good reasons to switch.  Think before you leap into new technology.

Keep it simple.  The final key is keeping it simple, and doing just enough to satisfy current needs.  Business systems evolve; they do not just get put into place, and start working day one.  A good business system starts out with humans doing most of the work.  Over time, the business process is refined  to eliminate the error-prone or repetitive jobs, and then if cost-effective, automate the others.

A corollary of simplicity is not to over-design.  Over-design comes at a price you may not be willing to pay, or even need to pay.

How many web sites have been built with the idea that they need to handle the traffic of Yahoo,  when they only get 25,000 hits at day, something that can be handled by a 486 based PC.  How many Oracle databases have been installed simply to handle a list of 500 customers?  When you grow big enough, re-factoring a system to scale it to a larger size is a nice growth problem to have.  You probably don't need scalability day one, and you probably don't understand your business needs well enough on day one to warrant paying for a highly scalable system.