CSC407S/ECE450S/CSC2103S Assignment 3

Due Friday Aril 12 in tutorial

Pretending that the system does not already exist, write an architecture document describing an existing system of your choice.

You are to prepare an architecture document for the design and implementation of a website, application, business system or free software tool that you are familiar with or fascinated by. In the case of very large systems you should restrict yourself to an identifiable subsystem. Acceptable examples would be amazon.com, a retail banking site, a SAP application, gnome, emacs, msword, a compiler, your favorite Java Virtual Machine, napster, etc... If you are currently working on a real system that badly needs an architecture document (that does not exist yet!) you may ask our permission to create and submit one.

The premise is that your document precedes (and sets the stage for) a future detailed design effort on the system. Your document should not be longer than about 10 pages. There is no implied requirement to reproduce the actual architecture of the system you have chosen. For instance, whether you choose amazon.com, msword or SAP you can (and should) create your own concept of how it works.

Recall that a diverse audience reads architecture documents. Some typical example readers:

• The senior engineering members of the design team;
• Junior (or prospective) engineering recruits to your project;
• Engineering task force members assigned to help you out with strategic technical decisions;
• Executives interested on what possibly could cost so much money;
• Managers of projects competing for resources interested in what you are doing;
• Sales support engineers of potential vendors bidding their databases, ORBs, widgets;

A good architecture document must describe a system at a high level so that a reader (in this case a TA) can understand what the system is to do. At the same time, a good architecture document must describe a system at a low enough level that a reader can also understand how the system is going to function. Though it is acceptable to refer to some background material your document must stand alone. Many of the readers of architecture documents (Teaching Assistants included) do not have the time to read a lot of references. You have to synopsize the background material and/or pitch your piece at the right level of address that it stands on its own. This is often quite difficult.

Generality is important in that it is not desirable to unduly constrain the subsequent design effort. However, the most useless architecture documents are those that are so general that they describe any system at all. You have to pin some things down. Here are a few illustrations of what this means:

• You need to pin yourself down to something more than a "persistent store". Suggesting an RDBMS (Relational DB Manager) or OODB is about right.
• Saying that "an IPC mechanism" will be used to communicate between machines isn't specific enough. You should suggest DCOM, CORBA or raw sockets.