A Practical Approach to Computer Systems Design and Architecture

Table of Contents

•  
  • 2.1. What Solution Providers Do Today?
    2.2. Why We Should Design Systems Properly? Do I have to answer this?
  • 3.1. Breaking the System with Easy Concepts
  • 5.1. Object Oriented Programming (OOP) Concepts
    5.2. Design Patterns
    5.3. Modular Based Development and Reuse of Modules
    5.4. Quickly Develop the Data Access Layer (DAL)
    5.5. Group Operations into Classes
    5.6. Keep Front Layer Free
    5.7. Visualize the System
    5.8. Naming Convention
• 1. Introduction
  2. Overview 3. The Approach to Design a System 4. Start Designing our Document Management System
  5. General Advices
  6. Think Fresh and Approach like a Newcomer
  7. Additional Hints for System Designers
  8. Final Note
  9. Coincident
  10. Summary
  11. History
  12. References

1. Introduction

Our Business Analyst went abroad last week to meet a new customer who selected us to develop his Content Management System. The Analyst had met and extensively discussed details about the business needs with the customer. Our hard working Business Analyst returned after two weeks with a detailed Business Model document on hand, where he together with a coworker prepared the formal requirement specification in a hurry. During this process they conferred with the customer to clarify some requirements. The formal requirement document was sent to the customer for initial approval, where it was returned with minor adjustments. The requested minor adjustments were made by the business analyst himself to get the final approval from the customer's end. It was a good effort; we got the fixed set of requirements three weeks after we first met the customer. Business Analyst sent the business model to the system architect. Soon, the Non-Functional Requirement Document was finished and was approved by the customer with no changes. As the next immediate process, the user cases were defined. System Architect finalized the design of the system together with the System Analyst. The Database Admin was followed by identifying/ defining the entities and their relations together with DDL (Data Definition Language) of the system. The UI (User Interface) designer designed the system user interface to finalize the initial design effort. At last, the deployment model was defined and started implementing the system steadily, after getting all required approval from the customer end.

What I just mentioned, was an imaginary system development process, which has limited real world applicability. In real world practice, there are many variables that make one to feel that system design/ development methodologies need to be adjusted from customer to customer, as well as from project to project. This article is a challenging attempt to introduce a concept (model) that hold onto all extreme cases of modern day system designing requirements.

The first step in designing a system requires thorough study of the problem domain. This implicitly means time, followed by money, which threaten the customer, who doesn't have an adequate visibility over the advantages of a properly designed system. It just makes things worse, when the current day diversity of requirements argues the value of one's experience. The experience give you confident but if one soon says that "Oh, This is just the same solution we delivered last year" he'll soon be ended up loosing the customer by delivering the wrong product.

There are good design methodologies out there, but often due to time limitations (where client push for quick releases, while developer struggle with extremely tight deadlines) solution providers aren't confident to apply them. Today, Solution Providers tend to implement systems without designing them properly. More often, the development starts after loosely evaluating the depth of the project. The System Requirement Specification is often changed in the middle of the development. This is due to insufficient clarity of business requirements had at the start of the project, as well as to insufficient domain expertise. The customer often waits until the solution provider releases the system to understand it. The customer uses the first few releases of the system to understand the direction of the project and to apply corrections. Unfortunately, some of these changes shake the whole foundation of the system, forcing designers to rethink the initial design. But these impacts are hardly seen by the customer's non-technical eye. A fight ensues between customer's money versus developer's 24 hours a day.

The customer estimates the correct time to enter the market at the initial stage of the project. The massive competition at the software market place makes it important to take decisions to pin-point accuracy. The most important is to hit the market on time.

2. Overview

2.1 What Solution Providers Do Today?

You don't need civil engineering expertise to understand the instability of building a foundation without knowing the number of stories of the finished building. The same philosophy applies to software architecting as well. Expanding a system, which is developed for a limited set of features, is just adding more problems than features. A high percentage of solution providers push for add-hoc development approaches. They use extreme programming to achieve tight deadlines. The customers are also encouraging them, having a daydream of re-factoring the system, once it is running at a profit earning stage. Another reason for customers to treat System Design as a low priority is the time the designers/ analysts take to investigate/ design a system. The Customer, according to some terminology is GOD, regularly expecting tangible outputs from the solution provider. But a proper system design process may make him wait several months. In order to support this customer's need, solution providers often plan bi-weekly or monthly system releases from the starting day of the project. This extreme need burns out resources in the middle stage of development.

Developers are used to starting the system development process with a scaled down version of the system, and gradually patch the rest of the system around it. This results in an unstable product with lots of repetitive, badly grouped codes. Additionally, it creates programmer-dependant code modules, since each module is coded by individuals with different skill sets. The inconsistent code makes debugging the system a nightmare. This costs time as well as money in many direct/ indirect ways, while making it impossible to expand.

2.2. Why We Should Design Systems Properly? Do I have to answer this?

Properly architected systems always gain that strategic advantage over common issues of the software development life cycle. A well architected system is cheaper than a patched together system when it comes to dealing with changes and upgrades. The architectural discipline regularizes code, while supporting and managing the implementation with short predictable development times. The consistency of the design allows managers to pull/ push resources from/ to different sections of the project with minimal training. These are some of the few advantages you gain with a properly designed system.

In order to drive the system development effort smoothly, the designer should introduce a steady design/ coding pattern at the early stage of the process, allowing every developer to gain mastery over it. This also opens the opportunity to remove the dependency on the Architect at later stage of the project.

3. The Approach to Designing a System

Let me highlight first, that I do not draw the famous user case diagram and sequence diagram, when designing systems. In-fact I have another approach that lets you understand the system better and allows you to directly draw the class diagram. But before drawing the class diagram, I encourage you to draw an activity diagram and/ or a system overview diagram and/ or a module interaction diagram and/ or any other type of diagram, which helps you to fully understand (feel) the system.

As I reiterated many times, designing a system mainly depends on the designer's understanding of the problem domain. So the better you understand, the easier the system design will be. However in modern days, it is less probable to assume that designers get a sufficient time frame to fully investigate the system, before starting to design.

As the first step, the designer has to be a master of the problem domain. A well written System Requirement Specification (SRS) document can be used as the introduction to the system. The system designer should read it repeatedly and should carefully understand each and every important feature, hidden in odd corners of the document. But in most cases, the designer does not get a proper SRS prior to the system design. (At least, this is the case with service base companies).