The document outlines an architecture methodology for consulting with a focus on architectural drivers, design, and solution architecture for a cloud software company, Showmelogs. It discusses key use cases, design decisions, constraints, and quality attributes for building a logging platform, aiming to optimize, protect, and monitor web applications. The document also details the proposed deployment strategies, including the use of a lambda architecture and various tactics for ensuring reliability and scalability in data processing.

3. Completed Architecture Methodology

4. Architect in Consulting: architecture drivers

5. Architect in Consulting: ADD

7. Architectural Design Delivers
• Documented, abstract,
verifiable model of the designed
system
• Collection of the significant
design decisions hard or costly
to change
• Mapping of elicited problems to
strategical and tactical solutions
• Communication vehicle about
the system among stakeholders

8. Document Types
(Cx — Cy) > Cdiff | Predefined templates will save around 25% of your time
Proposal
Architecture Vision/Architecture Assessment Report
Software Architecture Document (SAD)
Feature Design Document

9. Document Structure
General
Drivers
Architecture Decisions
Summary from sections below
Achieve

10. Document Structure
Apendix
Introduction Executive summary Architecture Drivers
Solutions Architecture Operation Plan
Implementation Plan
Optinal
View#1 View#N Transition Phase Operation Phase

11. General
Introduction
Document Purpose
Document Scope Definitions
Reference External Relations
Documentation Map
Executive Summary
Key Decision Key Risk Key Issues

12. Architecture Drivers
The section captures significant requirements driving the solution architecture and road map
Significant architecture requirements (SAR)
Business Case
SLA
Use Cases
Domain Model
Constraint
QA Scenario
QAS Refimaint
Arch Concern

13. Any View Structure
The section Solution Architecture is primary for the Architecture Vision, SAD, Architecture Assessment
document. It defines and reasons about the solution architecture design based on the architecturally
significant requirements and constraints identified in the section Architectural Drivers
View N
Intent
Context
Representation
Elements
Contracts
Behavior
Variability
Reasoning

14. Architecture Approach
System Context View
Container View
The C4 based model for visualizing software architecture
Component View
Deployment View
”Tactic” View #N

15. Review Session:
Structure and Format
Architecture Template

16. Project: ShowMeLogs
Business case

17. ShowMeLogs Business Case
ShowMeLogs is an innovative Cloud
Software Company that offers a web
infrastructure platform that
optimizes, protects and monitors
websites and web applications,
delivering speed, scale, security and
actionable insight.
ShowMeLogs is planning to build the
logging platform for collecting real-
time logs for analytics purposes.

18. Use Cases I

19. ID Use Case Actors
UC-1 Raw logs access
Customers should be able to download raw HTTP request logs hitting
the ReadMeNow infrastructure. Enabling them to have access to their
logs in a timely fashion without the need to ask ReadMeNow Support
streamlines their incident response process.
Customer
UC-2 Anomaly detection
Customers have varying definitions for traffic anomalies they would
like to detect based on HTTP request logs. Using the ReadMeNow
application, they
should be able to define these issues and be notified when these
issues occur.
Customer
UC-3 Visual insight with real-time dashboard
Customers and ReadMeNow personnel should be able to discover the
root cause of issues and see correlation between various time-based
events and impact of events on key performance metrics.
Customers,
Operations, Security
Administrator,
Support Engineers,
Client Services, Site
Optimizers and
Release Engineers
UC-4 Data Discovery with ad-hoc queries
ReadMeNow personnel (Operations) should be able to execute ad-hoc
queries over historical data to improve infrastructure
Operations
UC-5 Data Retention
The system should comply insurance regulation and implement data
retention policy (7 years)
System
UC-6 API for customers and partners
Customers and partners should have access to dashboard data
through REST service API
Customer, Partner
Project
Use Cases

20. Project
Constraints
and
Architecture
Concerns

21. System
Quality
Attribute
Scenario

22. Review Session: Adding business
case, constraints, use cases and
quality attributes
Architecture Drivers

23. Design
the System
•Define the context view of the system described in the workshop
business case.
•Perform decomposition of the system and document it as a view.
•Make primary decisions on the deployment of the system.
•Address a few concrete quality attribute scenarios selecting proper
tactics, patterns, and technologies.

24. Design Concept

25. System Context diagram

26. Intent
for
Decomposition
UC-1 Raw log access
UC-3 Visual insight with real-time dashboard
UC-4 Data discovery with ad-hoc queries
UC-5 Data retention
QA-1 Performance. The analytics dashboard shall load data within 5
seconds
QA-4 Scalability. The system shall process and store 1 BLN events per
day, max 50-80 M events per site UC-1-6 Now 20% of the clients
generate 80% of the traffic, other clients have rather small logs.
QA-5 Scalability. The dashboard shall have access to data of 3 month
period (ideally), 1 month is still OK or 1 week in worst case
QA-6 Scalability. Data discovery with ad-hoc queries shall have access to
data of 1 year (minimum) or 2 years (ideally) period
QA-7 Scalability. Raw data shall be stored for 7 years period (insurance
regulation)
QA-11 Reliability. The data collection and event delivery mechanism
shall be reliable (ideally 0% message loss, expected 0.1%)
CN-1 Select primary reference architecture for ShowMeLogs solution

27. System Decomposition

28. System Decomposition: Reasoning
UC-1, UC-3, UC-4, UC-5, QA-1, QA-4, QA-5, QA-6, QA-7,
QA-11, CN-1
Decisions ⇩ Sens
itivit
y
Trad
eoff
Risk Non-
Risk
Select Lambda architecture S1 T1 R1
Introduce data agents for
data collection
S2 T2
Introduce load balanced
data collector
S3 R2
•S1 - Lambda architecture positively affects performance
of the data processing
•S2 - allows adopting different log data sources
•S3 - load balancer positively affects reliability and
performance
•T1 - introduce additional complexity and negatively
affect deployability
•T2 - additional complexity on deployability and
monitoring
•R1 - increases cost of development, hosting and
support potentially leading to over budgeting
•R2 - load balancer can be a single point of failure

29. Intent
for Deployment
CT-1 Time to market: 3 months from start of development , beta version
(for internal users)
CT-2 Environment: Portal (Ruby/Rails), Platform (Java)
QA-4 Scalability: The system shall process and store 1 BLN events per
day, max 50-80 M events per site UC-1-6 Now 20% of the clients
generate 80% of the traffic, other clients have rather small logs.

30. System Deployment

31. Intent
for
Tactic View
Intent: QA-10: The distributed messaging shall support "at least once"
delivery mechanism, duplicates are possible; QA-11 The data collection
and event delivery mechanism shall be reliable (ideally 0% message loss,
expected 0.1%)

32. Tactic View

33. Tactic View: Reasoning
QA-10
Decisions ⇩ Sens
itivit
y
Trad
eoff
Risk Non-
Risk
Use Syslog to collect data
from Varnish server and
Flume Syslog source;
S1 T2,
T3
R1
Use Flume file_channel
option for reliable log
persistence (in case of node
failure or to avoid memory
overflow when log
destination is disconnected)
S2 T1,
T2,
Use Kafka to buffer latest 24
hours and replay logs in
case of destination failure
S3
•S1 - Syslog caches messages on the client side adding
up to the client side reliability;
•S2 - Flume positively influences in-transit reliability as it
stores all events in file surviving through failure;
•S3 - Kafka works as a buffer preventing overflow in
server side event processing engine and allowing re-
processing in case of any failure;
•T1 - Using file channel for Flume introduces additional
data latency;
•T2 - Introducing new layers for event transfer (such as
syslog, kafka) negatively influences event data latency;
•T3 - Deployment complexity grows;
•R1 - Fault detection and prevention is hard to achieve
due to event transfer complexity;

34. Review Session: Context,
Decomposition, Deployment and
Tactic
Architecture Views

35. THANK YOU!
ANY QUESTIONS?