Poorly designed architecture affects an application throughout its lifetime and can result in inestimable costs. Given this fact, it is surprising to see that the software architect's job is so often overlooked. Many businesses do not have software architects at all or they assign the role of software architect to someone in the shop; such as a software designer who might not have the experience to do the job correctly.
In the worst-case (but not at all uncommon) scenario, the so-called software architect is also working on other tasks integral to the project. In this case, the overburdened individual -- even if he or she is a trained software architect -- becomes little more than a figurehead. Design process and documentation are quickly abandoned, with predictably poor results.
To remedy this, I'll devote the next few columns to discussing the importance of the software architect in the application development process. I'll start this month with an overview of the architecture process in an example design project. Next month I'll go more in depth by looking at how the architect guides the process from start to finish.
The job of an architect entails more than offering up good ideas and advice at the beginning of the development cycle. Perhaps the most important aspect of good architectural design is adherence to an accepted documented process. In this column, I'll define the word process to mean a set of instructions or documents describing how the work is meant to be done.
The advantage of following a process is simple; it provides a framework to work from. If the process is functioning correctly, then it need not be altered; if it's not sufficient to the project, then you can always improve it. Regardless of which process you choose or create, the important thing is that a newcomer, or management, has some means of learning about it. If your process is one of the familiar ones (such as Rational Unified Process® or extreme programming), the source could be a book or a maybe even a Web site. In any other case the process should be adequately documented.
To best understand the importance of process, I'll use a working example -- an application to be built from the ground up, starting with the architecture. The first step in designing the application is to agree on the development process. Most of the accepted processes for designing software architectures focus on working with requirements and quality attributes. Rather than work with a single, generic methodology, I'll combine the features of some of them.
Figure 1 shows the example process. At the top of the figure are the stakeholders that define or collect the requirements for the application. The requirements are then processed into a requirement specification. The requirement specification can contain many requirements, not all of which are of equal importance. The most important requirements need to be selected so that they can be accounted for when the architecture is designed.
Figure 1. A design method for creating software architectures
This is a simplified process for designing a software architecture. First, the architects design the structure of the architecture with only the most important functional requirements. Next, the quality attributes are brought in. If the architecture passes through all the quality attributes, another iteration with a new set of requirements can be started.
After the architecture has been designed, the software developers create the detailed designs and implement and test the software. After the software is on the market, new requirements can be gathered from customer feedback and business intelligence. Appropriate solutions can be implemented in later versions.
Note that this design process borrows considerably from RUP® or extreme programming in the importance it grants to iteration. The architectural portion of the design process can be thought of as the first couple of iterations; or it can be understood as the inception phase in an RUP design process. In the following sections I'll go through each step of this process in more detail.
One of the architect's most important jobs is to dig out the application's functional requirements. This can be challenging because stakeholders tend to disagree. Marketing typically turns in a slew of requirements, whereas management's only requirement is that development costs stay low. It's usually the architect's job to negotiate these differences with the stakeholders and determine which requirements are essential to the application.
Let's take a simple example. The marketing department tells you that it has 48 crucial requirements for your software project on the same day that management gives you the projected budget, which you immediately know is too low to even cover ground-level costs. Management also stipulates that it wants to see the first version of the product enter the market within a year, in order to start bringing money in to the company. You need to categorize the requirements so that you can determine the ones the software must have when it goes to market. The remaining requirements will be left for future iterations.
After you have a good idea of the requirements you actually implement (hopefully defined in a requirements specification), the next step is to gather all the possible application constraints. A constraint can be anything from a company policy that states you must use a certain database system to a set of architectural guidelines for an existing product line. Like requirements, application constraints can be heavily contested territory, although in most cases constraints are less easily removed or set aside than requirements.
The next thing you'll need to determine is the architectural style of the software. You have many different architectural styles to choose from, including layered architecture (most common for enterprise applications), pipes and filters, various database-centered types of client-server architectures, virtual machines, and more. The architectural style you choose provides the conceptual framework around which you will build your application. For example, if you're implementing a layered architecture, you'll probably want to make specific layers for database classes, business classes, and maybe even for presentation-layer classes. Knowing this from the outset is helpful, even in the early stages of determining the classes and methods for the application.
With the functional requirements set, constraints accepted, and the architectural style chosen, your next step is to finally start designing the architecture! Assuming that your requirements specification includes use cases or user stories (which it should -- see Resources), a good first step is to go through the use cases one by one and write down all the entities in each case. Many of these entities will become important classes in the software.
A use case is much more than a diagram showing all the application functionality. A good use case contains a written story about what should happen in a particular instance of use. Listing 1 shows an example use case.
Listing 1. An example use case
Name: Login Description: User begins a session in the system. Details: 1. User goes to the login page. 2. User enters username and password and presses OK. 3. The system checks that the username and password are valid. 4. If the login is successful, the system loads user's personalized start page, otherwise an error page is shown. Precondition: 1. The user is not logged in to the system. 2. The user has access to the login page or an error page is shown. Postcondition: 1. The user has a valid session in the system. 2. The user's personalized start page is loaded. |
An architect reading the use case in Listing 1 would search for entities like login page, user, username, password, start page, and so on. Some of the entities will become classes in the system; others will be attributes in the classes. For example, User could be a class and username and password could be its attributes. Reading through the requirements and analyzing them helps you find the application's most important classes. After finding the classes, the next step is to go through the requirements once again, this time paying attention to functionality elements such as login and validation checks. Many of these elements become the application's methods and functions.
When you think you have found most of the application's classes and methods (defining its functionality), go through the requirements once more and make sure that they're satisfied by your proposed architecture. If the functional side of the application is working properly, it's time to move on to plotting its quality attributes.
The most common quality attributes are performance, reliability, security, usability, modifiability, portability, and interoperability. For best results, the entire development team (as well as the rest of the company) must understand and agree on the application's quality attributes. In order to get to this point, most development teams go through a process of writing down those attributes, determining what is required (or desired) from each one, and then using this document to measure how well the attributes are being met by the application in process.
Let me give you a small example to shed light on defining the attributes. Let's say you're defining the performance attribute. If you assume that the software is a Web site offering information for subscribed users, then you know that its performance requirements must be concrete and measurable. The two most important performance elements in this example are latency and throughput. Latency refers to the time that passed from the moment an event occurred to the time that the action was completed. Throughput is the number of events the application can respond to per unit of time. In this example, the latency requirement is that the system should respond to a client action within one second. To achieve this, actions must be optimized and the amount of data transferred over the Internet must be minimized. As for throughput, it could vary considerably. I'll say that the starting throughput requirement for this system is that it be able to handle 1000 users at once.
After you've defined a quality attribute, as I just did according to its most important elements and its impact on the application framework or functionality, the next step is to determine whether the application can meet it. In some cases, the answer is obvious. In others you might want to build a small proof-of-concept to see what happens. If the quality attributes are not met, you should change your architecture so that all of them are met. After that, you must go through the functional requirements to see if and how the changes have affected them, and then adjust the application accordingly.
Choosing the right architecture
After you've defined your application's functional requirements and quality attributes, you might find that you have several possible architectural candidates to choose from. Choosing the correct architecture for your application can be tricky. It is helpful, first, to consider the differences between the candidates, particularly by measuring or estimating the development times, costs, maintenance costs, and so on, for each one. Money is often the bottom line when it comes to choosing from a number of suitable architectural designs.
In this installment of Architectural manifesto, you've seen the role of a knowledgeable architect in designing software architecture. As discussed, the key to a successful project, from start to finish, is to employ a well-known and (preferably) documented process. Most design methods these days suggest that the architect should first design the architecture (or maybe two or three candidates) for the functional requirements, then bring on the quality attributes, and finally modify the overall design so that the quality attributes are met.
Whatever your process, it's important to note that application design can and should be iterative. With each iteration a collection of requirements can be produced, such that the application is continually improving. In the end, this process lets you move toward an architecture that satisfies both functional requirements and quality attributes.
Stay tuned for next month's column, when I'll delve more deeply into the role of the architect in the application design process.
- Reference Architecture: The Best of Best Practices (The Rational Edge, January 2004) is an excellent discussion of the benefits of RUP in software design and development.
- Risk reduction with the RUP phase plan (The Rational Edge, September 2003) is a more example-driven look at how RUP works in a real-world software development project.
- XP distilled (developerWorks, March 2001) is a hype-free overview of extreme programming.
- The article Best practices for software development projects
(developerWorks, June 2003) provides a checklist of time-tested project guidelines.
- In Designing MIDP applications (developerWorks, February 2004) Mikko walks you through a software development process using an example MIDP application.
- Quality Attribute Design Primitives (Software Engineering Institute) is a good article about how to handle quality attributes. Authors Len Bass, Mark Klein, and Felix Bachmann discuss attribute stories and provide examples of how applications can be built for easy modification and performance.
- Don't miss a single installment of Mikko's Architectural manifesto column! See the column series page for a complete listing of previous columns in this series.
- See the developerWorks Wireless technology zone for a continuously updated collection of articles and tutorials on mobile application design and development.
Mikko Kontio works as a Technology Manager for the leading-edge Finnish software company, Softera. He holds a Masters degree in Computer Science and is the author and co-author of several books, the latest being Professional Mobile Java with J2ME, published by IT Press. Mikko can be reached at mikko.kontio@softera.fi.
