email article printer friendly more resources

Best Practices for Design and Modeling
Look for warning signs that might indicate future problems with your app, and balance your design decisions accordingly.
by Jeff Levinson

June 1, 2006

An "application" can refer to a single system or a group of interconnected systems that provide a specific functionality. The thought process for designing and modeling an application is often complex. In this article, you'll learn how to look for warning signs that might indicate future problems, and how to balance your design decisions accordingly.

The first thing you should know: When architecting an application, you will not find right and wrong answers to your questions. You can perform any given task many different ways, but you must always consider tradeoffs. For example, if you make the system more flexible, then it will likely be harder to maintain. You have to balance the goals of the system, or your requirements, against future costs and needs, so it's a good idea to document the rationale behind your development approach.

Second, you need to understand the purpose of the model that describes your architecture. You've probably seen some fantastic UML models that were too complex for most of your colleagues to read. The key purpose of designing an architecture is not to build cool models; you want to communicate ideas and information clearly to all stakeholders. UML serves as a common language for documenting architectures, but it's useless if it becomes too complex. Use line and box drawings if they help you communicate your point more effectively.

Third, every choice you make when designing your architecture has advantages and disadvantages. For example, should you implement a Web service? What's helpful about a Web service? A Web service is language-agnostic and human-readable. What's not helpful about a Web service? It can be relatively slow compared to binary transfer mechanisms. And a Web service can break language neutrality if it's not written correctly. As demonstrated in this example, you'll encounter a downside and upside to all of your design decisions—it's important for you to anticipate both.

Finally, your architecture will suffer from the start if you don't understand the meaning of "architecture," both conceptually and in practice. Carnegie Mellon University's Software Engineering Institute has a section of its Web site devoted to architecture definitions; it's called the Community Software Architecture Definitions . These definitions, gathered from developers around the world, encompass both professional and private opinions. However, they share the same general theme, as you can see from this definition of "software architecture":

"The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them." (Excerpt was taken from Software Architecture in Practice (2nd edition).)

Different types of architects apply this definition in different ways. If you are a system architect, you're concerned with the interactions between systems. You don't care about how the data is gathered on one system and processed on another, but you do care about how the connections between systems are made and how the data is transferred.

If you are an application architect, you don't care about how a method performs a process, but you do care about how data is moved from one layer of the application to another. Both of these examples take into account externally visible properties and relationships, but from different perspectives. The example I used for the application architect would comprise an internal process—internal to the application—so the system architect wouldn't need to be concerned with it.

Note that architecture is not a technology. It has nothing to do with the language you are using. Decisions about technology should be made after the architecture is mostly complete. This way your technology choices support the architecture that you've designed.

Think Through Your Design Process
Before you can start designing an architecture, you need to understand the requirements—requirements that are communicated and requirements that are implied (also see, "Identify the System's Highest Priorities"). Not all requirements are well-defined, and a good architecture should take that into account. But, assuming the functional and nonfunctional requirements (such as security, performance, maintainability, and extensibility) are understood, you can start designing an architecture. Over the years, a lot of high-tech tools have been released to help you create architectures, but the most important are the low-tech whiteboard and eraser.