Architecture Design

Starting on a new project is very exciting. You start with a brand new problem and have to define the complete hardware and software architecture for the product. This stage presents its own challenges too. It is a big challenge to convert the system requirements into an architecture that will handle the requirements. In this article we will divide the process of architecture design into simple steps.

Architecture design can be de divided into the steps given below:

1. Analyze the requirements
2. Define use cases for the system
3. Identify processors/modules to implement the use cases
4. Select operating system and hardware platform
5. Assign requirements to individual processors/modules 
6. Define sequence diagrams at processor level

Note that architecture design is an iterative process. When you design your architecture you would move through the steps iteratively. For example, after analyzing the requirements and defining the use cases you might find that there are some aspects of the requirements you did not understand. So you would go back to analyzing the requirements.

Analyze the requirements

Entry Criterion	Customer requirements are available
Exit Criterion	System specifications are reviewed

The first step is to understand the requirements. This appears to be a simple step, you just read the requirements and understand it. But the truth is this could be the most difficult step of the whole process. The reason is that customer requirements may be written in a terse language that may need clarifications from the customer. It is a good idea to document the outcome of this analysis as a specification for the project. Essentially specifications are the customer requirements written in a language your team understands. Often the specifications would have more detail that the original customer requirements. At this stage, getting the system specifications reviewed by the customer will make sure that the customer and you are at the same plane.

Define use cases for the system

Entry Criterion	Reviewed system specifications are available
Exit Criterion	System level use cases are available

Once the system specification is available, develop system level use cases. The use cases at this level, consider the system to be a monolithic block. All interactions between the users of the system and the system itself are clearly documented. This process can itself be divided to into the following steps:

1. Identify the entities that will be interacting with the system
2. Define the interfaces between these entities and the system
3. Identify the most important scenarios for interactions between the users and the system
4. Define the use case interactions between the users and system

An Example

Lets consider the example of a digital switching system (telephone exchange) to better understand the steps involved.

1. Subscribers and other switches are the two entities that will be interacting with a switch.
2. Subscribers will use the system to setup and receive calls using a standard phone line. Other switches will originate and terminate calls on the switch.
3. Important scenarios for the system are:
   • Subscriber originates a call (successful, unsuccessful)
   • Subscriber receives a call (successful, unsuccessful)
   • Other switch originates a call (successful, unsuccessful)
   • Other switch terminates a call (successful, unsuccessful)
4. Define each of the scenarios that was identified in step 3. An example is given below. 

Subscriber originates a call (use case)

1. Subscriber lifts the handset
2. System gets an origination request
3. System feeds dial tone
4. Subscriber hears dial tone
5. Subscriber dials the digits
6. Switch removes dial tone
7. Switch routes the call to another switch by sending origination
8. etc. etc.

Identify processor/modules to implement the use cases

Entry Criterion	Reviewed system use cases are available
Exit Criterion	Hardware processor/modules have been identified and basic functionality has been assigned to the processors.

Once you have use cases for major scenarios, you are ready to move to the next step of identifying modules and processors that would be required to handle the system's functionality. Your selection of the hardware components should depend on the level of experience you have in executing similar projects. Here are a few guidelines:

• If you have an existing system which implements similar functionality, it might be a good idea to reuse the architecture from that project.
• If this is a brand new project, consider if the functionality can be implemented by a single processor. A single processor system would be the easiest to implement and debug. (even if you have to provide a 1-for-1 redundant machine).
• If the nature of the application or the performance requirements necessitate a multiple processor design, select the minimum number of processors that would be required to implement it. (Keep in mind that adding more processors to your system will complicate both hardware and software development).
• In a multiple processor design, separate out the processors that will control and manage the system from the processors that will perform the main operations. It is preferable to have just one processor control and manage the system, thus localizing the complexity of managing the system to a single processor. All other processors in the system handle the real work load of the system.
• Design a multiple processor system in such a way that it can scale from a small system to a large one by adding processors. Thus the customer can start with a small number of processors when the system is initially introduced. The system can then grow as the traffic on the system increases.

Select operating system and hardware platform

Entry Criterion	Processor and modules implementing the system have been decided.
Exit Criterion	Hardware and software platforms have been selected.

Selection of the operating system and hardware platform is based on the following factors:

• Technical merits (performance, stability) of the hardware/software platform
• Special requirements from the platform (e.g. does the application require a platform that supports a real-time operating system)
• In-house experience with the hardware/software platform
• Financial health of the companies backing the hardware/software platform (you don't want to be stuck with a platform from a company that may not be around to support the product)
• Company's roadmap for the product (you don't want to select a platform which does not have a clearly defined upgrade path)
• Quality of developer tools available for the platform
• Cost of training/availability of developers for the platform
• Head room in the software/hardware platform to grow with your needs (for example, don't pick a hardware platform when you know that the CPU utilization of the processor will be close to 80%, leaving no room for future growth)
• Does the platform require additional in-house development? A completely off-the-shelf platform is going to be a lot cheaper to work with than a in-house designed custom platform.
• Availability of device drivers for the platform (Can you afford to develop customer device drivers for every device that will interface with your platform?)
• Protocol support in the platform (e.g. does the platform support TCP/IP, HTTP, UDP etc.?)

Operating system and hardware platform selections can be very difficult to make. You will find members of your team deeply divided on the selection of the operating system. The best way to introduce some objectivity into decision making might be to consider the factors listed above and assign them weights. Then rate the proposed platform on all these factors.

Assign requirements to individual processors/modules

Entry Criterion	Processor and modules implementing the system have been decided and operating system and hardware platform have been selected.
Exit Criterion	Complete functionality of the system has been partitioned into different processors. All system specifications have been assigned to processors that constitute the system.

We have identified the modules/processors previously. Once the final hardware and software platform selections have been made, go through the system specifications and assign them to individual modules/processors in the system. A new revision of the system specifications should be produced with these inputs.

Define sequence diagrams at processor level

Entry Criterion	System specifications have been partitioned to different processors.
Exit Criterion	Processor level sequence diagrams have been produced for all the system use cases.

We consider this to be the final step in architecture design. Here the architects see if the architecture handles all the system level use cases. During this step, system level use cases will give way to processor level sequence diagrams. An example of such a conversion is given below. "Subscriber originates a call" use case is developed into a sequence diagram.

Subscriber originates a call (sequence diagram)

1. Subscriber lifts the handset
2. Originating call processor gets an origination request
3. Originating call processor allocates and assigns a digit collector module.
4. Originating call processor requests dial tone generator to feed dial tone.
5. Dial tone generator feeds dial tone
6. Subscriber hears dial tone
7. Subscriber dials the digits
8. Digit collector collects the first digit
9. Digit collector forwards the first digit to the originating call processor
10. Originating call processor requests the dial tone generator to disconnect the dial tone.
11. All other digits are collected in a similar fashion.
12. Originating call processor obtains routing information from the call routing processor.
13. Originating call processor communicates with the terminating call processor to further route the call.
14. etc. etc.

You can see here that the level of detail has increased considerably over the corresponding system level use case.