It is Friday and the SHEEP Web team is celebrating the successful installation of the new Java technology-based rich-client sales application. Everything appears to be working as designed. The users are happy. The project manager is finally relieved. The biggest decision being made today is who will get the last piece of pizza.
On Monday, the phones ring nearly non-stop. Several users call and ask, "What does RemoteException mean?" or, "What is a JNDI lookup?" Other users complain that they keep accessing the training system when they want to access the production system. The operations support team points out a log file that is growing very quickly, and says they may need to restart the server application to truncate the file. Suddenly, the SHEEP Web team is busy just keeping the application running.
A month later, the business sponsor points out certain screens in the SHEEP application that take many minutes to load and affect productivity. The developers have created a large number of quick-and-dirty fix scripts that run periodically to clean up tasks and files and restart services. The application is getting more fragile and complex.
This scenario seems to happen with many applications that are successfully deployed, whether custom built or off-the-shelf. Within months the well-crafted application is covered in virtual duct tape to hold it together.
The SHEEP Web team holds a meeting to determine what went wrong.
The team members followed the best-of-breed methods and patterns. They had active participation from the user community, so they understood the functional requirements well. They picked an appropriate reference architecture based upon the application class. They used the latest tools and techniques. They had active quality assurance and configuration management during the project. The source code followed the best object-oriented principles.
Figure 1 illustrates the way developers often think of an application. They think of the components that make up the application and how those components hold together. The boundary of their design is the functional requirements of the application. The SHEEP application figuratively suspends in isolation, and developers make the design decisions from this isolated view.
Figure 1. The developer's view of an application
Quality is often defined by how well the application meets the user's functional requirements, follows the best coding practices, uses the best methodologies, and passes various testing.
This narrow view of application quality even extends to the enterprise level. Too often, architects concentrate on the applications in the enterprise as isolated islands and on how to connect them.
However, no application exists in isolation. As Figure 2 illustrates, applications exist in a specific operational environment. An application consumes limited system resources, such as memory and disk space. It generates by-products, such as log files and temporary files. Applications have to share the operational environment with other applications. Specialized applications monitor the business applications. The operational environment has boundaries and security mechanisms to keep out malicious applications. All of these interrelate in one or more ways.
Figure 2. The operational view of an application
So, what went wrong with the SHEEP application? This column looks at the following causes:
- Picking an inappropriate architecture
- Overlooking the operational environment
- Forgetting the non-functional requirements
Another cause, compromising the design to satisfy business constraints, is a management and political issue, and is beyond the scope of this column.
The causes of poor application quality correspond to failures to address the major influences on the application. More accurately, quality is how well the application satisfies all the influences and expectations. Figure 3 illustrates these influences.
Figure 3. Influences on an application
- The functional requirements describe what the application does.
- The non-functional requirements describe how the application performs.
- The operational environment describes where the application runs, who runs it, and when it runs.
- The business constraints describe why the application is needed. This includes the value of the application to the business, the return on investment, funding, delivery schedule, resources, and more.
Architects and developers enjoy tackling the functional requirements and tend to concentrate their efforts in this area. A good evidence of this is the volume of books about specific technologies, languages, patterns, and methods that all speak to the functional aspect of the application. After all, the functional aspects are easier to understand, generally involve a limited number of solutions, and are exciting to developers. The other influence areas do not have clear-cut solutions, involve making trade-offs (none of which are ideal), and are boring to developers.
The application and its influences tightly interrelate. A choice made in one area affects all of the others. For example, using a distributed architecture (functional and operational) affects the application's maintainability (non-functional) and cost (business).
Picking an inappropriate architecture
Even with well-understood functional requirements, sometimes an architect chooses an inappropriate architecture. This happens for many reasons, including not knowing alternative approaches or platforms, political or career pressures, the desire to use the latest hype-driven products, and others.
In the opening example, the Web team created the SHEEP application. The business requirement was simply to create a mechanism that provided fiber for cloth. The SHEEP application fulfilled this requirement by creating wool. However, the business actually thought of a COTTON application since it fit better with its existing operating environment.
You can often satisfy the functional requirements with multiple solutions. Ideally, the architect evaluates the trade-offs associated with each solution to find the one that best fits the business' operating environment.
Overlooking the operational environment
As mentioned before, an application does not exist in isolation. It exists within an operational environment -- the life-support system for the application.
When meeting with the business users to obtain the requirements for the application, you realize that they are not aware of or concerned about what it takes to support the application. Their interest lies in how well the application supports their business needs. As a result, the architect must include the operations (or infrastructure) team in the requirements and design phases. Don't wait until it's time to deliver the application to work with the operations team. The operations team supports the application, and it has different requirements than that of the business community.
Figure 4 illustrates the major concerns that the operations team has when supporting an application. These concerns interrelate so that decisions made regarding one concern impact the others.
Figure 4. The operational environment
- User support -- Provide an interface with the user community
- Problem resolution -- Diagnose problems and perform repairs
- Configuration -- Manage the setup, topology, and customization of computers, networks, system software, and applications
- Assets -- Manage the computing resources (inventory control) and make appropriate resources (processor, memory, and disk) available to applications
- Security -- Manage the accessibility of the computers, network, and applications
- Performance and capacity -- Measure computer and application performance and estimate growth rates to determine current and future capacity needs
- Changes and updates -- Manage changes to applications and updates to system software and program products
- Operations and monitoring -- Monitor the applications to ensure each is running as planned and to discover problems proactively
- Backup and recovery -- Provide support for system restoration in the event of data or system failures
Forgetting the non-functional requirements
Just as architects and developers sometimes overlook the operational environment, they also sometimes forget the difficult-to-quantify, non-functional requirements. In many cases, when non-functional requirements are addressed during the initiation phase, the requirements are poorly stated or expressed in terms that are difficult to evaluate or act upon.
One possible reason why developers forget non-functional requirements is the difficulty of negotiating them with the business community. The business might want around-the-clock operations, yet the users only work normal business hours. The business might want excellent usability but be unwilling to pay for usability testing, or it might want sub-second response times on queries that process millions of data records. And the list goes on.
Architects build the non-functional requirements for the application by balancing the desires of the business with the realities of the operational environment, application architecture, and business constraints.
The non-functional aspects of the application interrelate. A design change that addresses a performance issue likely affects the reliability and maintainability of the application, among other aspects. Architects should consider the trade-offs associated with each solution.
The major, non-functional requirements can be divided into two categories -- observable and non-observable. Observable requirements are those that can be tested or are discernable at runtime. Non-observable requirements cannot be objectively tested and must be subjectively evaluated.
With statistical sampling, you can measure the observable, non-functional requirements, including:
- Performance -- The responsiveness of the system, for example, response time and throughput
- Security -- The measure of the system's ability to protect from malicious agents and unauthorized changes, while permitting legitimate use
- Availability -- The proportion of time the system is available (up and running) to service user requests
- Reliability -- The system's ability to provide consistent behavior, perform the intended work, and recover from failure
- Capacity -- The resource usage of the system, including projected growth
- Usability -- The ease with which the target audience can use the system
The non-observable, non-functional requirements include the following:
- Maintainability -- The ease with which the system can be changed, whether for bug fixes or to add new functionality
- Portability -- The ease of moving the application to other operating environments
- Integrity -- The ability of the system to protect and preserve transactions
- Scalability -- The ease with which the system can move to larger or distributed computer environments to satisfy processing demand
- Manageability -- The ease with which the system can be reused, deployed, and tested
- Safety -- The ability of the system to not harm users, including physical harm, as in medical systems, or financial harm, as in accounting systems, or other forms of harm
- Efficiency -- The assessment of how well the system utilizes resources and how it affects other applications in the environment
You can create an application using the best practices, best tools, and best methods, and it can still be of poor quality and not satisfy users' needs. Overlooking the influences on the application sometimes causes this poor quality. Broadly speaking, four things influence application quality:
- Functional requirements
- Non-functional requirements
- The operational environment
- Business constraints
Picking the wrong architecture to meet the functional requirements causes poor results. Overlooking the nature of the operating environment and support needs leads to poor end quality. Forgetting the non-functional requirements leads to undesired behavior. Architects and developers must balance all the influences to pick the best solution, none of which is ideal.
This column is the first in a series about the causes of poor application quality. Subsequent columns elaborate on examples of operational environments and non-functional requirement problems. Future columns start with an example of the problem, discuss the nature of the problem, and conclude with the questions architects should consider during design to reduce these problems.
- Read the author's other articles in the Quality busters series on developerWorks.
- Read "Software architecture in practice," authored by senior members of the Software Engineering Institute, for an excellent introduction to the concepts and practices of application architectures (Addison-Wesley, 1998).
- Check out "Software Requirements" for a good overview of gathering and
resolving requirements (Microsoft Press, 1999).
- For one of the best books to learn to think beyond just the application and look at the whole system, read "Quality software management: Systems thinking" (Dorset House Publishing, 1992).
- Read "AntiPatterns: Refactoring software, architectures, and projects in crisis," which, unlike the many patterns books that show prototypes for how to do things right, creates pattern descriptions for how things are done wrong (John Wiley & Sons, 1998).
- Read "The inmates are running the asylum: Why
high-tech products drive us crazy and how to restore the sanity", in which author Alan Cooper argues that many modern products are designed by engineers for engineers rather than for the general public (Sams
Publishing, 2004).
- Check out "Do as they need, not as they say," in which the author explains why it's often necessary for architects to steer the requirements and determine the user's needs instead of just implementing what they think they need (O'Reilly
ONJava.com, April 2004).
- Learn how to successfully deploy your application in "Deploy, Not Destroy" (Software Development, Jan 2003).
Michael Russell has a Bachelors Degree in Physics and a Masters Degree in Computer Science. He was a logistics engineer, a technical services manager, and a certified IT architect at IBM for nearly 14 years; he is currently a Web application architect for a resort company in Orlando, Florida. He has experience in Windows, UNIX, and OS/400 environments and uses Web technology for entertainment through his own company, Vicki Fox Productions.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
