eCrane Blogging

In the last article, I wrote in some general ways about application design, about some misperceptions and some difficulties. I will now turn my focus to what goes into application design? And in this, I’ll be primarily describing my own experience as a software architect and designer. I’d love to hear back about what I missed or where you disagree with me.

Let me start by saying that the ideas of “architecture” and “design” are often used synonymously. They are often grouped together and used interchangeably. For most projects, there’s so much overlap between architecture and design that there might be no value in making a distinction. I’m not sure if my understanding is correct, but I do think of architecture and design as being discreet activities, as I’ll describe bellow.

Application Architecture
One of the first tasks that falls to the application architect is to make decisions about the overall structure of an application, how will it be built, what tools will be used, which components will be built in house? Which will be bought? Sometimes these decisions will be made from policy: “We’re a Microsoft shop,” or “We’re a Java-Linux shop.” But even in these cases, there are often further decisions to make about which version of tools will be used, which components, and so forth.

In addition to tools and third party components there are decisions to be made about how in-house components will be built? Will it be a web application or a rich client application? How will the application be structured? Will it be client-server, or n-tier? What will the tiers be? Within a tier, how will it be layered. For example, the standard three tier application might be Presentation-Business-Data Storage. But then within the Business tier, how should code be organized? Will each business object be responsible for its own data access, or will there be a data access layer?

Server Architecture
Another part of architecture is to determine how the application will be deployed. What servers are needed? Will the application run on the web server or on a separate application server? Will the database be clustered or will a single instance suffice? What are the plans for backups, server redundancy, for fail over and disaster recovery? Usually, these kinds of decisions should come after some amount of time is spent understanding things like number of users, peak usage times, up-time requirements, etc.

Security Architecture
Application security is moving from the realm of a buzz word to being a fundamental assumption for most applications. Security architecture among other things defines who has access to what and how they’ll get that access while at the same time preventing others from getting the things that need to be protected. Application security could easily be a full time job for many software projects. But it is my opinion that many companies are waiting until they have a serious breach of security to start taking decisive steps. But that’s another subject.

High Level Design
High level design starts looking at particular components and decomposing them into packages and maybe even classes. A significant part of the high level design will be defining interfaces between layers, packages and other application boundaries. How will components of the system interact? What is the contract between the different layers of the system? High level design tackles those kinds of questions.

Incidentally, it is during high level design that I find knowledge of design patterns the most useful. What patterns will the application use? Knowing and naming the patterns helps structure the application and it helps communicate ideas to other team members.

Detail Design
Detail design is often part of the construction process. Detail design gets into the nitty gritty of how each class will be built, it’s responsibilities and interactions with other classes. For projects with a high need for exactness, airplane cockpit control for example, a fair amount of detail design needs to be done up front. But in my experience, for most business software it is usual to do detail design as part of writing code.

User Interface Design
User interface design can actually be sub-divided even further. There’s an artistic side that should be done by graphic designers or graphic artists. This would involve things like choosing colors and fonts, drawing buttons or other art, laying out screens, making decisions about component placement.

The other work that usually is part of user interface design is the human-computer interaction design. How is the best way for the user to enter the information needed? For a particular purpose, should we use a selection list, a menu or a custom control? How will users move from one panel to the next? How will users navigate the system? What controls should always be available and which will only show up from time to time? A lot has been written about the subject and as a result we usually only scratch the surface of what we could do to make the user’s experience a good one.

Database Design
Database design involved the design of the database, table design and possibly specification for other database objects (stored procedures, etc.) as well. Sometimes the database work falls to a DBA. But nevertheless, there is a significant amount of design work involved in creating a data storage system that fits well into the overall purpose of the application.

Non-Conclusion
From the paragraphs above, you can see that I’ve only hinted at the work that goes into each of those categories. Entire books have been written about each of these topics. But this serves to illustrate that the architecture and design of a system is a very important part of application development. There’s a lot that goes into it. But as I described in my last article, I think it is the most misunderstood element of software development. But it is also fun and challenging because there are so many different types of work to do. I’ve made this stuff the focus of my career in the past decade and I feel that I’m only starting to understand a fraction of what I need to know. So I’d love to hear back from you. What am I missing?

Matt raised an interesting question in response to my last post.  How does using a more agile or iterative development process affect design?  First off, I’ll say that no matter what your development process looks like you still have to do design in the sense of making decisions about how the application will be built.  And whether you make all those decisions at one time as part of a formal phase of a defined process or whether you make the decisions as you do analysis and coding go to the question of your methodology.  But regardless of your process, is there an intentional design aspect in it?  I guess the keyword here is “intentional”.  Are you aware of the design decisions you are making?  Are you considering trade-offs?  Are you communicating the design to others involved in the project?

Back to Matt’s comment.  I agree with your idea of continuous design as something ongoing and in a feedback cycle.  But I think that even if we blur the lines between distinct phases of a process, we should be very wary of blurring our design activities.  We should be intentional and clear about design.

In the past couple years I’ve done a fair amount of interviewing where I’ve been evaluating candidates on their technical abilities. One of the questions that I routinely ask is what part of a project the candidate would most like working on and I provide the following list of options: Analysis, Design, Construction (Coding), Testing, or Maintenance. So far, no one has picked the “Maintenance” option, no surprise there. The real interesting thing is that most candidates pick “Design” as their favorite part. But when I ask, “What books have you read about Design?” they rarely have an answer. And when I ask further probing questions about how they would go about design, or what they like about it, I often get very nebulous answers at best. I wonder if some people like the IDEA of Design but have actually done very little of it. They think of being creative, brainstorming, white-boarding, or even just of the excitement that sometimes surrounds starting a new project. It might be true that on many projects that is the only kind of thing that is done as part of “design”.

When I think of design, a number of things come to mind. I’d be curious to hear back about how other people think of design. But before I get into what is actually involved in design, I want to address the issue of design being the preferred part of the project. Doing design can be fun, I’ll admit it. The other phases of software development can be fun too. But lets be clear about something: there is also a lot of work that goes into the design of an application. Or at least there should be!

The design phase of an application development project should address the fundamental question of HOW the application will be built. Hopefully, the analysis phase has already addressed the question of WHAT is to be built. The primary output of design should be documents, or UML diagrams or whatever will best communicate the overall structure of the application and interactions between layers and components of the application. So there are two things that make design difficult. The first is making good decisions about how to structure things. The second is clearly communicating those decisions to others on the team. And here’s the catch about design–there may be better decisions and worse decisions, but there are very rarely right and wrong decisions. Designing applications often comes down to trade-offs. Sometimes a design decision is made based on the best available information. And then as the project progresses, more information comes to light. Or maybe business realities change making past design decisions look like “wrong” decisions. The good thing about writing code is that either it compiles or it doesn’t. Either it works or it doesn’t. With design there’s a whole lot more grey area than that.

Here’s another thing that makes design difficult: everyone on the team has a BETTER idea of how things should be structured. Developers often think that their way of doing things is the only RIGHT WAY. One person thinks everything should be a web service and another thinks .NET Remoting is the answer. Someone is used to having UI components bind directly to the database and sees no reason to ever do otherwise. Someone else likes XML and wants everything to be represented as XML. The point is that it is rare to find a developer who is sympathetic to the fundamental difficulty of the trade-offs involved in many of the design decisions. When we become accustomed to doing things in particular ways, we tend to become myopic and see other ways of doing things as wrong. So it often falls to the application designer to work with other developers, to listen to their ideas, to evaluate them, to incorporate them as applicable, to communicate when the ideas are not taken, and at the same time to try to keep a cohesive design in place. This stuff is hard, particularly since much of it is sociological in nature and not in the natural sweet spot for technical folks. This difficulty often pushes designer to one extreme or the other. They tend to become either dictatorial and not really take input from the rest of the team. Or they go in the other direction where there take all input and there ends up being no cohesive design in the end. The application becomes an amorphous blog of code with no discernible design. I’ve worked for both types.

Don’t get me wrong: I really do like doing application design. But I think that doing good application design is actually the hardest parts of a project. Maybe one of the reasons I like it is that it is very challenging.

Part 2 of this article is going to be about what actually goes into application design.