Recommendations

Topics:
1. 2. 3. 4. 5. 6. 7. 8. 9. Project Overview Architecture Business Cycle Quality Attributes Quality Tactics Architecture Pattern Architecture Views Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Project Demo

Project Overview
Project Objective Recommendations (a.k.a. Reco) is a consumer recommendation platform - a reliable source for valuable consumer insight, unbiased advice and personalized recommendations. It is a platform for people to seek opinion or feedback on various products and services (e.g. cars, dentists and even birthday cakes) before spending their money and to share their experiences - both good and bad. Here people will not just tell you what to buy, they will also warn you what to avoid. Target Users This tool will be available only to employees. Reason behind this is that people trust the opinion if someone whom they know personally provides it. Current System Everyone try to be extra careful before spending money and employees are no different. Today, if a employee wants to get an opinion on something, he/she sends an email on an internal group of fellow employees asking for recommendation or feedback and fellow employees provide feedback by replying to his/her email.

Topics:
1. 2. 3. 4. 5. 6. 7. 8. 9. Project Overview Architecture Business Cycle Quality Attributes Quality Tactics Architecture Pattern Architecture Views Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Project Demo

Architecture Business Cycle

Definition: Software architecture is a result of technical, business, and social influences. Its existence, in turn, influences these technical, business, and social environments. This cycle of influences from the environment to the architecture and back to the environment is called the Architecture Business Cycle. Its a Dance between the architecture and the organization

Architecture business cycle: Organization goals to requirements Requirements to architecture Architecture to systems Systems to organization

Influence of ABC cycle on Reco: Technical influence: The architecture of Reco was influenced by technical skills of developers. For example, we decided to developed PHP, Flex and MySQL based technical skills of developers. Business influence: Due to financial constraints we removed mobile experience which was there in the original architecture. Social influence: People trust known people and hence send mail to local closed groups to get opinion on some product and service. This influenced our architecture to restrict to closed group (i.e. Employees only). Because of above reason we have also decided to use corporate authentication system. Requirement to reduce spam made us to restrict reply only to the person asking for opinion.

Topics:
1. 2. 3. 4. 5. 6. 7. 8. 9. Project Overview Architecture Business Cycle Quality Attributes Quality Tactics Architecture Pattern Architecture Views Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Project Demo

Quality Attributes
System quality attributes: Security Availability Performance Modifiability Business quality attributes: Targeted market Integration to legacy system (closed email group) Architecture quality attributes: Buildability

Topics:
1. 2. 3. 4. 5. 6. 7. 8. 9. Project Overview Architecture Business Cycle Quality Attributes Quality Tactics Architecture Pattern Architecture Views Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Project Demo

Quality Tactics
Security QA tactics: Requirement: Users from corp network only should have access to Reco system.

Tactics:

Corp Authentication Mechanism: Reco uses Backyard (Corp Authenticate Mechanism) to authenticate users. Since Backyard is accessible only from corp network, Reco can not be accessed from outside corp network.

Availability QA tactics Requirement: System should not be down if there is a hardware crash on one of the host and service should be provided with the help of remaining hosts.

Tactics: Redundancy of Hardware: Reco system has multiple servers providing services to users. System has VIP (Virtual IP) under which there are multiple hosts. VIP keeps polling each of the hosts periodically. In case if one of the hosts has a hardware crash, VIP takes that host out of rotation so that request will not go to the faulty host. At the same time other hosts will be taking user requests. Hence there is no system down time.

Performance QA tactics Requirement: Simultaneous requests (Up to 1000 in numbers) should be processed within 3 seconds of latency.

Tactics: Introduce Concurrency: Reco uses VIP mechanism (which is one CNAME, multiple hosts.) that has multiple servers providing services simultaneously. VIP takes care of load balancing to make sure that none of the hosts are overloaded. By means of multiple servers, Reco supports average latency of 3 seconds for simultaneous requests (Up to 1000 in numbers).

Modifiability QA tactics Requirement: Adding a new notification mechanism should not require changes in the existing classes.

Tactics: Localize modifications: Reco uses XML format for data to be sent to user. Now if the requirement is to send the data to user via SMS, then a new class is added which takes the same XML format input. Hence no need to change existing classes.

Topics:
1. 2. 3. 4. 5. 6. 7. 8. 9. Project Overview Architecture Business Cycle Quality Attributes Quality Tactics Architecture Pattern Architecture Views Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Project Demo

Architecture Pattern
Software pattern suitable for Reco: MVC Generic MVC structure:

MVC diagram ( Reco):

Topics:
1. 2. 3. 4. 5. 6. 7. 8. 9. Project Overview Architecture Business Cycle Quality Attributes Quality Tactics Architecture Pattern Architecture Views Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Project Demo

Architecture Views
Describing the architecture of software-intensive systems, based on the use of multiple, concurrent views

Logical View: Functionality provided by the system to end users. Class diagram:

Sequence Diagram: Scenario 1: User asking for an opinion

Sequence Diagram: Scenario 2: User responding to a question

Sequence Diagram: Scenario 3: User reading the responses posted on a question

Development View: Component Diagram:

Development View: Package Diagram:

Process View: Dynamic aspects how they communicate, and focuses on the runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability. Activity diagram: Scenario 1: User asking for an opinion

Activity diagram: Scenario 2: User responding to a question

Activity diagram: Scenario 3: User reading the responses posted on a question

Physical View: System Engineers Point of view Deployment diagram:

Scenarios: Scenario 1: User asking for an opinion Scenario 2: User responding to a question Scenario 3: User reading the responses posted on a question

Topics:
1. 2. 3. 4. 5. 6. 7. 8. 9. Project Overview Architecture Business Cycle Quality Attributes Quality Tactics Architecture Pattern Architecture Views Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Project Demo

Architecture Tradeoff Analysis Method (ATAM)

Scenario A01 Attribute Environment Stimulus Response Architecture decision Detection via status Failover Routing Reasoning

Scenario: If one of the box is down traffic should fail over to another box within 1 sec Availability Degraded operation Hardware Failure Failover within 1 sec Sensitivity S1 S2 Trade off Risk R1 R2 Nonrisk

Guaranteed to detect failure within a second Active redundancy ensures minimal down time Simple and common solution Shown in next slide

Architecture Diagram

Scenario A01 Attribute Environment Stimulus Response Architecture decision Replicated DS

Scenario: If datastore is down, interruption should server without interruption Availability Degraded operation Software Failure Failover within 1 sec Sensitivity S6 Trade off Risk R5 Nonrisk

NoSQL behind MQ
Reasoning Architecture Diagram

T4

R6

Replicated store can transparently handle node failures Shown in next slide

Scenario A01 Attribute Environment Stimulus Response Architecture decision Modularity Use polymorphism

Scenario: New feature should be added with less than 25 hours and minimal rewrite of components Modifiability Development time New product feature Featured delivered, first time right, within stipulated time Sensitivity Trade off Risk S3 T3 S5 R4 R3 N1 Nonrisk

Single Responsibility Reasoning Architecture Diagram

Standard practices NA

Scenario A01 Attribute Environment Stimulus Response Architecture decision DB Replication NoSQL Reasoning Architecture Diagram

Scenario: Scale for 100+ users Performance Normal Multiple users accessing webapp Featured delivered, first time right, within stipulated time Sensitivity S8 T1 Standard practices NA Trade off Risk R7 N3 Nonrisk

Sensitivities
S1: Detecting a box is down is very important for graceful degradation. Through status checks rather than ping can detect partial hardware failures also S2: Failover Routing is essential to remove a faulty box from cluster S3: Modularity is THE feature that governs future extension S5: Single Responsibility ensure robust classes adaptive for CR S6: Replicated data store => active redundancy S8: DB replication => same as S6

Trade-offs
T1: The current scalability requirements do not demand NoSql. It can also increase application complexity T3: Use Polymorphism. Can be taken at a later stage and can be neglected currently thanks to dynamically typed languages. T4: T1 assumed.

Risks
R1: status check should be reliable and need development effort R2: additional layer, possible single point of failure. R3 & R4: Need more experienced developer and added effort of code review R5:Configuration/Maintenance effort R6: Additional layer of MQ, another opportunity for failure R7: R6

Non Risks
N1: Can be neglected currently and can be considered later thanks to dynamically typed languages N3: Doesnt demand that level of scalability to deploy NoSQL

Topics:
1. 2. 3. 4. 5. 6. 7. 8. 9. Project Overview Architecture Business Cycle Quality Attributes Quality Tactics Architecture Pattern Architecture Views Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Project Demo

Cost Benefit Analysis Method (CBAM)

P Performance A Availability S Security M Modifiability

Step 1 Collate Scenarios

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. If one of the box is down, traffic should get diverted to another box within 1 second. If data store is down, user should be served without any interruption within 1 second. New feature should be added with less than 25 man hours and minimal rewrite of components Changes to OS, DB, Mailing application etc should not impact the domain layer Traffic should be protected from internet. Access should be protected from unauthorized use Protect from repudiation Scale for 100+ concurrent users Static HTTP pages should be served within 200ms Questions and Answers should be rendered within 2 sec

Step 2 Refine Scenarios

S# Response Attribute W 1 Traffic Diverted 5% Response Goals C 80% D 90% B 100%

2
3 4 5 6 7 8

No User Interruption
New feature addition Technology Changes Protected from internet Protected from unauthorized use Repudiation Scale 100+ Users

5%
10% 10% 50% 50% 10% 10%

85%
0% 0% 90% 80% <1% 70%

90%
1% 1% 95% 95% 1% 80%

100%
0% 0% 0% 0% 0% 100%

9
10

Static HTTP pages

Questions and Answers rendering

5%
50%

0%
90%

0%
95%

100%
100%

Step 3 Prioritize Scenarios

S# Votes Response Attribute
W

Response Goals
C D B

1
2 3 4 5 6 7 8 9 10

20
10 4 4 15 5 7 15 5 15

Traffic Diverted
No User Interruption New feature addition Technology Changes Protected from internet Protected from unauthorized use Repudiation Scale 100+ Users Static HTTP pages Questions and Answers rendering

5%
5% 10% 10% 50% 50% 10% 10% 5% 50%

80%
85% 0% 0% 90% 80% 2% 70% 0% 90%

90%
90% 1% 1% 95% 95% 1% 80% 0% 95%

100%
100% 0% 0% 0% 0% 0% 100% 100% 100%

Step 4 Assign Utility

S# Votes Utility Scores

W
1 2 3 4 20 10 2 2 10 10 5 10

C
80 80 70 75

D
100 95 100 90

B
100 100 100 100

5 6
7 8 9 10

15 5
7 15 5 15

10 5
10 10 10 10

80 70
20 90 75 80

90 90
90 100 90 100

100 100
90 100 80 100

Step 5 Develop Architecture Strategy

Strategy Architecture Strategy Scenarios Affected 1 2 Current Response 80% 85% Expected Response 90% 90%

Ensure site up

Authorization and Data Integrity

5
6 7

90%
80% 2% 70% 0% 90% 0% 0%

95%
95% 1% 80% 0% 95% 1% 1%

Ensure high performance

8 9 10

Code extensibility

3 4

Step 6 Determine expected QA response

Strategy Architecture Strategy Scenarios Affected
1 2 2 Authorization and Data Integrity 5 6 7 3 Ensure high performance 8 9 10 4 Code extensibility 3 4

Current Utility
80 80 80 70 20 90 75 80 70 75

Expected Utility
100 95 90 90 90 100 90 100 100 90

Ensure site up

Step 7 Calculate total benefit obtained from AS

Strategy Scenarios Affected 1 2 2 5 6 7 3 8 9 10 4 3 4 Scenario Weight (Wj) 20 10 15 5 7 15 5 15 4 4 Raw AS Benefit (bi,j) 20 15 10 20 70 10 15 20 30 15 Normalized AS Total AS Benefit Benefit (bi,j x Wj) (Bi) 400 150 150 100 490 150 75 300 120 60 180 525 740 550

Step 8 Choose Architectural Strategies based on ROI

Strategy Architecture Strategy Cost (Ci) Total AS Benefit (Bi) Strategy ROI (Ri = Bi / Ci) Strategy Rank

1
2 3 4

Ensure site up
Authorization and Data Integrity Ensure high performance Code extensibility

700
800 1200 500

550
740 525 180

0.78
0.92 0.43 0.36

2
1 3 4

Step 9 Check if chosen architectural strategies align with the business goals As per our business goals also, security and availability are of high importance