Lead Allocation System - Attribute Driven Design (ADD)

Lead Allocation System Attribute Driven Design By, A3, Inc.

Introduction ADD Steps ADD Inputs ADD Outputs (Architecture Design)

Introduction (Cont.)

According to SEI

The SEI's Attribute-Driven Design (ADD) method is a systematic step-by-step method for designing the software architecture of a software-intensive system

Business Opportunity

Current System is Legacy

Requires a lot of manual labor from marketing department

Vertical currently breaking even because of operation costs

New Generic System

Generic enough to run across A3, Inc. verticals

Allocate in real time products that are of interest to partners

Success Criteria

Marketing department cost: Reduced by 60% within one year.

IT department cost: reduced by 15% within six month.

Reduce Time for allocation the Leads: from days to hours which will increase company revenue from 10% to 20% within six months.

Lead conversions: Increased by 50%. Within six months.

Partner’s satisfaction rate: Increased by 50% within one year.

Stakeholder’s Goals

Real time allocation – Leads can be contacted as soon as they are allocated. The waiting time would reduce from days to a time period, in the seconds, that the marketing department deems appropriate.

Marketing department – Increased conversion would make advertising for marketing department easier since they would now be able to market the business with a new niche.

Business Risks

Exclusive lead means assigning a lead to a partner who accepts a lead which it has no demand for

All transactions must be logged at granular level for debugging and legal purposes

Legal agreement between A3 Inc. and partners necessary

Major Features

Real time lead allocation

Allocate lead to highest bidder

Real time

Partners would bid or decline to bid for a lead

Lead would be allocated to the highest bidder

Partners need to respond in a legally binding SLA

Partners would do not respect SLAs would be ignored even if their bid is the higest. This is very important to keep the system in a “Real Time” mode at all times.

Major Features

Real time Lead Acquisition

Acquire leads through any middleware or front-end system

Be interoperable

Constraints

End product will be DLL(s) that can be referenced by different types of applications, including Web Services.

The runtime environment will be the .NET CLR.

OOD shall be used with a clear separation of objects that consume data and objects that produce data.

Interfaces between components shall be designed to only take primitive types and return primitive types.

Quality Scenarios

The system needs to allocate the lead no later than 8 sec and would concurrently process no more than 10 leads at one time. If the system receives more than 10 leads, it should handle them using a queue.

LAS needs to be available 24 hours a day, 7 days a week, 365 days a year bearing significant hardware malfunction. The LAS architecture should accommodate this using some sort of backup system.

LAS should only allow trusted sources access to API calls. If the API calls are from un-trusted sources, then LAS should deny access.

The API calls should be secure so that malicious third party persons/software cannot view information going to and from the LAS.

First Iteration

Sufficient Requirement Information

Element to Decompose

Candidate Architecture Drivers

Design Concept that Satisfies Architectural Drivers

Instantiate Architectural Elements and Allocate Responsibilities

Define interfaces for Instantiated Elements Verify and refine requirements

After reviewing the inputs, the architecture team has determined that there sufficient requirements information.

Since this is the first iteration, the architecture team has decided to start at the root, which is LAS.

Low High 1.2 Constraint 4 Primitive API calls only 10 Low Medium 1.2 Constraint 3 OOD used 9 Low Medium 1.2 Constraint 2 Run in .NET CLR 8 Low Medium 1.2 Constraint 1 Compiled DLLs 7 High High 1.1 Requirement 2 Allocate Lead 6 Medium High 1.1 Requirement 1 Acquire Lead 5 Medium High 1.3 Scenario 4 Secure access 4 Medium High 1.3 Scenario 3 Trusted access only 3 Medium Medium 1.3 Scenario 2 System availability 2 High Medium 1.3 Scenario 1 Allocate Lead Performance 1 Difficulty Importance Section Discussed In Architectural Drivers #

Identify design concerns

Modifiability, Localize Modification 10 Modifiability, Prevent Ripple Effect 9 Modifiability, (N/A) 8 Modifiability, Localize Modification 7 Modifiability, Prevent Ripple Effect 6 Modifiability, Prevent Ripple Effect 5 Security, Resisting Attacks 4 Security, Resisting Attacks 3 Availability, Fault Recovery 2 Performance, Resource Arbitration 1 Design Concern AD#

Alternative Patterns that address the concerns

Use an Intermediary Pros – Easy to understand. Cons – Tedious to implement. Hide information Pros – Traditional. People are most familiar with it Cons – Depends strongly on skills and talents of the person implementing it. Modifiability, Prevent Ripple Effect 5 Maintain Data Confidentiality Pros – Software such as SSL exist and is easy to implement Cons – Need to purchase SSL certificate. Authenticate Users Pros – Easy to use in conjunction with Authorize users Cons – Need additional software or man power to manage user registration Security – Resisting Attacks 4 Authorize users Pros – Dynamic. Easy to modify Cons – Need additional software such as Active Directory Limit Access Pros – High Security Cons – Need to know IP address of incoming request Security - Resisting Attacks 3 Active Redundancy Pros – Data will be up to date. Also, recovery time will be milliseconds. Cons – Need additional monitoring and switching software Spare Pros – Easy to configure Cons – Data will not be up to date and recovery time will be minutes. Availability – Fault Recovery 2 Fixed-Priority Pros - Flexibility for priority Cons – Difficult to implement FIFO Pros - Easy to implement Cons – No flexibility for priority Performance - Resource Arbitration 1 Pattern (pros/cons) Pattern (pros/cons) Design Concern AD #

Anticipate Expected Changes Pros – Fits in nicely with Maintain Semantic Coherence pattern. Cons – Difficult to determine what to anticipate for. Generalize the Module Pros – Makes communication with modules much simpler. Cons – Makes the inner workings of the module somewhat more complex, hence requiring more qualified people. Modifiability – Localize Modifications 10 Use an Intermediary Pros – Easy to understand. Cons – Tedious to implement. Hide information Pros – Traditional. People are most familiar with it Cons – Depends strongly on skills and talents of the person implementing it. Modifiability, Prevent Ripple Effect 9 N/A N/A N/A 8 Limit Possible Options Pros – Requires zero development time Cons – Requires senior management buy in Maintain Semantic Coherence Pros – Creates reusability as well as preventing ripple effects Cons – Time consuming. Requires talented professionals. Modifiability – Localize Modifications 7 Use an Intermediary Pros – Easy to understand. Cons – Tedious to implement. Hide information Pros – Traditional. People are most familiar with it Cons – Depends strongly on skills and talents of the person implementing it. Modifiability, Prevent Ripple Effect 6

Selected Patterns

For AD # 1 the architecture team selected the FIFO pattern. The reason for this was mainly because of the simplicity of implementing such a pattern and although it does not exceed the requirements, it certainly meets them. Also, there are resources on the team that are very familiar with this pattern

For AD # 2 the architecture team selected Active Redundancy pattern. This choice was because the team decided that since the spare is not up to date and it takes minutes to recover it is vastly inferior to the Active Redundancy pattern.

For AD # 3 the architecture team selected Authorize Users patterns. This choice was because the team decided that limiting access to certain IP addresses was really not practical for a web based application since managing client IP addresses would be too restrictive and sometimes, not possible.

For AD # 4 the architecture team decided that both Authenticate Users and Maintain Data Confidentiality patterns will be required because of their relationship to each other. They have good synergy and really cannot exist without coexisting in this instance.

For AD # 5 the architecture team selected Hide Information pattern. This choice was because of the natural nature of this pattern and also because of the tedious nature of the Use an Intermediary pattern.

Selected Patterns

For AD # 7 the architecture team selected Maintaining Symantec Coherence pattern. This choice was made because the architecture team decided that depending on management to limit possible options, even though they might agree initially, is not realistic.

N/A

For AD #10 the architecture team decided that a combination of both the Generalize the Module and Anticipate Expected Changes pattern would be a good way to go. The reason for this choice was because since the API for the LAS needs to work for other platforms having the inner workings of the middleware adjust based on the primitive input types would be ultra helpful. To have this architecture team decided that it would have to think 2 steps ahead and anticipate what changes would occur.

Selected Patterns Related

Use Event Driven Architecture (EDA)

allow loosely coupled objects

packages a way of communication

meets and exceeds the patterns identified so far

Capture Preliminary Architectural Views

Instantiate Elements

Assign Responsibilities to Elements

Active Redundancy 2 Redundant LAS servers 1, 2, 3 6 Authenticate Users, Maintain Data Confidentiality, Authorize Users 3, 4 Security Service 5 FIFO 1 Allocate Lead FIFO computation 4 Hide information 6 Allocate Lead Service 3 Hide information 5 Acquire Lead Service 2 Generalize the Module, Hide information, Maintain Semantic Coherence, Anticipate Expected Change 7, 8, 9, 10 LAS API Adapter 1 Pattern (s) Architectural Driver Element Name Element #

Allocate Responsibilities

LAS API Adapter – This element is responsible for receiving API calls, interpreting them and passing them along to other elements.

Acquire Lead Service – This element is responsible for receiving leads from lead providers and preparing them to be allocated to lead acquirers.

Allocate Lead Service – This element is responsible for providing lead heading to lead acquirers that ask for it. It is also responsible for accepting bids and sending complete leads to lead providers.

Allocate Lead FIFO – This element is responsible for the FIFO algorithm computation to handle multiple lead acquirers requesting leads simultaneously.

Security Service – This element is responsible for making sure only trusted lead providers and lead acquirers have access to LAS and they are who they say they are.

Redundant LAS server 1, 2, 3 – These elements would act as mirrored duplicates in case the primary LAS server experiences problems.

Interfaces for Instantiated Elements

N/A N/A Redundant LAS servers 1, 2, 3 TO ALLOCATE LEAD SERVICE: Trusted user security information TO ACQUIRE LEAD SERVICE: Trusted user security information FROM ACQUIRE LEAD SERVICE: Trusted user information FROM ALLOCATE LEAD SERVICE: Trusted user information Security Service TO ALLOCATE LEAD SERVICE: Lead request from queue. Lead bid from queue. FROM ALLOCATE LEAD SERVICE: Lead request information. Lead bid information. Allocate Lead FIFO Computation TO ALLOCATE LEAD FIFO COMPUTATION: Lead request information. Lead bid information. TO SECURITY SERVICE: Trusted user information FROM LAS API ADAPTER: Lead request information. Lead bid information. Trusted user information Allocate Lead Service TO SECURITY SERVICE: Trusted user information FROM LAS API ADAPTER: Lead information. Trusted user information Acquire Lead Service TO LEAD PROVIDER: A lead recorded successful message and transaction reference number. TO LEAD ACQUIRER: A lead heading. An interface to allow the lead provider to place a bid, and the full lead if the lead acquirer decided to buy the lead. The interface should also provide a transaction reference number. TO ACQUIRE LEAD SERVICE: The lead information TO ALLOCATE LEAD SERVICE: The request for a lead information Primitive type input from lead providers or lead acquirers. This would be lead information from the lead providers and lead request information from lead acquirers. It would also require trusted user information such as a username and password. LAS API Adapter Provides Requires Element

Verify and refine requirements

All the architectural drivers (functional requirements, constraints, and quality scenarios) have been accounted for.

Second Iteration

Define interfaces for Instantiated Elements Verify and refine requirements

This step is not necessary for the second iteration since it was done once at the beginning of the ADD process.

Current knowledge of the architecture

The security service element has chosen as the system to decompose. Specifically when acquire lead and allocate lead services are targeted as per section 2.6.

Risk and difficulty

Since this element is depending upon the third party active directory therefore it is very difficult to achieve the element associated requirements.

In order to decompose this element, active directory component should be setup and the users profiles need to be inserted.

Business criteria

Security element plays a vital role in the system as per SRS.

Partners need to be in active directory before LAS system broadcast the lead.

Secure Certificate Layer needs to be set before LAS will go live

Organizational criteria

Security has been identified a highest priority for the LAS as per the business vision and SRS because this element has an direct impact on the overall LAS

Low High 2.6 Constraint 1 Active Directory 4 Medium High 2.6 Scenario 3 Trusted access only 3 Medium High 2.4.2 Scenario 2 Authenticate Users 2 High High 2.4.2 Scenario 1 Authorize User 1 Difficulty Importance Section Discussed In Architectural Drivers #

Identify design concerns

Modifiability, Localize changes, Prevent Ripple Effect 4 Security, Resisting Attacks, Maintain integrity 3 Security, Resisting Attacks, Authenticate User 2 Security, Resisting Attacks, Authorize User 1 Design Concern AD#

N/A Prevent Ripple Effect Pros – Enterprise standard, and easy to configure Cons – Need to add every partner. Modifiability, Localize changes, Prevent Ripple Effect 4 N/A Maintain Integrity Pros – Software such as SSL exist and is easy to implement Cons – Need to purchase SSL certificate. Security, Resisting Attacks, Maintain integrity 3 N/A Authenticate Users Pros – Reduce time, because for authenticate Enterprise uses active directory Cons – Needs extra resource for the configuration. Security – Resisting Attacks, Authenticate User 2 N/A Access Matrix / Authorization [1] Pros – Flexible Cons – Need additional resources to maintain the user profile and their roles Security - Resisting Attacks, Authorize User 1 Pattern (pros/cons) Pattern (pros/cons) Design Concern AD #

Selected Patterns

There is no other alternative pattern has been identified

Selected Patterns Related

Security Architecture for Authentication and Authorization of LAS by using AD

Capture Preliminary Architectural Views

Instantiate Elements

Active Directory User Role Database LAS Services LAS Gateway

Assign Responsibilities to Elements

Maintain Integrity 3 Gateway of LAS 3 Access Matrix / Authorization 2 User role database 2 Authenticate, Prevent Ripple Effect 1, 4 Active Directory 1 Pattern (s) Architectural Driver Element Name Element #

Allocate Responsibilities

Active Directory: When users will try to invoke any LAS services, this element will authenticate the users first and then allow users to entire in to the system

User role database: for the authorization level of the LAS services a database needs to be created where user profiles will be stored

Gateway: A new gateway needs to be purchased from the third party for secure socket layer and configure it

Interfaces for Instantiated Elements

It provides the 128 bit encryption for the entire LAS system. Set up and configuration for LAS system. Gateway It provides authorization for LAS services. A setup as well as tables needs to be created for each and every LAS service user. And also identify the role. User role database It provides authentication and a system will be secure after implementing this element. A setup and configuration need to require for entire LAS services. Active Directory Provides Requires Element