 | Level: Introductory Michael Russell (MikeRussell@VickiFox.com), Application Architect, Vicki Fox Productions
10 Aug 2004 The quality of an application depends on more than how well it satisfies user-functional requirements. Even an application that successfully makes it through development and deployment can encounter grumblings from users and system operators if it is hard to use, keeps failing, is difficult to diagnose, or consumes excessive resources. In addition to user-functional requirements, you must also consider how well the application satisfies the non-functional requirements and fits into the organization's operational environment.
After the celebration
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.
Diagnosing the causes
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.
Understanding the influences
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
In summary
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.
Stay tuned
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.
Resources - 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).
About the author | 
| | 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. He can be reached at MikeRussell@VickiFox.com. |
Rate this page
| |
