Solution Architecture

Template

Info-Tech Research Group Inc. is a global leader in providing IT research and

advice. Info-Tech’s products and services combine actionable insight and
relevant advice with ready-to-use tools and templates that cover the full
spectrum of IT concerns.
© 1997-2021 Info-Tech Research Group Inc.
Solution Architecture
Product: <Name> <version>

Info-Tech Research Group | 2

How to use this workbook
instruction
Follow the bubbles
01 These will indicate what you need to fill in to make your digital product
vision your own. Feel free to use our suggested language or substitute
what you prefer. Please delete the bubbles when you no longer need them.

Use as much or as little as you like

We provide several explanation slides to add context to the results of your
exercises. You can leave these in, change them, or remove them depending
02
on your needs.

Let our templates open your mind

03 The various templates we use are meant to guide you down the right path.
Most larger products will require more space than we provide. Feel free to
add lines and pages and do whatever is necessary to document what you
want to do.

Success isn’t achieved overnight

Change is a process, not a light switch. We encourage you to write as 04
much down as you can, discuss with your team, and iterate. The content
you place in these workbooks is meant to evolve over time as you learn
Info-Tech Research Group | 3
more and certainly won’t be complete in a single day!
Phase 1.1: Craft a vision statement for your solution’s architecture

Tracking info:
• Product owner
Name of product,
• Link to
service, or family
knowledgebase
or repository
Vision, unique
• Last update date
value proposition,
(automatic)
elevator pitch, or
positioning
statement

Metrics used to
List of business measure value
objectives or goals realization and
for the product ensure goals are
achieved

List of key
List of groups who resources,
consume the stakeholders, and
product/service teams needed to
support the
product/service
Info-Tech Research Group | 4
 Phase 1.2: Document dynamic value stream maps

Loan Provision
Choose either one of the documentation
Loan Disbursement of Risk Service styles shown here.
Application Funds Management Accounts

Disbursement of STYLE # 1:
Funds
Applicant’s Bank The use case Disbursement of Funds has three actors:

1. A Loan Applicant who applied for a loan and got approved for one.
2. A Loan Supplier who is the source for the funds.
Deposit Loan 3. The Applicant’s Bank that has an account into which the funds are deposited.
Into
Applicant’s
Bank Account
Loan
Applicant
Loan Supplier STYLE # 2:

Loan Provision: Disbursement of Funds

Use Case Actors Interaction
Deposit Loan Into Applicant’s (1) Loan Applicant (1) Should be able to see deposit in bank account
Bank Account (2) Loan Supplier (2) Deposit funds into account
Repeat this exercise for every use case and (3) Applicant’s Bank (3) Accept funds into account
user role combination.

Info-Tech Research Group | 5

Phase 1.2: Document architectural design decisions using SRME

Deposit Loan Into Applicant’s Bank Account

User Loan Applicant

Expectations On login to the web system, should be able to see accurate bank balance after loan funds are
deposited.
Stimulus User signs into the online portal and opens their account balance page.
Expected Response From System System creates a connection to the data source and renders it on the screen in under 10ms.
Measurement Under Normal Loads: Under Peak Loads:
• Response in 10ms or less • Response in 15ms or less
• Data should not be stale • Data should not be stale
Quality Attribute Required • Required Attribute # 1: Performance
o Design Decision: Reduce latency by placing authorization components closer to user’s
location.
• Required Attribute # 2: Data Reliability
o Design Decision: Use event-driven ETL pipelines.

For net-new requirements, use this table

structure. Repeat this exercise for every use case and
user role combination.
Info-Tech Research Group | 6
Phase 1.2: Document architectural design decisions for technical debt relief

Repeat this exercise for appropriate use

Deposit Loan Into Applicant’s Bank Account cases and user role combination.

User Loan Applicant

Expectations On login to the web system, should be able to see accurate bank balance after loan funds are
deposited.
Stimulus User signs into the online portal and opens their account balance page.
Expected Response From System System creates a connection to the data source and renders it on the screen in under 10ms.
Measurement Under Normal Loads: Under Peak Loads:
• Response in 10ms or less • Response in 15ms or less
• Data should not be stale • Data should not be stale
Quality Attribute Required • Required Attribute # 1: Performance
o Expected is 15ms or less under peak loads, but average latency is 21ms.
o Design Decision: Increase the number of data servers in areas with average latency >18ms.
• Required Attribute # 2: Data Reliability
o Data should not be stale and should sync instantaneously, but in some zip codes data
synchronization is taking 8 hours.
o Design Decision: Set up parallel distributed ETL pipelines.

For existing requirements, use this table

Info-Tech Research Group | 7
structure.
Phase 1.3: Create a conceptual map between the value stream component, use case,
and required architectural attribute
Loan Provision
Loan Disbursement of Risk Service
Application Funds Management Accounts

Value Stream Component Use Case Required Architectural Attribute

Loan Application UC1: Submit Loan Application UC1: Resilience, Data Reliability
UC2: Review Loan Application UC2: Data Reliability
UC3: Approve Loan Application UC3: Scalability, Security, Performance
UCn: …….. UCn: …..
Disbursement of Funds UC1: Deposit Funds Into Applicant’s Bank Account UC1: Performance, Scalability, Data Reliability
UCn: ……..
Risk Management ….. ….

Service Accounts ….. ….

Info-Tech Research Group | 8

Phase 1.4: Create a prioritized list of architectural attributes
Legend
Loan Provision
Loan Disbursement of Risk Service Very Important Fairly Mildly Important
Application Funds Management Accounts
Important

Replace the attributes in the column with

those that were discovered in section 1.3

Info-Tech Research Group | 9

Phase 2.1: Discuss and document data architecture decisions

Data Management Requirements for Risk Management Reporting Data Design Decision
Needs to query millions of relational records quickly • Strong indexing
• Strong caching
• Message queue
Needs a storage space for later retrieval of relational data • Data storage that scales as needed
Need turnkey geo-replication mechanism with document retrieval in milliseconds • Add NoSQL with geo-replication and quick
document access

Info-Tech Research Group | 10

Phase 2.2: Document security architecture risks and mitigations

Example of using STRIDE for a TRA on a system using a payment system

Threat System Component Description Quality Attribute Impacted Resolution

Spoofing PayPal Bad actor can send fraudulent payment request for obtaining funds. Confidentiality Authorization

Tampering Bad actor accesses data base and can resends fraudulent payment request
PayPal Integrity Authorization
for obtaining funds.
Repudiation Customer claims, incorrectly, their account made a payment they did not Authentication and
PayPal Integrity
authorize. Logging
Disclosure PayPal Private service database has details leaked and made public. Confidentiality Authorization

Denial of Service is made to slow down through creating a load on the network,
PayPal Availability N/A
Service causing massive build up of requests
Elevation of Bad actor attempts to enter someone else’s account by entering incorrect Confidentiality, Integrity, and
PayPal Authorization
Privilege password several times. Availability

*Feel free to use any technique, other than STRIDE, that you are aware of.

Info-Tech Research Group | 11

Phase 3.1-3.2: Discuss and document initial decisions made for architecture scalability and
performance

Value Stream Component Design Decision for User Interface Layer Design Decisions for Middle Processing Layer

Loan Application Scalability: N/A Scalability: Scale vertically (up) since loan application
Resilience: Include circuit breaker design in both mobile processing is very compute intensive
app and responsive websites Resilience: Set up fail-over replica
Performance: Cache data client Performance: Keep servers in the same geo-area
Disbursement of Funds *Does not have a user interface* Scalability: Scale horizontal when traffic reaches X
requests/second
Resilience: Create microservices using domain-driven
design; include circuit breakers
Performance: Set up application cache; synchronous
communication since order of data input is important
…. …. ….

Info-Tech Research Group | 12

Phase 3.3: Combine the different architecture design decisions into a unified solution
architecture
From Phase 2.2: Security Design Decisions From Phase 2.1: Data Design Decisions

Value Stream Design Decision for User Interface Layer Design Decisions for Middle Processing Design Decisions for Database Layer
Component Layer
Loan Application Security: Use JSON Tokens Security: HTTPS communication Data Reliability: Use real-time data
Scalability: N/A between APIs. stream for rates information.
Resilience: Include circuit breaker design Scalability: Scale vertically (up) since Search Performance: Use indexes and
in both mobile app and responsive loan application processing is very implement cache for selected long-
websites. compute intensive. running queries.
Performance: Cache data client. Resilience: Set up fail-over replica. Security: All personal information will be
Performance: Keep servers in the same saved as a hash.
geo-area.
Disbursement of *Does not have a user interface Scalability: Scale horizontal when traffic Data Reliability: Use real-time data
Funds reaches X requests/second. stream for rates information.
Resilience: Create microservices using Data Archive: Horizontally auto-scaled
domain-driven design; include circuit storage space.
breakers.
Performance: Set up application cache;
synchronous communication since order
of data input is important.

Info-Tech Research Group | 13

Phase 3.3: Combine the different architecture design decisions into a unified solution
architecture
Add additional columns if needed.

Value Stream Components Design Decision for User Design Decision for Design Decision for
Interface Layer Middle Processing Layer Database Layer

Info-Tech Research Group | 14