Software Architecture and Project Design

Our Services

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 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 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

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 .

Rate of success to deliver on time and on budgest

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

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 for development
• Most delivered projects require vast cross-project modifications immediately following their initial deployments
• 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 accurate
• 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 selected option
• 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:
  • 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
  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 design
• 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 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.

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