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?