Do We Really Need Software Architecture ?

Introduction

This article will focus on one aspect of the development process which is the used software architecture to build the design. The term software architecture is very similar to the architecture of a building, where we are going to define the basic components of the software, how they are organized and how these components interact. There are numerous known software architectures e.g. layered, pipe-and-filter, Model–view–controller,

When building software for a new project there are two mindsets, the first one is the “Code Monkey” simply this guy knows everything about the programming language he is using and he has a quick understanding of the project requirements. Our code monkey will rush to coding the first design that comes to his mind and will spend all the development time to debug, redesign his code till reaching the target behavior. The second mindset is the “Software Engineer” one; this guy will use a development process to build his design. A simple development process may just be:

  1. Define clear testable requirements
  2. Build a design to satisfy these requirements
  3. Start Implementation Phase
  4. Start Verification Phase
  5. Start Maintenance phase

The process steps may look lengthy and let you think that it will take more time than rushing to code but actually the process steps will save you a lot of time later. First of all, the process ensures that you will reach a solution every time you design specially when working on complex systems. Second, it will give you a chance to see the big picture at the design phase so that you can choose between your design choices easily and moreover you can do optimizations at this level. Also, it will give you the change to build a reusable design that you can use it in future projects.

What is a good architecture then?

Let us just start by blueprint for examples for architectures, the first one is the output of our  code monkey and the second one is the output of an engineering mindset.

main-qimg-30fddfc623620b01a3e5c791337caae8             IBM_Fig1

From my point of view a good architecture must respect the following:

  1. Architecture is based on identified & clear requirements
    The architect needs to review the input requirements before designing his software.
  2. Architecture is not detailed design
    The architecture shall describe the big picture, the main building blocks and how they interact. It must not go deeply in the details, for example it shall not show the detailed algorithms.
  3. Manage CPU Time
    The architecture must respect the hard time constrains from the very beginning and decide whether the software will be able to handle it or not.
  4. Architecture is designed for testability
    One of the known methods of measuring the quality of a requirement is to put yourself in the shoes of the one who will validate your system and see whether this requirement is testable or not. Design for testability will ensure a robust system and a good quality within the target cost. Currently about 80% of testers time is spent to build tests for non-testable requirements.
  5. Architecture is easily changed
    Building a standard reusable software is the responsibility of the architect from the beginning. A good company doesn’t write any piece of code and sell it once, it must be reused in different systems just with different configurations.

Summary

To sum up, a good architecture is the key to your software success. Never rush to implementations before building a proper design. And always remember that a good requirement must be clear enough to be fully testable.

Waiting for your comments, feedback and questions !     View Hisham El Meligi's LinkedIn profile View Hisham El Meligi's profile

Leave a comment