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.
Collaboration became vital as groups developed complex social orders where the individual and group interests sometimes clashed. The relative power distribution among the stakeholders became more subtle and intricate and influenced the organization’s evolution.
So what is solution design?
Solution (and software) design is a stage in the Software Development Lifecycle that usually sits between Analysis and Development.
This article will answer the following questions:
- What happens in the solution design stage of the SDLC?
- What differences exist between software and solution design?
- Is design necessary for all types of projects?
- Do Waterfall, Agile or DevOps have a different view on this topic?
2. Table of Contents
- 1. Overview
- 2. Table of Contents
- 3. What Is Solution Design
- 4. When Does Solution Design Take Place
- 5. Product vs Solution
- 6. Why Is Solution Design Important
- 7. Solution Design Considerations
- 8. Agile Solution Design
- 9. Conclusion
- 10. Further Reading
- 11. Featured Articles
3. What Is Solution Design
Everything more or less begins when the organization’s stakeholders acknowledge 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 Exploring Many Designs
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.3 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 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.
Naturally, if you want to increase performance and availability simultaneously, you probably must upgrade your hardware or buy additional licenses, thus impacting a third criterion, cost-efficiency.
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.4 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.
|Attribute||Online System||Batch System|
|Utility, functionality, value||Non-negotiable||Non-negotiable|
|Availability||Top-priority in mission-critical systems||Medium priority as batch systems is required to be online only when needed.|
|performance||High-priority for the best user experience||Medium priority as long as the work is done within a reasonable time frame|
|Technology||Best in breed — it is more important to get optimal performance even at the cost of increased time-to-market||Mature technology that is easy-to-learn is OK if it delivers the required functionality.|
Another equally influential factor in the decision criteria ranking is 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 coordination must occur to optimize a complex system jointly.
3.5 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.
- 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 to be 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.6 Solution vs Software Design
Architecture generally discusses structures of connected nodes in a cluster.
In a solution architecture, the nodes are software platforms, applications, or systems, typically connected by interfaces. In contrast, in software architecture, the nodes are classes or domains, and the connections are either structural or behavioural.
What about design?
Once the concept of operations has been defined, and the major players in the architectural structure have been described, the design selects appropriate values for key performance parameters. The result is an optimized model that satisfies the project’s constraints.
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 project’s High-Level Solution Design (HLD). 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:
- 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.
- 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:
- 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.
- 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 we highly recommend.
- 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 distinguish 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.
A 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.
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 called 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 encompassing various products from various disciplines 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.
Failure to Address a Business 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 that 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
rework is mainly due to a project property called cost of change which is governed by the following two factors:
- The nature of the project: In some cases, rework necessarily incurs a high cost of change, 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.
- The project delivery methodology: Agile projects are more suited for earlier error detection. 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:
- 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.
- 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.
- The project involves cross-functional teams from project management, development, testing and quality assurance, and DevOps. Challenges can be compounded when people are operating on misaligned schedules and priorities.
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 existing features or upstream services. Include the necessary tests and dry runs to ensure seamless promotion to production.
These potential issues must be considered in the design phase and documented accordingly.
6.4 Getting the Estimation Right
Here are a few examples of what is typically overlooked:
- Impact of the changes on other systems in the network
- Amount of code change required
- How much regression testing is adequate
- Non-functional testing includes 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 must be made. For example, a system that runs at peak performance 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.
Several design considerations exist, 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:
- What business features, services, or functionality will the system offer and what needs will it satisfy
- What will the user experience be like
- 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.
Most prominent industries today are regulated by public or private regulatory bodies.
The payment industry, particularly, 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 rules and regulations that apply to the industry, project, or software implemented.
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 occurred 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 must be observed in all designs involving sensitive information such as user and customer data.
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.
- A modular product or solution comprises smaller, independent, self-contained components that can work together. 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.
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 them.
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.
Every project requires budgeting, and once the budget is allocated, it will not be easy to modify. If your project runs out of money, you need to have a good excuse; otherwise, you would send the wrong message to senior management.
For this reason, it is vital to have a very succinct idea of:
- How much development, testing, and training effort is involved
- What type of skills and headcount is required
- If additional infrastructure or licenses are needed
- 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 cannot deliver 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.
Decent performance is a standard requirement for all IT projects, especially online transaction processing. performance is generally measured in Transactions per Second (or TPS), response time, or maximum concurrent user sessions.
When designing a solution, ensure 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 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 the 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; 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:
- Welcome changing requirements, even late in development.
- Responding to change over following a plan.
- Working software over comprehensive documentation.
- The best architectures 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
Some projects have an implicitly high cost of change, or the requirements are obvious enough, and no iterations are needed.
On the other hand, in projects where the cost of change is low or when the requirements are ambiguous, Agile is highly recommended and has its methods for dealing with documentation (epics, user stories, tasks), planning (sprints), and software design (self-organizing teams).
In Systems Engineering, you typically create an objective function representing the criteria 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. You have a set of requirements, some of which are mandatory while others are nice-to-have. This differentiation arises between the two disciplines and 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 ensure you have done the minimum designing for your next IT project.
10. Further Reading
- Great talk by Martin Fowler on Agile Architecture.
- Fantastic lecture by Robert Martin on Clean Architecture.
- Design Definition and Multidisciplinary Optimization — MIT OpenCourseWare