Pre-Sales Solution Architecture Workshop

Once you had your initial workshop and pinpointed the essential needs for the project, you were ready to create an awesome solution!

The aim of the Solution Workshop is to show off our wireframes and sitemap, get the client's opinion, answer any tech queries and move on with the architecture.

In order to better understand a customer's needs and build a connection with them, it is beneficial to set up a call with the client to clarify and present. Although this workshop can be omitted, it is an invaluable opportunity to gain insight into the customer's expectations.

Prepare for the Solution Workshop

Prepare a list of questions to clarify and identify the main points for customer feedback. Work in parallel with the pre-sales team to formulate technical questions to create a solution architecture.

Note: It is a nice idea to engage a customer with some design prototypes or visualisation of ideas on a board.

During the Workshop

1. Present wireframes, sitemap, and journey map

In order to ensure customer satisfaction, it is important to listen attentively to the customer to gain necessary feedback. Explain and demonstrate why the proposed solution will be of great value to the end users.

If the customer is satisfied with the solution and gives the approval to proceed, the next step is to create a solution architecture.

However, if the customer requests changes, it is important to understand why these changes are needed and if a better solution can be offered. It is essential to comprehend the true purpose of the requested changes and how to implement them.

2. Clarify technical questions for Solution Architecture

The goal is to define a list of ASR (Architecturally Significant Requirements) both functional and non-functional as detailed as required to design solution architecture.

• Check any existing architecture documentation

• Clarify:

How the client’s business work

Understand the client’s business goals

Understand project drivers

Greenfield project or it is in the development phase

Clarify the expected cost of infrastructure

How the solution should adhere to the regulatory requirements of the applicable country

• Requirements

Document high-level functional requirements

Collect main use cases (you can then draw a diagram to visualise main workflows)

Drive the discussion of stakeholders' visions

Be proactive in proposing missed use cases and ideas

• Non-functional requirements
• Clarify general technical questions

Software preferences, standards if any

Existing hardware, servers, and deployment approach

What database is used by the client

What licenses do they currently possess, and are they prepared to purchase additional licenses?

There can be some industry solutions that might be used. Are they ready to buy them?

What platforms are already bought? What strategy are they using for it: custom development, SaaS, PaaS, etc.

What do they consider: enterprise or open source?

Do they want to integrate with the existing/legacy/vendor systems?

• Stakeholders

identify stakeholders for technical questions

Identify stakeholders for requirements

• Constraints (something which we need to accept)

Verify that the constraints are reasonable and, if not, attempt to explain to the customer why they are inadequate

• Assumptions

Identify any potential gaps that are not explicitly stated by the customer or are not immediately visible

Double-check if there are no gaps left in functional and non-functional requirements

Assumptions will protect your solution in future

• Quality attributes - measurable or testable characteristics of a system that are used to evaluate how well the system meets the needs of its users.

Think and propose metrics to measure solutions. For example availability percentage, latency, throughput (number of events that take place within a given amount of time), and time to load a page.

• Some examples of quality attributes for a software solution include:

1. Performance
2. Scalability
3. Reliability
4. Usability
5. Security
6. Maintainability: The ease with which the software can be modified or updated to fix bugs or add new features.
7. Testability
8. Portability: The ability of the software to run on different platforms or devices without significant changes or rework.
9. Compatibility: The ability of the software to work seamlessly with other software or systems.
10. Customisability: The ability of the software to be tailored to the needs of specific users or organisations.

There is a big chance your customer will feel overwhelmed by the number of technical questions you need to discuss.

Don't worry! ???I have some tips to help make the process easier and more enjoyable.

First of all, don't let the conversation be buried by the questions. Instead, try to be polite and proactive. Show your enthusiasm for the project and make sure the customer knows you're a problem solver for the job.

Second, try to make the questions as concise as possible. Nobody wants to answer a long list of questions, so make sure you're only asking the most important ones.

Encourage participation: Encourage participation from the interviewee by asking them questions and giving them the opportunity to share their thoughts and opinions. This can help keep the interview engaging and interactive.

Use visual aids: Consider using visual aids, such as slides or videos, to make the interview more engaging and interactive. You can find hints on what to visualise in this article:

Finally, take breaks: Don't be afraid to take breaks during the interview to give everyone a chance to rest and recharge. This can help keep things fresh and energized.

It is important to ensure that customers are satisfied with the service they receive, so it is important to agree on a time for a follow-up call. Once that is established, the next step is to present a final architecture and make an offer.

After the Workshop

Say thanks to your colleagues for conducting this workshop. It is the most complex and technology-heavy part of the pre-sales process.

As you have shown the site map and wireframes, you can proceed with the visual design.

Make sure there is a dedicated person from the customer's side to answer your questions.

After you clarify technical questions proceed with building architecture.

Think about possible accelerators to speed up your project development.

I suggest preparing System context diagram and Container diagram after the workshop with the client.

You can consider the C4 Model which includes 4 types of diagrams:

1. Context diagram
2. Container diagram
3. Component diagram
4. Class diagram (too low level and often skipped)

A good style is to start the preparation of a SAD (Solution Architecture Document).

These diagrams should be included in an offer for the client.

In conclusion, the solution architecture workshop is a critical step in the pre-sales process. It helps to ensure that the customer's needs are met and that the project is on track. With the right preparation and planning, the workshop can be a successful and rewarding experience for everyone involved. Good luck!