Can Agile reverse the broken traditional decomposition approach?

One of the challenges with traditional software development was to understand and estimate software through problem decomposition.   This process has involved taking a complex problem specification through recursive decomposition until you have a set of problems which are well understood.  Ironically it is much like how we are taught to solve problems from advanced math disciplines such as differential equations (everyone should try one of these classes).

Unlike a math problem with a concrete specification, software concepts tend to be much less understood.  These traditional software methods would depend on designers, architects and leads performing the decomposition required to provide specific designs and exact estimates.  Unfortunately this cannot occur without a complete specification.  While this problem should be obvious, often teams fall prey to pressures created by those removed from the process who do not understand. 

Agile processes embrace the reality the specification is a work in progress and instead focus on a compositive process whereby a solution is built up one step at a time.  Instead of wasting time & resource on an arbitrary big picture definition (which may not be right from the outset), the focus switches to building up a solution with regular checks and balances. 

Would you agree that Agile effectively helps reverse this backwards approach?  How might this change your approach to leveraging agile?

 

Defining enterprise application architectures – important non-functional requirements

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.