Design Guidelines

Here you will find a number of system design techniques and considerations we have developed based on our years of experience and industry best practices.  It is our hope that they will help you and your staff design and build your information systems efficiently.

• Before you begin planning an IT project consider the following:

  • What technology do you really need?  Technology is not a cure-all.  Sometimes creative thinking can provide solutions to problems more quickly and effectively than an expensive information system.  Technology is often a part of the solution but too often is seen as the whole solution.
  • Do you make good use of the information you already have?  The quality and usefulness of the information provided is far more important than the volume.  A well designed system provides you with relevant information while filtering out what is irrelevant.  Many organizations could spend their resources more wisely developing an information filtering / processing or data analysis system (computer based or not) rather than one that simply generates more information. 
  • How will the project fit in with the rest of the organization?  Information is not understanding.  Technology and information systems must be designed to integrate with and support the rest of the organization.

• Designing an information system requires tradeoffs.  You must choose to emphasize some factors at the expense of others.  The following list includes the major factors to be considered.  The degree to which different items compliment or interfere with each other will depend on the specific system, so you will need an experienced software / system designer (either internal or external) to help you evaluate the tradeoffs.  However, you can rank each of these in order of importance to your project to minimize the amount of the designer's time required.

  • Functionality - What do you need the system to do?
  • Cost - How much can you afford to spend on the system?  Don't forget post-production maintenance and support.
  • Security - How sensitive is the information contained in the system and how much damage would result if it were compromised or lost?
  • Scalability - How easy must it be to expand the system so it can accommodate a greater work load?
  • Performance - How quickly do various system functions need to respond when under a typical work load?  a heavy work load?
  • Time - When does the system need to go into production?
  • Reliability - How often can the system go off-line (planned or unplanned) without seriously harming the company?
  • Availability - What percentage of the time must the system be on line?
  • Data Integrity - How resistant must the data be to corruption?
  • Recoverability - How quickly must the system be restored to full operation in the event of a failure?
  • Flexibility - How easy must it be to add / change functionality without significant technical changes, like code or database changes?
  • Manageability - How easy must it be to administer the system?
  • Maintainability - How easy should it be to modify the system when significant technical changes are required?
  • Concurrency - How many simultaneous users must the system support?
  • Ease of Use - How easy must it be for non-technical, untrained users to learn the system and trained users to use it?
• Of the design decisions listed above, only time and cost can be quickly established and set aside with only brief monitoring requirements.  All of the rest must be thoroughly thought through during the planning phase of the project and fully incorporated into the design of the system before you start building it, regardless of what importance you have assigned to them.  Just because you decide that security is more important than performance doesn't mean you shouldn't plan for the best performance possible within your security constraints.  For instance, if you write most of the code and then decide to go back and optimize it for performance or incorporate security measures, you will spend more time coding and debugging than necessary and your system will not perform as well or be as secure as it would have been if those considerations had been built in from the start.

• Be complete and creative in designing the system to meet your current and future needs but don't try to do everything at once.  First design the ideal system (what the system would do if cost & other constraints were not an issue).  If you have the resources to complete the ideal system as designed then begin building it, but if you don't (which is usually the case), decide what functionality is most critical and start there, keeping in mind the additional functionality that will be added in a later version.  Even more important, you will almost certainly think of changes and additions that need to be made to functionality after construction of the system is well under way.  There are two ways to deal with this:

  • Hold off making any but the most simple of these changes until you have completed the system according to the original specifications and put it into production.  Once you have a stable system in production you can then design and create an updated version to handle the changes.  Using this phased approach can save you a great deal of post production headache in fixing bugs and dealing with corrupt or missing data.
  • Use Agile development techniques to add flexibility to the project.  These techniques, when properly integrated with a solid plan, focus on initially delivering the most basic possible level of functionality and then incrementally adding additional functionality until the system reaches its completed state.  This allows development to be more adaptable to change, but at the expense of taking longer to reach completion.
• Prototype complex systems before finalizing their design.  The prototype does not need to be very robust or handle much use and therefore can be built using a "quick and dirty" approach.  Its purpose is to provide users a low cost, hands-on, rough draft of the system so they can provide feedback on what functionality needs to be added or changed before a lot of time and money are spent building a production system.  Once everyone is happy with the functionality of the prototype (though not necessarily its performance and quality) it essentially becomes the functional specification for the production system.  While prototypes are generally not cost effective for simple systems they can provide tremendous time and cost savings for complex systems as well as increasing the user satisfaction level for the initial production version of the product.
• Use the right tool for the job.  Many systems have problems after they have been in production for a while because they were developed using inadequate tools and / or insufficiently experienced personnel in order to cut initial costs.  However the long term cost of dealing with problems ends up exceeding whatever was saved in development.  If all you need is a prototype or a non-mission critical system for a few users, tools such as Microsoft Office can provide for very rapid, relatively inexpensive application development.  However you are better off spending the time and money developing systems using enterprise class software such as Microsoft SQL Server and the .NET platform if your application requires centralized data management, high levels of stability & security, more than a few concurrent users, etc...

If you have any IT questions that aren't answered here please feel free to contact us.  Whether you just need a little informal (no charge) guidance or need experienced designers and developers, we're here to help.