Home > Our Services > Software Architecture

What Is Software Architecture And Why Is It Crucial?

Architecture of any system boils down to formulating a breakdown of the system's concept into its comprising components.
Many software systems lack architecture design altogether, but even when software architecture is performed, it, more often than not, delivers only the static design of the software. Proper software architecture should also define how the different components should interact at run-time.
Identification of the composing components of a software system is called system decomposition.

Desingning the software architecture is quick and inexpensive compared to developing and testing the system. Getting the architecture right is critical because once the system is built it is extremely expensive to maintain or extend it.
However, although it sounds logical many systems turn out to have defective architecture or architecture which does not cater for the end user's needs and that is detected only after most of their code is fully or almost fully developped and tested. Correcting it is unthinkable because of the investment already made and in view of the high cost in time and money, but maintaining and extending the faultly architected software system shall prove to be even way more expenssive over time.

That is why it is crucial to get the architecture right before coding stats.

The Main Problems of the Software Industry

Rate of success to deliver on time and on budgest

Various reports indicate the following success/failure distribution for software development projects:

  • Less than one third of them do succeed to be delivered on time and on budget to the cliet.
  • 44% of them exceeded by far the budget and time initially allocated for them. It is very probable that many projects categorized in this category did actually fail but were still categorized as delivered to the customers for organization internal politics reasons. Therefore although delivered to the customer, these products are failures thereby they are either not used at all, or do not meet most of the customer’s requirements.
  • The last 24% failed and were not delivered to the end users.

Projects that do get to be used by the customer for whom they were developed very often suffer from one or more of following problems:

  • Exceeding by far the time and budget frames that were initially estimated and allocated for development.
  • Maintenance cost of these projects increases dramatically over time.
  • Most delivered projects require vast cross-project modifications immediately following their initial deployments.

The extent of the problems is well documented on the web.
For more information ---

Low to non existent fast response to market ever changing requirements and uncontrollable rise in maintenance costs

Changes in software tend to become slower and slower as the software ages. The reason for that is that each modification in the software erodes its resilience and its robustness, thereby increasing the time required for modification with similar complexity in the future.

The increase in cost and the decay of customer responsiveness usually follow an exponential pattern as illustrated by the attached graph.

Implemeting our designs yields dramatic cost savings because it shortens the time required for changes from weeks and months to days and because it substantially prolongs the life cycle of the software.

Low Quality Software

The word "software" is almost a synonym of the word "bugs".
Vast majority of developers in the software industry have never had produced a defect-free product, regardless of their experience.
It is a common practice in the industry that an attempt to fix a defect increases the number of defects rather than decreasing it.

These and many more yeild low quality products which are QAed by the customer. No other industry would have tolerated this. On very extreme and rare cases the customers act on it, after having spent a fortune, as in the case of Hertz-Accenture Lawsuit .

What Causes It

In most cases the reason for these problems is either flawed architecture design for the project or lack of it all together. Flawed project conduct design or the lack of it extends these problems, because well designed architecture may be derailed and butchered by sloppy implementation.

Even when design had been meticulously performed in the traditional way it is almost certainly guaranteed to run into the same problems because the architecture structure is determined by functional decomposition of the system.
Functional decomposition seems to be logical but it yeilds incorrect and rigid architecture. In fact functional decomposition is the core reason for many well known problems.

Avoiding the Problem by Acting Differently

The proper way to architect software is infact counter-intuitive. Therefore we conduct software project design in three sequential steps. Each step lays the next layer of the full design, based on what had been designed in the previous steps as follows:

  • Structural design of the software should reflect decomposition by the allocated volatility areas of the system, not by the required functionality. This structural design also reflects possible future modifications allocated by the architects using several unique crteria to determine them.
    The structural design formulates the software's core-use-cases, which are totaly different than the user-stories. Whereas user-stories are derived from the required functionality, core-use-cses should not.
  • Based solely on the assets created by the first step, a meticulous design of each user-story yeilds the required functionality of the system.
  • Detailed project conduct design seals the design process. It starts only after the two presious steps have ended, because that is the time we know, in detail, what software modules should be developed. At the end of this step we also know, in detail, how to perform the development, when to add developers to the team and when to dismiss them to receive maximum efficiency.
    This step can yeild more than one option of time/budget/risk combination. It is usually useful to present to our client's management more than one development option so they can select the combination that best fits the business needs of the organization. That also strengthens management commitment to the selected option.
coding starts only after full completion of the design as detailed hereafter. That assures that resources and money are not wasted in vain.

We have developed computerized tools that support these processes and make the information we supply in the design documents very coherent.

Software Project Architecture

We conduct project High Level and Architecture design to provide our clients with the following tangibles:

  • Preliminary analysis of the required design work. This short phase provides our customer with the full scope of the required design work and aligns the expectations.
  • We begin by cunducting detailed survey for understanding issues such as:
    • The business knowledge and logic required for performing this design.
    • Past experience of the client pertaining to software modification.
    • User operations required for carrying out the tasks of the software.
    This survey is the foundation for high-level static design and dynamic design of the software. We provide it in the format of power point presentation because design is better understood in graphical form rather than verbal form.
  • Architecture and High Level Design document that defines the exact structure of the software. This is the blue-print for the project. It defines each software module so that its developer gets a written description of what the module must do.
This phase ends up with the detailed design of what has to be developed and of how the different parts should be wired together.

Software Project Management

We conduct project management design, that implements the design captured in the High Level and Architecture design document, using a sound methodology that yields the development sequence for the project.
That well established methodology is Critical Path Method which was initially developed for the Manhatten project in the 1940s.
It was later used for the U.S. Navy in the 1950s with the Polaris submarine missile project.
Later in the 1960s, NASA used the critical path method as the principal planning tool for catching up and winning the race to the moon.
The critical path method literraly salvaged the much delayed Sydney Opera House project, which was completed in 1973.
It also ensured the rapid construction of the World Trade Center in New York City, also completed in 1973.

We conduct this design by the following steps:

  • We identify all the activities required for full completion of the software development in compliance with the High Level Design and Architecture document.
  • We select one combination of resources (such as programmers, testing professionals, development, testing facilities availability etc.) to be allocated for the development of that project.
  • We use old school engineering to determine the project's critical path. Based on that we design which development tasks should be conducted in parallel to the critical path's development, in what order, by what developer and what should the integration points between these tasks and the critical path. Then we optimize this initial design.
  • From the optimized design we then derive the exact cost, time and risk factor ivolved in the development of the the software under the selected combination of resources.
  • Actions described in the peceding three steps above may be re-itterated selecting different resources combination for each such itteration. That enables us to present to the decission makers of our client more than one alternative based on meticulous design.
  • After management makes its choice, selecting their favorite alternative, coding may start and we conclude and submit the Project Development Design document.

This methodology also makes it possible to monitor the project development in details to the extent that it makes it possible for us to detect any deviation from the plan almost immediately, thereby allowing minimum waste of time and means before getting back to track. We use for that special metric of the project's progress based on data collected constantly during the development phase.

The Bottom Line

We utilize modern and seldom-used methodology that transforms software development into a more controlled process similar to old-school engineering. That yields the following benefits:

  • Reception of very accurate estimations of the required time, budget and risks involved before coding starts. An estimation calculated that way is far more accurate than standard estimations received by methods used by most of the software industry today.
  • Dramatic reduction of the time required for introduction of changes into the software during its whole life-cycle (including during development) resulting in dramatic reductions of maintenance costs.
  • Further dramatic cost reduction is gained because we prolong the life-cycle of the software significantly. The effect of doubling or tripling software's life-cycle on the cost needs no explanation.