Containers

One of the hardest things about software development is being asked to come up with a design when all you're given is a set of requirements and a blank sheet of paper. Starting with the big picture means understanding the context and how what you're building fits in with the existing environment. Once you understand how your system fits in to the overall system landscape, a really useful starting point for your own architecture can be to draw a simple block diagram showing all of the containers that make up these systems. By containers, I mean the executables that make up the systems; such as web servers, application servers, Windows services, enterprise service buses, databases, standalone applications, web browser plugins, etc. If I'm dealing with multiple Java EE web applications or .NET websites, I treat these as separate containers because they are usually executed in independent classloaders or AppDomains.

For example, if you're building an Internet Banking system you might have one or more web servers along with the various databases and backend systems that act as data sources. Do this from a logical perspective only and don't worry about things like having multiple container instances to support scalability and/or availability just yet.

Using a sheet of flip chart paper and a set of index cards is an excellent way to get started. In the diagram above, each index card represents an executable container that has been annotated with the technology and a very high-level statement of its responsibilities. This is very similar to Class-Responsibility-Collaboration (CRC) cards although we're working at a higher level of abstraction and showing collaborations as explicit connections between the cards.

In addition to helping to organise the major building blocks of your own architecture, this technique explicitly shows the dependencies on containers that make up other systems and the connections between those containers. Typically, inter-container communication is inter-process communication and the diagram above highlights these interactions. Now you know about them, you need to choose or determine technologies (e.g. web services, REST, RMI, WCF, messaging, etc) and design how those interfaces will work.

A high-level diagram like this doesn't show much detail, but it only takes a few minutes to put together and provides a way to communicate the major building blocks of your architecture and how they communicate. It also provides the framework in which components will reside, so that every component has a home. It's a simple, yet very useful step between viewing the system at a high-level and viewing the system as a collection of components.