# Solution Design and Its Role in Successful Projects

#### Georges Lteif

Software Engineer

Last Updated on May 10, 2022.
Subscribe now to stay posted!

## 1. Overview

From the 1970s onward, IT software projects acquired a notorious amount of complexity due to the advancement of hardware (exponential rise in processing power of the personal computer) and software technologies (proliferation of programming languages and frameworks).

These advancements captured the user’s interest and radically changed their preferences toward more modernization and digitalization.

Project delivery methodologies such as Agile and Waterfall were introduced to manage this complexity.

Collaboration became vital as groups developed complex social orders where the individual and group interests sometimes clashed, and the relative power distribution among the stakeholders became more subtle and intricate and influenced the organization’s evolution.

On the technical side, something similar happened. As projects grew in size and complexity, much forethought had to be placed into solution architecture and design to avoid costly rework.

In effect, aside from the tiniest instances, delivering working software of any business value is fraught with tremendous risk without a proper design.

So what is solution design?

Solution (and software) design is a stage in the Software Development Lifecycle that usually sits between Analysis and Development.

1. What happens in the solution design stage of the SDLC?
2. What differences exist between software and solution design?
3. Is design necessary for all types of projects?
4. Do WaterfallAgile or DevOps have a different view on this topic?

## 3. What Is Solution Design

### 3.1 Definition

Everything more or less begins when the organization’s stakeholders acknowledge the existence of a business need and decide to do something about it.

These needs can be generic, such as predicting the demand for umbrellas in the next rainy season. How this need is to be satisfied and what standards it needs to follow come in the next stage, the requirement gathering and definition typically carried out by Business Analysts.

The requirement definition exercise results in a clear set of objectives, some of which are functional, others are constraints, while the rest can be performance or quality-related.

The business requirements and objectives are then fed into the high-level design (HLD) or solution architecture process. Potential solutions are explored at a conceptual level during this stage, and a solution candidate is selected.

Now the time has come to generate a low-level solution design, the topic of this article.

First, a logical or functional decomposition occurs on the principal elements and functions of the HLD and lower-level components are identified. In the umbrella demand forecast example, the forecast engine is divided into three subcomponents responsible for data sanitization, model creation, and model integration.

Also, low-level technical decisions must now be made. In the same example above, these decisions can be whether to use neural networks or statistical models to generate the predictions and which frontend framework to use for the UI.

Next, additional requirements must be gathered to define the functionality of the subcomponents.

In the final stage, an optimization process will result in a low-level design, ready for implementation. That is the optimal solution given all the high and low-level requirements we have now gathered.

The low-level solution design is a blueprint ready to be discussed and signed off, in which case it will be implemented by the development team.

### 3.2 Architecture vs Design

We typically use the terms architecture and design interchangeably in most contexts. However, in our articles, we will distinguish between the two.

The term architecture will refer to solution architecture. The concepts of solution architecture are subtle and require some unpacking. If you are interested in a thorough discussion, you can find it here. In that article, you will also find information on the overlapping but distinct architecture and design concepts.

In a summary, architecture generates concepts and selects the fittest. It also establishes a vector of key design variables that are then used in the optimization process which we call solution design.

### 3.3 Exploring Many Designs

In the Toyota Way, considering many alternatives is a critical requirement in the decision-making process achieved by requiring feedback from people who may not have any stakes in the project.

A full exploration of the design space can be costly as it delays the time-to-market but is also critical when the stakes are as high as they are in the automotive business.

To compensate for the time spent deliberating on design decisions, an implementation should be swift, and that’s the adopted motto of the people at Toyota.

It is safe to assume that running through several candidates during software design also has merits, especially when the number of feasible options is not very limited. Equally important is to document why a specific design has been adopted.

### 3.4 Solution Design Optimization

One of the outcomes of a solution architecture is a vector of key design and operation parameters.

An example of a design parameter is the number of connections between two components. An example of an operating parameter would be the information displayed on a dashboard monitoring the infrastructure.

These parameters can be tuned to adjust the system’s overall performance and operational attributes. This tuning process is typically referred to as the optimization of an objective function.

The most generic and intuitive objective function is the utility to cost ratio, where we seek to maximize utility (business value) and minimize cost:

$J(params) = \dfrac{Utility}{Cost}$

The central idea is that not all the system parameters can be dialled up for maximum performance or operational ease. Tuning up one parameter can harm another as well as the overall system performance.

A sweet spot (or Pareto optimum) must be located. The combination of parameter values is optimal when no change in any parameter can be made without negatively impacting another. In effect, there could be a set of Pareto optimums.

Consider the above graph where system availability and performance are plotted. The idea is as follows: increasing the throughput of a system also increases the risk of damaging it and putting it out of service. The curve in the graph represents the set of Pareto optimums available.

You can decide which criterion is more important, performance or availability—an SLA placing system availability at 99.9%, for example, will determine the peak performance achievable.

These are the rules, and careful consideration must be placed into ranking the design criteria by priority and importance to help choose an alternative.

The optimization process should attempt to produce a robust design vis-a-vis the criteria ranking. This robustness is vital as stakeholder influence and preferences change; you don’t want to redesign the whole system if you have a new project sponsor or manager.

### 3.5 Ranking Decision Criteria

In profit-seeking organizations, the top-priority criterion is probably long-term profit, and technical superiority is only desirable if it provides a slight edge over the competition. Beyond that point, it is typically frowned upon by whoever is in charge of financials.

These subtle and conflicting constraints make technical choices non-trivial and subject to intense negotiations between business, technology, and finance departments.

Profit and utility aside, and as long as the final product does the job, there is much room for maneuver when fine-tuning design parameters. Consider the following example of an online and batch system in an ideal scenario.

There is another equally influential factor in the decision criteria ranking: power distribution in the organization.

Key figures will impose their priorities and actively oppose any project that results in modifying the status quo.

A large part of a project’s success can be attributed to the appropriate analysis and management of relevant stakeholders. Securing leadership support, active involvement, and engagement can tip the balance, especially in game-changing, long-term, substantial projects resulting in major power redistribution.

Additionally, subject-matter experts tend to focus on their areas, and plenty of coordination must occur to optimize a complex system jointly.

### 3.6 How Much Design Is Enough

What is sufficient breadth and depth in design space exploration? How much simulation and proof of concepts are enough before kicking off implementation.

Ideally, you want to explore as many alternative designs as possible and perform as much decomposition and lower-level design as practicable.

The depth of the design effort should be sufficient to allow analytical verification of the design to the requirements. The design should be feasible and credible when judged by a knowledgeable independent review team and should have sufficient depth to support cost modelling and operational assessment.

You also want to ensure that the selected candidate is also technically feasible.

Recommendations:

• Breadth can be achieved by involving as many stakeholders as practicable in the design review exercise.
• Depth will depend on how much you trust your engineers and developers in being able to make very low-level technical decisions on their own.
• How much simulation or proofs of concept are enough depends on the maturity and technological readiness of the solution concept adopted.

### 3.7 Solution vs Software Design

There is some overlap in the main ideas between software architecture and design and solution architecture and design.

There is also some overlap between software architecture and design, but they are fundamentally distinct.

Here is a list that is specific to software architecture and design:

Great software architecture guarantees quality code, while great software design ensures performance and availability.

## 4. When Does Solution Design Take Place

We have previously mentioned that solution designs come in two forms: low-level design and high-level design, each serving a different role and being prepared in a different phase of the software development life cycle or SDLC.

During the Analysis stage, a solution architect creates the High-Level Solution Design (HLD) for the project. The HLD is an architectural plan for the IT system and is usually submitted alongside the Statement of Work (SOW).

The HLD is mainly for a slightly technical audience, and its purpose is:

1. To furnish the relevant stakeholders with a bird’s eye view of the system’s target state, once implementation and development are completed. The stakeholders can then provide any comments and feedback before signing off.
1. Creates conceptual solutions, and selects the fittest. It also determines the high-level components and functions of the system, as well as a mapping between them. Finally, it establishes a set of critical design and operational parameters.

Once the SOW and HLD are signed-off and before any development starts, the Design phase kicks off, during which software engineers prepare the Low-Level Solution Design or LLD.

The aim of the Low-Level Solution Design is as follows:

1. Performs a further logical or functional decomposition of the main components and functions of the solution and selects the subcomponents to be used. The design and specifications for these subcomponents are also determined at this stage.
1. Provide a reference for developers and facilitate user story creation and implementation and writing unit or integration test cases, thus boosting the application of Test-Driven Development, a practice that we highly recommend.
1. Provide a basis for stakeholder acceptance which can be completed through testing, requirement verification, and quality assurance

## 5. Product vs Solution

Let’s take a moment to make a noteworthy distinction between the two distinct terms: product and solution.

The term product carries the connotation of a consumer product, something you pick off a supermarket shelf. It typically comes with a user manual and can, perhaps, be configured in a few different modes depending on how you want to use it.

On the other hand, a solution can be understood as an offering that solves business requirements. A solution can involve several products or platforms, customizable according to specific user requirements.

In summary, a solution is designed to solve a specific customer’s business needs, whereas a product is designed to solve a specific problem in a particular way.

### Product

Software Product usually refers to an application(s) running on a computer system. It offers users one or more functionalities that satisfy a specific business need in a predetermined industry.

### Solution

An Enterprise Solution may consist of any number of integrated software products, hardware components, and enterprise data. A software solution typically runs in a data centre or on the cloud.

A software solution allows enterprises to offer digital services to their customers or address an internal business need.

Office 365 or a payment switch from FIS are both examples of software products.

The software, servers, licenses, and user configuration for Office 365 are collectively referred to as enterprise software solutions.

A Software Product can be viewed as a self-contained platform with interfaces to the outside world allowing the integration with other products.

An Enterprise Solution is an umbrella term that encompasses various products from varying disciplines integrated together to offer an end-to-end business solution.

## 6. Why Is Solution Design Important

Let’s start this discussion with a compelling anecdote that illustrates how a massive gap can arise between a product implemented at a considerable cost and what the customers need.

In February 2008, Qantas – Australia’s national airline – cancelled Jetsmart, a \$40 million parts management system implementation. The engineers simply refused to use it. The union’s Federal Secretary explained: the software was poorly designed and difficult to use, and that engineers didn’t receive sufficient training.

The three reasons given by the union’s Federal Secretary to explain the abandonment of the project will be, as well as others, the subject of this section’s discussion. We will argue that a proper design process should help eliminate such risks.

### 6.1 Avoiding Costly Rework

I believe most would agree that the sooner an error is detected, the less costly it is to redesign and rework it—this leads to the idea that more design at the early stages of the project is better.

Rework is mainly due to a project property called cost-of-change which is governed by the following two factors:

1. The nature of the project: In some cases, rework necessarily incurs a high cost and, aside from investing plenty of forethought in the design process, there isn’t a lot that could be done to avoid high expenditures when rework is required. An example of such a project is building a high-rise or an aeroplane; any serious issue detected in the foundations, for example, will be detrimental to the entire schedule and budget.
1. The project delivery methodology: Agile-run projects are more suited for earlier detection of errors. This is facilitated by smaller and more frequent releases and parallel testing activities. On the other hand, Agile is not always applicable although a hybrid model can be adopted with no risk.

There is a distinction to be made between corrective measures and experimentation. In the latter case, you typically carry more than one design and try these out (simulations, proof of concept) to test their feasibility and suitability.

On the other hand, rework is created when something goes wrong in the analysis or implementation stages, which could have been avoided with more diligence or clarity.

Diligence in designing solutions can reduce or even eliminate rework.

### 6.2 Design Exercises Enhance Collaboration

Today’s IT projects involve a broad gamut of expertise from cross-functional teams such as business, security, compliance, infrastructure, procurement and technology.

This complexity requires high levels of collaboration on, possibly, multiple projects running simultaneously.

Problems of efficient collaboration can threaten knowledge sharing, decision-making, planning and time-management tasks in a large and complex social group. They become more acute in the following situations:

1. The group is dynamic, with members popping in and out from different projects or outside the organization. Under such conditions, teams have little time to know each other and get familiar with each other’s modus operandi. Maintaining a coherent and functioning structure requires mature processes and a strong organizational culture. Information should be readily available and easily accessible by newcomers.
1. The project is sizeable, with many software and hardware products incorporated into the solution and where no single person is an expert in the whole stack. There is a need in this situation for people to be able to see the big picture without having to hunt around for information.
1. The project involves cross-functional teams from project management, development, testing and QA, and DevOps. Challenges can be compounded when people are operating on misaligned schedules and priorities.

Collaboration, in this case, can be enhanced by availing high-quality information (such as the solution design) for all stakeholders.

Knowledge management processes can be implemented using tools like JIRA, Confluence, and MS Sharepoint to facilitate access, navigation, search, sharing, and collaboration on business or technical knowledge.

To mitigate any risk from misaligned requirements, schedules, timeframes, and priorities, solution design exercises bring relevant (and competing) stakeholders together (business/technology, client/vendor).

Guaranteed success requires the involvement and commitment of all stakeholders.

### 6.3 Reduces Risks and Adverse Side-Effects

Deploying new features into production is always an event. When designing a solution, make sure you take every possible step to minimize the risk of any potential downtime or service interruption or deterioration.

Consider backward compatibility, go-live approaches (big-bang vs phased), pilot phases, and impact on exiting features or upstream services. Include the necessary tests and dry-runs to ensure seamless promotion to production.

These potential issues need to be considered in the design phase and documented accordingly.

### 6.4 Getting the Estimation Right

Estimating development and testing effort needs to be as accurate as possible for smooth project management and tracking, adequate resource allocation, and delivery of profitable projects.

However, proper effort estimation cannot happen if you don’t precisely know what work needs to be done. For such exercises, a detailed design can come in handy.

Without a detailed and thorough solution design, you are at serious risk of underestimating many tasks and overlooking a lot of the usual overhead, such as test environment setup.

Here are a few examples of what is typically overlooked:

1. Impact of the changes on other systems in the network
2. Amount of code change required
3. How much regression testing is adequate
4. Non-functional testing such as performance (stress and load tests) and high availability (failover, backups, disaster recovery).

An excellent solution design will provide enough details to allow for a proper estimation to be calculated.

## 7. Solution Design Considerations

When designing a system, we look for an effective solution (does the job) that is also efficient (does it well) and cost-effective.

A practical solution cannot achieve everything and compromises have to be made. For example, a system that runs at peak performance at all times risks going down, thus reducing availability.

The solution design process, therefore, is an optimization exercise that selects values for key design and operating system parameters in order to maximize an objective function such as profit or utility.

There can be a number of different design considerations to look at, and a dedicated standard called ISO 25010 covering software quality has been published. The following sections will go through some of the most important quality aspects of an IT project covered by the standard.

### 7.1 Functional Requirements

Functional business requirements dictate what functions the system will offer, and answer the following questions:

1. What business features, services, or functionality will the system offer and what needs it will satisfy
2. What will the user experience be like
3. How should the system behave in different scenarios (nominal and exceptional)

### 7.2 Non-Functional Requirements

Let’s look at a list of some of the most common non-functional design considerations.

#### 7.2.2 Compliance

Most of the prominent industries today are regulated by public or private regulatory bodies.

The payment industry, in particular, has a long list of regulations to follow. Most notable are EMV and PA:DSS set by global organizations such as Visa and Mastercard.

It is not uncommon that whole projects are sometimes implemented to comply with the latest set of compliance mandates.

Solution designs should observe any rules and regulations that apply to the industry, project, or software implemented.

#### 7.2.3 Security

Software and cyber security requirements are essential to any IT project. Security, however, is not limited to the safekeeping of passwords but covers a wide array of similar needs (see ISO 25010 standard on software quality for a complete list).

Security can be broken down into five major categories:

• Confidentiality: Security in the traditional sense, i.e., protecting private data from unauthorized access
• Integrity: or how easy it is to identify messages that have been exchanged between two parties and were either modified or tampered with along the way
• Non-repudiation: The degree to which actions or events can be proven to have taken place so that the events or activities cannot be repudiated later.
• Accountability: This aspect deals with the firm’s ability to firmly audit sensitive activities on the system.
• Authenticity: Degree to which internal or external entities accessing the system can be authenticated.

Security requirements need to be observed in all designs that involve sensitive information such as user and customer data.

#### 7.2.4 Scalability

A system is scalable if it can be easily expanded (either vertically by adding more resources or horizontally by adding more nodes) to accommodate additional data or load.

An example of a perfectly scalable system is a modern database engine like Oracle; it can be scaled horizontally (by adding more instances) and vertically (by adding more discs) without bringing down the service!

#### 7.2.5 Extensibility and Modularity

Extensibility and modularity are the hallmarks of great architecture

• A system is extensible if it can be easily extended with new functionality without touching its core components.
• modular product or solution comprises smaller, independent, self-contained components that can work together as a whole. Modular pieces can be added, removed, enabled, or disabled at the user’s discretion.

Solutions architects typically watch out for either inextensible or monolithic products as they severely reduce the system’s future ability to accommodate additional services.

#### 7.2.6 Fault Tolerance

Fault tolerance refers to the system’s ability to continue functioning even though one or more parts have failed.

Oracle database engines make a great example of fault-tolerant systems; you can swap faulty hard drives without ever having to stop the database.

#### 7.2.7 Compatibility

Software compatibility can refer to several categories.

For example, two systems are compatible if they can be appropriately integrated and successfully exchange information.

A different example of compatibility can be OS platforms. An application is compatible with certain Operating Systems or platforms if it can be successfully deployed on these systems.

A good solution design does not limit itself to working only with specific software, hardware, or message types. Use industry-standard messaging and data transmission protocols to integrate with similar third-party systems.

### 7.3 Constraints

#### 7.3.1 Cost-Efficiency

Every project requires budgeting, and once the budget is allocated, it would not be easy to modify. If your project runs out of money, you need to have a good excuse as otherwise, you would be sending the wrong message to senior management.

For this reason, it is vital to have a very succinct idea of:

1. How much development, testing, and training effort is involved
2. What type of skills and headcount are required
4. Any other project expenses

A solution design is a great place to tackle these questions. A cost-efficient design will also lower maintenance and operational costs.

#### 7.3.2 Schedule and Timeline

Missing deadlines can mean a lot for the business. They can lose to the competition, incur fines from regulatory agencies, or prove to senior management that they are incapable of delivering on their promises.

The effort estimations generated from the solution design and how many resources are available for this specific project are usually what you need to get the dates right.

### 7.4 Performance

Decent performance is a standard requirement for all IT projects, especially those involving online transaction processing. Performance is generally measured in Transactions per Second (or TPS), response time, or maximum concurrent user sessions.

When designing a solution, make sure the system can easily accommodate reasonable future growth. Include stress, load, and spike tests in your design to ensure that the right resources and infrastructure are available when you need them.

## 8. Agile Solution Design

### 8.1 Design, Agile, and Waterfall

Classic Waterfall-based project management approaches have placed significant emphasis on design efforts to eliminate the need for redesigning anything in the later stages of the assignment when the cost of change typically becomes higher.

The graph above shows a conceptual image of how cost-of-change radically increases as the project moves to later stages.

Agile, however, has a completely different stance on design and how much should be spent doing it.

To illustrate the difference, let’s look at how sprints are conducted. During a short (typically two-week) sprint, design, development, testing, and documentation must be made, and, therefore, there is not much time to think about everything, write it down, and get it signed off.

In the Agile manifesto, the principles touching on documentation, design, and planning are:

1. Welcome changing requirements, even late in development.
2. Responding to change over following a plan.
3. Working software over comprehensive documentation.
4. The best architectures, requirements, and designs emerge from self-organizing teams.

We seem to have an incongruity between Agile principles and what we have articulated thus far on solution design. Is there a fundamental disagreement or only a misunderstanding?

### 8.2 When to Design

Our views are as follows. Some projects have an implicitly high cost of change, and Agile in its pure form is not applicable in such implementations. Extensive design and planning activities are required to avoid exorbitant costs associated with rework.

On the other hand, in projects where the cost of change is low, Agile is highly recommended and has its methods for dealing with documentation (epics, user stories, tasks), planning (sprints), and design (self-organizing teams).

## 9. Conclusion

In Systems Engineering, you typically create an objective function that represents the criteria that your stakeholders care about.

The objective function is parameterized by the system design and operation parameters, and you would usually use Multi-Disciplinary Optimization (MDO) techniques to try and optimize that function.

On the other hand, software engineering does not have the equivalent of an objective function. What you do have is a set of requirements, some of which are mandatory while others are nice-to-have. This differentiation arises between the two disciplines gives rise to two phenomena.

• The first phenomenon is that software and solution design are more of an art than hard science, but like art, they are nevertheless governed by rules of aesthetics.
• The second phenomenon is that every new project that adds features to the solution will have to leverage the existing design; it would not be cost-efficient to redesign a solution from the ground up with every new addition. This approach to solution building produces multi-layered architectural hierarchies that are the hallmark of complexity, and the latter always comes at a cost.

For these two reasons, solution and software design offer additional challenges that architects and engineers must tackle, and it’s never a good idea to sacrifice design efforts in an unsustainable manner.

Always make sure you have done the minimum designing for your next IT project.