An Architect's Perspective on Application Quality: Part 2

Java Development News:

An Architect's Perspective on Application Quality: Part 2

By Allen Stoker and Joel Ottinger

01 Aug 2006 |

This is part two of a series on application quality from an architect's perspective. Be sure to read part one.

I do not claim to be an expert in the area of quality, but as an architect for a business area that includes multiple systems, it is my responsibility to define solutions that are functionally accurate, performant, robust and reliable. These application characteristics can only be achieved with focus on quality. From an abstract viewpoint, heightened levels of quality require processes that impose more scrutiny of the product, which inherently translates to time and resources. In the acceptance of my responsibility, I must apply pragmatism to my architectural decisions to best help the business reach achievable goals within their targeted budget. It is from within this paradigm that I provide my commentary on quality.

In my first article on this topic I suggested that the area you target to achieve your measure of quality is up to you. I highlighted the need to define and focus on your goals, and I drove into two quality-focused goals to discuss how they could be implemented. As noted in the discussion thread for that article, the business or customer (however you define them) typically have expectations of high quality even if that expectation has not been formally communicated. It is critical to both define your goals, and challenge them to ensure that you can answer those challenges:

  • What is the desired level of quality (How good is good enough)?
  • What is the cost to achieve the desired level of quality?
  • Will the benefits of achieving those goals outweigh the cost?

I believe that the overall key to higher quality is the adherence to a well-defined process. It is far less important which process you follow, as long as you continue to follow that process. Quality is most readily achieved through consistent repetition. In an organization where ten teams follow ten different processes it is difficult (if not impossible) to audit quality across the teams. When a process is followed consistently, deficiencies in the process become evident and can be addressed with a common solution increasing the quality for all project teams. Following a prescribed development methodology gives you the leverage of reusing what others have learned; however, it is still up to you to implement the process that will best align with your stated goals.

While readers of this article will come from organizations that have achieved varying levels of maturity in their quality practices, most of us face critical timelines and budgetary constraints that must be factored into our quality goals. These constraints drive us to the implementation of processes and tools to help us squeeze every possible drop of quality out of our development budget.

I personally use a variety of tools for static analysis, code coverage and JVM monitoring. All of these tools provide valuable pieces of information that when properly combined give me insight to the overall quality and capabilities of my applications, but none of them can take the place of proper processes. Tools, however, are not the answer, they are just enablers. It is critical that tools are selected and implemented based on their support of your process. If you don't have good processes, tooling along will not solve your quality issues.


I believe the most essential element in the production of a quality product is the requirements. Requirements must encompass both functional and non-functional aspects of the system including performance and reliability, and are the primary communication medium for the definition of quality goals. The combinations of both functional and non-functional requirements are critical to the development of an appropriate architecture. The development of use-cases helps to foster the communication of true requirements, but always be sure to limit the requirements to "what," not "how." This minor point can become a major issue. If you allow yourself to fall into the "how" trap, you may limit yourself later on the options for implementation. How is a design question that should not be asked until all requirements are identified and can be considered in relationship to each other.

What is your requirements management process? Remember that a repeatable process is a critical factor in achieving good quality.

  • Who will define the application requirements?
  • Who will capture the application requirements?
  • How will the requirements be documented?
  • Will everyone who needs access to the requirements be able to find them?
  • Will they be understood by a broad audience?
  • How will team members know if the requirements change?
  • How will you version requirements over time?

Capturing non-functional requirements is just as important as the identification of functionality. For a server-based product you need to ask the business what hours the server needs to be available. If you are working on a desktop application, consider the distribution channel. If you need to burn and mail CDs that dictates a packaging requirement. You also need to clearly define performance requirements by use-case and the volume of expected transactions for each use case. All of these requirements are inputs to the architecture and design processes. Failure to consider all aspects of requirements may lead to an inappropriate architecture and other deep-rooted quality issues.

Finally, don't miss this opportunity to discuss quality with the customer. Does the customer really understand the cost of a quality application? A business customer may not wish to pay for the level of architectural quality that you desire. As an architect you must be prepared to communicate the risks and rewards associated with such decisions. The customer may be able to save 10% of the project cost by deferring some of the architectural work to a later release. The customer may not realize that such a decision could cost the next release an extra 50% because the required architectural foundation was part of the cut from the first project. You must be prepared to articulate and quantify the risk in order to prevent such decisions.

Communication and Community

Some comments from my first article noted the impact of culture and community. I consider these important aspects of teamwork and add general communication to the mix. I heard a Kent Beck speech where he presented developer testing with an analogy to an AA meeting which I paraphrase: "Hi, I'm Allen. I'm a code-first programmer. It's been four days since I wrote code without a test." As silly as that may sound, there is tremendous power in community with your peers and the pressure it can produce to do the right thing.

The expectation of the entire team should be to produce a reliable quality product. Each team member has a responsibility to the entire team to do their part. You can be up front and ask that this individual accountability be understood and agreed to by each team member, but you may encounter resistance. You could also choose the approach of leading by example, but don't expect to infect the organization overnight.

A clash of personalities can destroy a team, but if everyone has a cooperative spirit, most issues can be used as a learning experience. As the team works together over time, individuals will typically find themselves assuming roles of mentor, leader or maybe student. I have seen teams bond through the adversity of a troubled project, but I believe that a more productive relationship is reached when team members find things outside the team that they have in common. Forming personal relationships is not going to solve a critical problem on your project, but it may create the communication channels between team members allowing them to work closer and create solutions as a team.

Communication of direction and strategy is also important. If the architect keeps the vision in their head, team members will create their own vision and may even start working towards their own vision. As noted earlier, quality requires consistency. An architect must communicate the vision on a regular basis to ensure that all team members understand the long term vision of the architecture. As team members become more familiar with the future state vision, they gain confidence in the knowledge that they are helping the team achieve that vision.


Quality efforts require the engagement of resources. Since resources translate to costs in real dollars, it is imperative that these costs be thoroughly evaluated against predetermined goals. Simply producing a product with minimal defects on time and within the agreed budget is a fundamental level of quality that customers should be able to expect. Even that may be seemingly unachievable without the proper processes.

Be sure that your projects start with a clear understanding of the goals, goals for quality, and other aspects as well. Be sure that you understand the requirements, foster a healthy team, and follow your defined processes. Testing and other quality-focused activities are often the first efforts to be abandoned when thing start to go wrong, but that is the time that it is most important to stick to your process. Functionality can be added later, but once the development cycle has run its course, you may never have another chance to fix quality-related issues.

Note that I've skipped over one type of programmer - the hero, the programmer who manages to save the entire project by coding something unexpected. This person is an asset for any team he's on, but he's often difficult to predict from a quality standpoint. To maximize a hero's effect on quality, his role should be to help define processes and mentor the team where possible, while recognizing his ability to short-circuit formal development processes at times. After all, what makes this person a hero in the first place is his ability to occasionally leap over tall buildings in a single bound, so to speak, but you should still expect him to follow the sidewalks along with the other mortals as often as possible.

About the Authors

Allen Stoker is currently a Technologist with Liberty Mutual Insurance in Indianapolis and oversees the architecture of several applications in both the J2EE and Mainframe environments.

Joseph Ottinger is the current editor of and has extensive experience developing and deploying enterprise applications in various languages.

*The views and opinions expressed are the authors' and do not necessarily represent Liberty Mutual, its management, or the formal views of TechTarget or