Reference UseCase

Let us say an Architect Kris, has been asked to engineer a solution for a customer facing application which accepts feedback for various products from the customer. While there will be other folks to capture the functional requirements (which, Kris will also be across), Kris will be mainly focusing on the Non functional requirements of the application.

Few of the key non functional requirements, which catches his eye are:

  1. Application availability - 99.99.
  2. Response time - 10 ms
  3. Peak Transactions per second (TPS) - 400

Apart from the functional and non functional requirements, Kris also gathers information about the business needs of the application and comes to know that the application has to evolve constantly to discover and implement newer ways of gathering feedback, to stay competitive. For example, the application might have to mine information from social media, or gather indirect feedback by using analytics which could interpret customer actions.

Methodology:

Kris realizes that the application would need frequent release cycles, as short as every week to introduce new features. So, he decides that following Agile practices and following Devops methodology could prove to be very effective.

Target Platform:

Kris, needs to choose a target platform which can provide the availability criteria specified in the non functional requirements and design a solution which will guarantee this availability. He choses the right cloud platform by examining the various factors which are involved in choosing a cloud platform. Kris analyzes the various Infrastructure As a Service offerings and Platform As a Service offerings to choose the right solution which fits the needs. Based on the application availability specified, Kris calculates RTO and RPO and comes up with a disaster recovery plan to ensure that the availability requirement is met.

Application Architecture:

Kris also realizes the need for adopting a modern architecture (like a Microservices Architecture), in order to build loosely coupled services quickly which can evolve over time. In order to meet the response time, he finds that building a loosely coupled scalable architecture is necessary by using asynchronous communication channels wherever applicable. He analyzes the system components to look for potential Single point of failure and take appropriate steps to mitigate them. Kris gives special attention to fault handling mechansims to ensure that the system is robust and can withstand failures at all levels.

Data Architecture:

Due to the diverse nature of data sources involved and the need for scalability, Kris might have to use NoSql databases for certain services. Kris analyzes the read and write patterns, the nature of data operations and the nature of the data to recommend and choose the right NoSql database for the solution. Kris also estimates the sizing of the data storage required and whether the solution will cater to the specified number of Transactions per second.

Security:

Kris evaluates the security requirements of the application and also the organizational compliance laws required to protect customer data privacy. He ensures that application is secured against various attacks like XSRF, XSS attacks for example. Kris also makes sure that communication channels are secured by using SSL or MASSL as required.

Kris generates multiple view points to discuss the architecture with various stakeholders.

Note that, all the steps mentioned here need not have been necessarily executed in the same order and some of the steps could be iterated several times, before arriving at the solution. For example, Security requirements would have to be considered in every other step. Similarly, choosing a target platform may not be possible at one step and may have to be revisited as it would be impacted and constrained by other steps like data architecture, application architecture etc.

results matching ""

    No results matching ""