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 and their interaction with each other.
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
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 introduce into it modifications that the architecture was not designed to contain.
Incorrectly designed architecture is expenssive to maintain or to extend and this gets worse as
the system ages.
However, although designing properly sounds logical, many systems turn out to have defective
architecture, or architecture which does not cater for the end user's needs. In most cases
these faults are detected only after most of the code is fully or almost fully developped and tested.
Correcting it by redesign is unthinkable because of high cost in time and money investment already made
but maintaining and extending the faultly architected software system shall prove
to be even way more expenssive and painful over time.
That is why it is crucial to get the architecture right before coding stats.
The Main Problems of the Software Industry
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
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 at all
Many 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:
Time required to introduce modifications and new features to the software becomes longer and longer as
the system ages. At first these delays are measured by days, later by weeks then by months and even by
years in extreme cases.
This impairs more and more severely the marketing requirements to keep up with new demands arising
from the market and to be able to respond to them as soon as possible
Maintenance cost of these projects increases dramatically over time
Exceeding by far the time and budget frames that were initially estimated and allocated
Most delivered projects require vast cross-project modifications immediately following their
Reaching their end of life within a decade or two. They have to be re-written, thereby
writing-off the vast investment for developing and maintaining them, that had already been
invested in them. This becomes a necessity because the cost and time
required to introduce changes to that software have increased to unexeptable magnitudes.
Rewriting the software, also referred to as the clean slate syndrome, incures businesswize
extremely high expenses and very high risk.
In some cases such projects can be rescued but that also is a very expenssive venture
The extent of the problems is well documented on the web.
For more information ---
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.
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.
However, this is not enough. Flawed project conduct design or the lack of it extends these problems because poor project
conduct may derail the project in spite of a good architecture design.
And last, but definitely not least, flawed detaild design or the lack of it may destroy a well designed architecture
and well designed project because well designed architecture and project may be derailed and butchered by sloppy implementation.
Avoiding the Problem by Acting Differently
The proper way to architect software is infact counter-intuitive. We conduct software project design in three
sequential steps. Each step lays the foundations for the next layer of the full design, based on what had
been designed in the previous steps as follows:
High level Architecture design based is not based on the requirements list. We base it on the business
domain's analysis as this is a stable environment unlike the requirements list. We initially define the
system's Core Use Cases which are not the use cases defined in the requirements list. We also extract the
volatilities list. Each such volatility is a software area bound to be broken when modifications are
performed. The building blocks we design both encapsulate allocated volatilities and they also cover
all business domain's aspects.
We actually design a software framework that acts as "production line" for any feature the business domain
may require. We then validate the architecture design by proving that this framework's architecture can
satisfy 100% of the currently requested use cases.
However, introduction of any new use case (i.e., feature) in the future simply means adding
small functionality to existing software framework items in this "production line".
Therefore, introduction of new a feature to the software does not change its architecture as it
merely is an additional new integration of these building blocks
Based solely on the assets created by the first step, a meticulous project design base on Cricical Path
Analysis is performed yeilding one or more options for the project's stake holders. This is where we provide
Detailed project conduct design starts only after the high level architecture had been approved by the
customer. That is the time we know, in detail, what software modules should be developed and how
they should interact in order to provide the required software solution.
At the end of this step we also know, in detail, how to perform the development, when to add
team members 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 decide which combination
best fits the business needs of the organization. That also strengthens management commitment to the
Detailed design seals the design process. Detailed Design phase always exposes issues that were not
addressed during the high level architecture design. It runs hand in hand with code production.
The system architect first sketches into one vertical slice of the system all the implementation details
the developers must follow.
The architect then is constantly reviewing the development of each module. The reason for that is a twofold:
first to make sure that the implementation is conducted according to the design and the developers do not
ruin the design by fusing everything together under the hood, and second to collect all the questions and
dilemmas that arise during the actual implementation and bring them again to the relevant function in
the business environment to get them to solve the dilemma rather than let the developer decide
We have developed computerized tools, for internal use only, 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:
This survey is the foundation for high-level static design and dynamic design of the software.
We initially provide this high level design in the format of power point presentation because
design is better understood in graphical form rather than verbal form. This power point presentation
is then formally reviewed by the customer in a Design Review [DR] to recieve the customer's approval for
The business knowledge and logic required for performing this design
Past experience of the client pertaining to software modification
User operations the software must best serve
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 that was 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
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.
Software Detailed Design
This is also when actual development starts. The architect makes sure that the design is implemented as intended
and that it abides to development best practices.
The architect is responsible for:
Providing the full folder structure in the actual development environment that will accomodate the solution
Select one vertical slice and sketch in it the required elements in each item so that developers can have an
example to follow
Provide a weekly track of the project, with comparison to the designed plan, to the project's stake holders.
Early tracking of deviation from the plan require mild measures to get back on track, while late discovery of
such deviation require much harsher measures
Participation in set of design reviews conducted for every development work item of the plan, including
integration with other parts of the system until and including the system delivery
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:
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
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