IncidentMonitor™ITIL and Help Desk Software Architecture

IncidentMonitor™ was designed to be a scalable request management system, meaning you can add servers to the system as your call center grows in size. IncidentMonitor™ can be run on a single server for smaller environments (less than 50 support people supporting low thousands of users) up to multiple servers for larger environments (1,000's of support people supporting millions of users). The architecture picture below shows a high level view of the system. The three rings in the center represent the server or servers, depending on the size of your environment.

Don’t be fooled by older products on the market that use old client/server technology that won’t scale up as your business grows. All of the performance leaders in the TPC's Transaction Processing Performance Council's (TPC) benchmark tests use multi-tier architectures like IncidentMonitor™'s. Don't take our word for it, take a look for yourself on TPC's web site. The TPC is a non-profit corporation founded to define transaction processing and database benchmarks and to disseminate objective, verifiable TPC performance data to the industry.

Keep in mind that if a vendor hides their product architecture from you, more than likely it means they have something to hide.

Benefits Of A Good Architecture

A well designed architecture provides a distinct advantage over other help desk systems that haven’t been designed to accommodate change. An architecture that is open and can easily deal with change, will undoubtedly be able to adapt to the changes and with very little effort and additional cost. The advantages of a well designed architecture may not be readily apparent to you until you need to make some changes to your system in order to support your business. The one thing that is constant in business is change. Why not make sure you are ready for it. The following is a list of benefits a good architecture will provide:

• Architecture should provide the basis for supporting your changing business and the needs of your user community.
• Leverage what you already have, so you don't need to reinvent the wheel.
• Easily add capacitiy to the system so it grows as your needs grow.
• Connect your business with other businesses or departments by merely agreeing on a data exchange format.
• Never have a system imposed limit due to design decisions.
• Having an open system allows you to adapt to changes that the future holds.
• You never know what the future holds and your architecture shouldn't limit you to functionality today.
• Be able to use other systems or components from within the architecture.
• Leverage the architecture in other applications.
• Architecture should be able to take advantage of new technologies as they become available.