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.
Various reports indicate the following success/failure distribution for software development projects:
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:
The extent of the problems is well documented on the web.
For more information ---
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.
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 .
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.
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:
We have developed computerized tools that support these processes and make the information we supply in the design documents very coherent.
We conduct project High Level and Architecture design to provide our clients with the following tangibles:
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:
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.
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: