Given performance requirements, one needs to architect and design the IT system or application to meet the requirements. Without requirements, one may land up with a completely faulty architecture that will not stand the test of time. Before proceeding let us note that architecture means 'what' and design means 'how'. Also when we use the term architecture, we need to be more specific. We assume that requirements are stated at a business level and therefore the first level architecture means a business architecture. In other words what are all the business transactions, what are their workloads, what are their performance targets. (See section on performance requirements gathering and analysis in this site.)
Once the business architecture is known, which is done in conjuction with business analysts, the application architecture needs to be formed. That is, what are all the application components that will be required to meet the business service functionality. For example, a banking deposit transaction will need to pass through a communication component, a validation component, a deposit transaction component, and a view balance component. The performance requirements at the business architecture level need to be translated to performance requirements at the application architecture level.
The next step for an architect is to arrive at the technical architecture, which means the set of technology components that will be used to implement the application architecture. For example, web servers, application servers, LDAPs, and databases. Therefore, the performance requirements at the application architecture level need to be translated to those at the technical architecture level.
Finally, comes the deployment architecture, which is the physical set of hardware (servers, network, storage) that need to deployed to meet the technical architecture requirements. The transalation of technical architecture performance requirements needs to be done to the deployment architecture and this will manifest itself in the form of IOPS, Mbps, etc. Hardware sizing needs to be done for the deployment architecture. In the absence of measurements, one needs to know how to arrive at a suitable methodology that is vendor independent, otherwise it will lead to too many combinations of sizing based on hardware and operation system and platforms.
We could proceed to provide a number of checklists, design patterns, best practices for architecture and design engineering for performance. But at the end of it, you will realize that it is nothing but common sense. And when architecture is an art why try to degenerate it in to a set of practices to be followed and make it boring. Checklists are useful for a reviewer but for an architect it is best to approach each problem with a fresh look. The experience of the architect will automatically help him choose the right set of guidelines when dealing with any problem. So rather than go through a set of practices, it will be better to illustrate architecture and design engineering through a problem statement that will capture various challenges faced by the IT industry today.
Let us now get on to the problem statement. The vanilla version of this problem is that ABC Bank wishes to centralize its processing across all branches (called core banking). They float an RFP (request for proposal) inviting IT vendors to bid for the solution. The requirements are that by the end of the third year of centralization they will have 5000 branches, each with an average of 10000 customer accounts. They estimate 15 million banking transactions per day (predominantly withdrawals, deposits, inquiries, loans). The transactions will occur through teller terminals, internet, and ATMs. They would like the IT vendor to propose a solution that will not only meet the third year requirement but also scale to at least twice the needs for the future. The IT vendor needs to provide the hardware sizing (server, storage and network) required to meet the bank's workload such that end to end response times at teller terminals is less than 2 seconds for majority of the transactions.
The problem statement above can be solved with a classic IT architecture (web, app, DB server) and that is why core banking has become so commonplace today. More details of the solution are provided at <this link>. Now let us get on to the next level of the problem. The bank now wishes to expand in to brokerage operations. This will entail internet trading for end customers, as well
as placing its own orders in to the stock exchange(s). For this they expect at least 2500 orders/sec and 1000 trades/sec peak, by the third year and they would like the IT vendor's solution to be able to scale to meet double this target. A peak of about 15% is expected on a single hot stock on any given day. End to end response times remain at 2 seconds, but the bank is considering placing its hardware in the stock exchange to allow for algorithmic trading, where they would expect less than a millisecond response time in their servers.
The brokerage problem above is not a commonplace IT architecture requirement and some more considerations are required to meet it. More details are provided at <this link>. Now let us get in to the last variant. As more and more investors and traders, are signing up for the bank's brokerage and also linking it with their bank account, the brokerage now wants to do risk management per customer. That means they would not like to provide exposure beyond a specific limit, for any given customer. More specifically, the brokerage wants to ensure that the customer has sufficient funds before placing a buy order or has sufficient stocks before placing a sell order. In due fairness to the customer, the sufficient funds includes the bank balance, as well as total value of all the stocks that the customer holds at the brokerage. Herein lies the challenge. The stock price of any stock will fluctuate many times a second and the risk management computations need to be done that often. If you consider a hot stock that is held by more than 25 percent of customers and consider its price to fluctuate 100 times a second, you can imagine the amount of recomputations to be done.
This risk management architecture will be a complete failure if a traditional IT architecture (web, app, DB server) is to be used. So how do we deal with this problem? For details click <here>.