Enterprise applications present interesting challenges to those tasked with defining the architecture and design for the application.   In some cases the application is solving a well-known problem in a better way and other cases it is solving a still evolving problem.    In addition, more and more customers are seeking OOB applications for their enterprise solutions – so they expect to achieve their needs with limited “customization.”  This begins a series of posts to discuss the architecture of enterprise applications.

Regardless of the actual problem being solved, there are many non-functional requirements which should be accounted for in the system architecture.   When building these applications, the “architecture” will be a significant factor in the success of the application and organization building/supporting it especially as it relates to the non-functional requirements.      

Below are some of the non-functional requirements which I have found to be very important to customers and highly dependent upon a good architecture.

  • Flexibility.  Customers generally have a need for high degree of flexibility.  This will include the business rules embedded in the application, configurations, look & feel, etc.
  • Integrations.  Generally there is a need to connect the new application to existing tools and processes.   It is not unusual for these tools to be proprietary or be dated 3rd party applications.
  • Scalability.  Applications must scale to support large numbers of users.  Often these users can be dispersed around the globe and may include users from external companies.
  • Global.  This should not be confused with scalability as this reflects the reality that users are more and more spread across the world.  This requirement impacts how the system must interact with users.
  • Dependability.  Application must be dependable – both application availability and data integrity.  Users have come to depend on software and have a low tolerance for outages or data loss.  In some cases there are also regulatory rules at play.
  • Long Install Shelf Life.  An “Installation” will have a long shelf-life – customers cannot afford to re-install once a year.  It is not unusual to have enterprise applications in use for 3-5 years.
  • Long Development Shelf Life.  I have listed this separate because while it sounds similar to above it should be considered separately.  This requirement relates to the reality that a product will be under development for many years and modules of code may exist for 5-10 years before being re-written.  In addition this code/architecture will often out-live several generations of engineers within an organization.

Can you think of others?   The next post will begin considering how these impact the system and ideas for meeting the long term needs.

Advertisements