Techniques to KYC for Solution Design

Know Your Customer for Designing a Solution

To provide any solution to your customer, it is important to understand the customer very well. This article covers some of the best practices and techniques for understanding your customer better to come up with a solution for the pain points of your customer.

1. Understand Your Customer's Business

Try to understand the type of business, strategy, history of the customer, and company’s vision and, going one step ahead, understand their customers as well. It will help you to derive the solution that is better for their ecosystem.

Team Mentoring and Learning Path

Considering a lot of demand for the various skill sets of people for upgrading existing systems or for new projects, it is very challenging to prepare the best team for the project. 

A few successful processes could improve the situation; I have listed some of them below and hope they are helpful.

Top-Down Design — an Approach for Flawless Software Design and Implementation

Check out this "top-down" view.
You may also like: Software Design Principles

Top-Down Design

In software development, you would have read in many articles and books that the design should be a top priority. A good design would resolve many issues. The design will bring in more clarity to the developers. It will give granular details on the exact requirements. In this article, I am going to discuss the Top-Down Design approach. I will explain step by step by taking an example of eLearning.

A problem must be viewed at multiple levels. Each one of them has its benefits. The different levels in software design or development are as follows

Code Review for Software Quality

Software code review plays an important role in software quality. The code review can happen in multiple stages, by multiple people, on multiple deliverables. Each one of them focuses on specific areas of software.

Reviewing code for software quality can be stressful!
You may also like: Code Review

Peer Code Reviews

Peer review is mainly between two people. Developer and another teammate.

Research Spikes in Agile

In Agile, we have to think about both long-term and short-term goals. The long-term goal is to ensure the customers' needs are translated into release themes. Short-term goals are meant for execution and deliverables. Long-Term thinking translates into release themes, which are split into epics.

A spike in Agile denotes something is not clear to the team. It needs more research to proceed further. In such cases, the recommended approach is to have time-boxed research events called research spikes. Some of the benefits of such an event include:

Event-Driven Pub-Sub Design

Problem Statement

In a complex, enterprise-level application, fundamental entities can be updated in various integration points or endpoints. You will build many business rules based on these entities' data. As the system grows bigger and bigger, it will be very difficult to track all the integration points that will update the entities' data.

In such cases, there are chances that it would be very difficult to get things right. It will be very hard to identify all integration points that will update the entities' data to plug the new business rules.

Zero Downtime Deployment

Software availability is one of the important criteria considered for the success of any software. It is important to make sure your business is not impacted due to software deployment activity. Achieving the highest software availability is possible in many ways.

A new release of software should not bring down the system. To achieve a zero downtime deployment, the software should be built considering the factors that do not demand any downtime.

Preparation for the Failure

Predicting failures of software in a production environment is very critical, apart from ensuring the quality during the development stage. The failures can happen in many ways, predicting them upfront and ensuring there are solutions for all such failures is a smart way. It will position you ahead in the race.

The preparation for failure should start from the initial stage of software design and carry on to the development and testing cycles. We must keep questioning our decisions in all these stages about the probability of failures and associated solutions.