Get Instant Access
to This Blueprint

Applications icon

Enhance Your Solution Architecture Practices

Ensure your software systems solution is architected to reflect stakeholders’ short- and long-term needs.

  • In today’s world, business agility is essential to stay competitive. Quick responses to business needs through efficient development and deployment practices is critical for business value delivery.
  • A mature solution architecture practice is the basic necessity for a business to have technical agility.

Our Advice

Critical Insight

Don’t architect for normal situations. That is a shallow approach and leads to decisions that may seem “right” but will not be able to stand up to system elasticity needs.

Impact and Result

  • Understand the different parts of a continuous security architecture framework and how they may apply to your decisions.
  • Develop a solution architecture for upcoming work (or if there is a desire to reduce tech debt).

Enhance Your Solution Architecture Practices Research & Tools

1. Solution Architecture Practices Deck – A deck to help you develop an approach for or validate existing solution architecture capability.

Translate stakeholder objectives into architecture requirements, solutions, and changes. Incorporate architecture quality attributes in decisions to increase your architecture’s life. Evaluate your solution architecture from multiple views to obtain a holistic perspective of the range of issues, risks, and opportunities.

2. Solution Architecture Template – A template to record the results from the exercises to help you define, detail, and make real your digital product vision.

Identify and detail the value maps that support the business, and discover the architectural quality attribute that is most important for the value maps. Brainstorm solutions for design decisions for data, security, scalability, and performance.


Member Testimonials

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve. See our top member experiences for this blueprint and what our clients have to say.

10.0/10


Overall Impact

$62,999


Average $ Saved

10


Average Days Saved

Client

Experience

Impact

$ Saved

Days Saved

The President and Fellows of Harvard College, a Massachusetts nonprofit corporation, acting by and through Harvard Business School

Guided Implementation

10/10

$62,999

10

LiveBetter

Guided Implementation

9/10

$3,719

2

Apogee Enterprises, Inc

Guided Implementation

10/10

N/A

N/A

Trinidad and Tobago Unit Trust Corporation

Guided Implementation

8/10

N/A

N/A

State of Wyoming

Workshop

10/10

N/A

N/A

eGov Jamaica Ltd.

Guided Implementation

8/10

N/A

N/A

Legal Practitioners Fidelity Fund

Guided Implementation

9/10

$12,189

20

Todd Energy Limited

Guided Implementation

9/10

$63,667

5


Workshop: Enhance Your Solution Architecture Practices

Workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.

Module 1: Vision and Value Maps

The Purpose

  • Document a vision statement for the solution architecture practice (in general) and/or a specific vision statement, if using a single project as an example.
  • Document business architecture and capabilities.
  • Decompose capabilities into use cases.

Key Benefits Achieved

  • Provide a great foundation for an actionable vision and goals that people can align to.
  • Develop a collaborative understanding of business capabilities.
  • Develop a collaborative understanding of use cases and personas that are relevant for the business.

Activities

Outputs

1.1

Develop vision statement.

  • Solution Architecture Template with sections filled out for vision statement canvas and value maps
1.2

Document list of value stream maps and their associated use cases.

1.3

Document architectural quality attributes needed for use cases using SRME.

Module 2: Continue Vision and Value Maps, Begin Phase 2

The Purpose

  • Map value stream to required architectural attributes.
  • Prioritize architecture decisions.
  • Discuss and document data architecture.

Key Benefits Achieved

  • An understanding of architectural attributes needed for value streams.
  • Conceptual understanding of data architecture.

Activities

Outputs

2.1

Map value stream to required architectural attributes.

  • Solution Architecture Template with sections filled out for value stream and architecture attribute mapping; a prioritized list of architecture design decisions; and data architecture
2.2

Prioritize architecture decisions.

2.3

Discuss and document data architecture.

Module 3: Continue Phase 2, Begin Phase 3

The Purpose

  • Discuss security and threat assessment.
  • Discuss resolutions to threats via security architecture decisions.
  • Discuss system’s scalability needs.

Key Benefits Achieved

  • Decisions for security architecture.
  • Decisions for scalability architecture.

Activities

Outputs

3.1

Discuss security and threat assessment.

  • Solution Architecture Template with sections filled out for security architecture and scalability design
3.2

Discuss resolutions to threats via security architecture decisions.

3.3

Discuss system’s scalability needs.

Module 4: Continue Phase 3, Start and Finish Phase 4

The Purpose

  • Discuss performance architecture.
  • Compile all the architectural decisions into a solutions architecture list.

Key Benefits Achieved

  • A complete solution architecture.
  • A set of principles that will form the foundation of solution architecture practices.

Activities

Outputs

4.1

Discuss performance architecture.

  • Solution Architecture Template with sections filled out for performance and a complete solution architecture
4.2

Compile all the architectural decisions into a solutions architecture list.


Enhance Your Solution Architecture Practice

Ensure your software systems solution is architected to reflect stakeholders’ short- and long-term needs.

Analyst Perspective

Application architecture is a critical foundation for supporting the growth and evolution of application systems. However, the business is willing to exchange the extension of the architecture’s life with quality best practices for the quick delivery of new or enhanced application functionalities. This trade-off may generate immediate benefits to stakeholders, but it will come with high maintenance and upgrade costs in the future, rendering your system legacy early.

Technical teams know the importance of implementing quality attributes into architecture but are unable to gain approval for the investments. Overcoming this challenge requires a focus of architectural enhancements on specific problem areas with significant business visibility. Then, demonstrate how quality solutions are vital enablers for supporting valuable application functionalities by tracing these solutions to stakeholder objectives and conducting business and technical risk and impact assessments through multiple business and technical perspectives.

this is a picture of Andrew Kum-Seun

Andrew Kum-Seun
Research Manager, Applications
Info-Tech Research Group

Enhance Your Solution Architecture

Ensure your software systems solution is architected to reflect stakeholders’ short- and long-term needs.

EXECUTIVE BRIEF

Executive Summary

Your Challenge

  • Most organizations have some form of solution architecture; however, it may not accurately and sufficiently support the current and rapidly changing business and technical environments.
  • To enable quick delivery, applications are built and integrated haphazardly, typically omitting architecture quality practices.

Common Obstacles

  • Failing to involve development and stakeholder perspectives in design can lead to short-lived architecture and critical development, testing, and deployment constraints and risks being omitted.
  • Architects are experiencing little traction implementing solutions to improve architecture quality due to the challenge of tracing these solutions back to the right stakeholder objectives.

Info-Tech's Approach

  • Translate stakeholder objectives into architecture requirements, solutions, and changes. Incorporate architecture quality attributes in decisions to increase your architecture’s life.
  • Evaluate your solution architecture from multiple views to obtain a holistic perspective of the range of issues, risks, and opportunities.
  • Regularly review and recalibrate your solution architecture so that it accurately reflects and supports current stakeholder needs and technical environments.

Info-Tech Insight

Well-received applications can have poor architectural qualities. Functional needs often take precedence over quality architecture. Quality must be baked into design, execution, and decision-making practices to ensure the right tradeoffs are made.

A badly designed solution architecture is the root of all technical evils

A well-thought-through and strategically designed solution architecture is essential for the long-term success of any software system, and by extension, the organization because:

  1. It will help achieve quality attribute requirements (security, scalability, performance, usability, resiliency, etc.) for a software system.
  2. It can define and refine architectural guiding principles. A solution architecture is not only important for today but also a vision for the future of the system’s ability to react positively to changing business needs.
  3. It can help build usable (and reusable) services. In a fast-moving environment, the convenience of having pre-made plug-and-play architectural objects reduces the risk incurred from knee-jerk reactions in response to unexpected demands.
  4. It can be used to create a roadmap to an IT future state. Architectural concerns support transition planning activities that can lead to the successful implementation of a strategic IT plan.

Demand for quick delivery makes teams omit architectural best practices, increasing downstream risks

In its need for speed, a business often doesn’t see the value in making sure architecture is maintainable, reusable, and scalable. This demand leads to an organizational desire for development practices and the procurement of vendors that favor time-to-market over long-term maintainability. Unfortunately, technical teams are pushed to omit design quality and validation best practices.

What are the business impacts of omitting architecture design practices?

Poor quality application architecture impedes business growth opportunities, exposes enterprise systems to risks, and consumes precious IT budgets in maintenance that could otherwise be used for innovation and new projects.

Previous estimations indicate that roughly 50% of security problems are the result of software design. […] Flaws in the architecture of a software system can have a greater impact on various security concerns in the system, and as a result, give more space and flexibility for malicious users.(Source: IEEE Software)

Errors in software requirements and software design documents are more frequent than errors in the source code itself according to Computer Finance Magazine. Defects introduced during the requirements and design phase are not only more probable but also more severe and more difficult to remove. (Source: iSixSigma)

Design a solution architecture that can be successful within the constraints and complexities set before you

APPLICATION ARCHITECTURE…

… describes the dependencies, structures, constraints, standards, and development guidelines to successfully deliver functional and long-living applications. This artifact lays the foundation to discuss the enhancement of the use and operations of your systems considering existing complexities.

Good architecture design practices can give you a number of benefits:

Lowers maintenance costs by revealing key issues and risks early. The Systems Sciences Institute at IBM has reported that the cost to fix an error found after product release was 4 to 5 times as much as one uncovered during design.(iSixSigma)

Supports the design and implementation activities by providing key insights for project scheduling, work allocation, cost analysis, risk management, and skills development.(IBM: developerWorks)

Eliminates unnecessary creativity and activities on the part of designers and implementers, which is achieved by imposing the necessary constraints on what they can do and making it clear that deviation from constraints can break the architecture.(IBM: developerWorks)

Use Info-Tech’s Continuous Solution Architecture (CSA) Framework for designing adaptable systems

Solution architecture is not a one-size-fits-all conversation. There are many design considerations and trade-offs to keep in mind as a product or services solution is conceptualized, evaluated, tested, and confirmed. The following is a list of good practices that should inform most architecture design decisions.

Principle 1: Design your solution to have at least two of everything.

Principle 2: Include a “kill switch” in your fault-isolation design. You should be able to turn off everything you release.

Principle 3: If it can be monitored, it should be. Use server and audit logs where possible.

Principle 4: Asynchronous is better than synchronous. Asynchronous design is more complex but worth the processing efficiency it introduces.

Principle 5: Stateless over stateful: State data should only be used if necessary.

Principle 6: Go horizonal (scale out) over vertical (scale up).

Principle 7: Good architecture comes in small packages.

Principle 8: Practice just-in-time architecture. Delay finalizing an approach for as long as you can.

Principle 9: X-ilities over features. Quality of an architecture is the foundation over which features exist. A weak foundation can never be obfuscated through shiny features.

Principle 10: Architect for products not projects. A product is an ongoing concern, while a project is short lived and therefore only focused on what is. A product mindset forces architects to think about what can or should be.

Principle 11: Design for rollback: When all else fails, you should be able to stand up the previous best state of the system.

Principle 12: Test the solution architecture like you test your solution’s features.

CSA should be used for every step in designing a solution’s architecture

Solution architecture is a technical response to a business need, and like all complex evolutionary systems, must adapt its design for changing circumstances.

The triggers for changes to existing solution architectures can come from, at least, three sources:

  1. Changing business goals
  2. Existing backlog of technical debt
  3. Solution architecture roadmap

A solution’s architecture is cross-cutting and multi-dimensional and at the minimum includes:

  • Product Portfolio Strategy
  • Application Architecture
  • Data Architecture
  • Information Architecture
  • Operational Architecture

along with several qualitative attributes (also called non-functional requirements).

This image contains a chart which demonstrates the relationship between changing hanging business goals, Existing backlog of technical debt, Solution architecture roadmap, and Product Portfolio Strategy, Application Architecture, Data Architecture, Information Architecture and, Operational Architecture

Related Research: Product Portfolio Strategy

Integrate Portfolios to Create Exceptional Customer Value

  • Define an organizing principle that will structure your projects and applications in a way that matters to your stakeholders.
  • Bridge application and project portfolio data using the organizing principle that matters to communicate with stakeholders across the organization.
  • Create a dashboard that brings together the benefits of both project and application portfolio management to improve visibility and decision making.

Deliver on Your Digital Portfolio Vision

  • Recognize that a vision is only as good as the data that backs it up. Lay out a comprehensive backlog with quality built in that can be effectively communicated and understood through roadmaps.
  • Your intent is only a dream if it cannot be implemented ; define what goes into a release plan via the release canvas.
  • Define a communication approach that lets everyone know where you are heading.

Related Research: Data, Information & Integration Architecture

Build a Data Architecture Roadmap

  • Have a framework in place to identify the appropriate solution for the challenge at hand. Our three-phase practical approach will help you build a custom and modernized data architecture.
  • Identify and prioritize the business drivers in which data architecture changes would create the largest overall benefit and determine the corresponding data architecture tiers that need to be addressed.
  • Discover the best-practice trends, measure your current state, and define the targets for your data architecture tactics.
  • Build a cohesive and personalized roadmap for restructuring your data architecture. Manage your decisions and resulting changes.

Build a Data Pipeline for Reporting and Analytics

  • Understand your high-level business capabilities and interactions across them – your data repositories and flows should be just a digital reflection thereof.
  • Divide your data world in logical verticals overlaid with various speed data progression lanes, i.e. build your data pipeline – and conquer it one segment at a time.
  • Use the most appropriate database design pattern for a given phase/component in your data pipeline progression.

Related Research:Operational Architecture

Optimize Application Release Management

  • Acquire release management ownership. Ensure there is appropriate accountability for the speed and quality of the releases passing through the entire pipeline.
  • A release manager has oversight over the entire release process and facilitates the necessary communication between business stakeholders and various IT roles.
  • Instill holistic thinking. Release management includes all steps required to push release and change requests to production along with the hand-off to Operations and Support. Increase the transparency and visibility of the entire pipeline to ensure local optimizations do not generate bottlenecks in other areas.
  • Standardize and lay a strong release management foundation. Optimize the key areas where you are experiencing the most pain and continually improve.

Build Your Infrastructure Roadmap

  • Increased communication. More information being shared to more people who need it.
  • Better planning. More accurate information being shared.
  • Reduced lead times. Less due diligence or discovery work required as part of project implementations.
  • Faster delivery times. Less low-value work, freeing up more time for project work.

Related Research:Security Architecture

Identify Opportunities to Mature the Security Architecture

  • A right-sized security architecture can be created by assessing the complexity of the IT department, the operations currently underway for security, and the perceived value of a security architecture within the organization. This will bring about a deeper understanding of the organizational infrastructure.
  • Developing a security architecture should also result in a list of opportunities (i.e. initiatives) that an organization can integrate into a roadmap. These initiatives will seek to improve security operations and strengthen the IT department’s understanding of security’s role within the organization.
  • A better understanding of the infrastructure will help to save time on determining the correct technologies required from vendors, and therefore, cut down on the amount of vendor noise.
  • Creating a defensible roadmap will assist with justifying future security spend.

Key deliverable:

Solution Architecture Template
Record the results from the exercises to help you define, detail, and make real your digital product vision.

Blueprint Deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

This image contains screenshots of the deliverables which will be discussed later in this blueprint

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.

Guided Implementation

Our team knows that we need to fix a process, but we need assistance to determine where to focus. some check-ins along the way would help keep us on track

Workshop

We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place

Consulting

Our team does not have the time or the knowledge to take this project on. we need assistance through the entirety of this project.

Diagnostics and consistent frameworks are used throughout all four options

Workshop Overview

Contact your account representative for more information. workshops@infotech.com 1-888-670-8889

Day 1 Day 2 Day 3 Day 4
Exercises
  1. Articulate an architectural vision
  2. Develop dynamic value stream maps
  1. Create a conceptual map between the value stream, use case, and required architectural attribute
  2. Create a prioritized list of architectural attributes
  3. Develop a data architecture that supports transactional and analytical needs
  1. Document security architecture risks and mitigations
  2. Document scalability architecture
  1. Document performance-enhancing architecture
  2. Bring it all together
Outcomes
  1. Architecture vision
  2. Dynamic value stream maps (including user stories/personas)
  1. List of required architectural attributes
  2. Architectural attributes prioritized
  3. Data architecture design decisions
  1. Security threat and risk analysis
  2. Security design decisions
  3. Scalability design decisions
  1. Performance design decisions
  2. Finalized decisions

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is series of calls with an Info-Tech analyst to help implement our best practices in your organization.
This GI is between 8 to 10 calls over the course of approximately four to six months.

Phase 1 Phase 2 Phase 2
Call #1:
Articulate an architectural vision.
Call #4:
Continue discussion on value stream mapping and related use cases.
Call #6:
Document security design decisions.
Call #2:
Discuss value stream mapping and related use cases.
Call #5:
  • Map the value streams to required architectural attribute.
  • Create a prioritized list of architectural attributes.
Call #7:
  • Document scalability design decisions.
  • Document performance design decisions.
Call #3:
Continue discussion on value stream mapping and related use cases.
Call #8:
Bring it all together.

Phase 1: Visions and Value Maps

Phase 1

1.1 Articulate an Architectural Vision
1.2 Develop Dynamic Value Stream Maps
1.3 Map Value Streams, Use Cases, and Required Architectural Attributes
1.4 Create a Prioritized List of Architectural Attributes

Phase 2

2.1 Develop a Data Architecture That Supports Transactional and Analytical Needs
2.2 Document Security Architecture Risks and Mitigations

Phase 3

3.1 Document Scalability Architecture
3.2 Document Performance Enhancing Architecture
3.3 Combine the Different Architecture Design Decisions Into a Unified Solution Architecture

This phase will walk you through the following activities:

  • Determine a vision for architecture outcomes
  • Draw dynamic value stream maps
  • Derive architectural design decisions
  • Prioritize design decisions

This phase involves the following participants:

  • Business Architect
  • Product Owner
  • Application Architect
  • Integration Architect
  • Database Architect
  • Enterprise Architect

Enhance Your Solution Architecture Practice

Let’s get this straight: You need an architectural vision

If you start off by saying I want to architect a system, you’ve already lost. Remember what a vision is for!

An architectural vision...

… is your North Star

Your product vision serves as the single fixed point for product development and delivery.

… aligns stakeholders

It gets everyone on the same page.

… helps focus on meaningful work

There is no pride in being a rudderless ship. It can also be very expensive.

And eventually...

… kick-starts your strategy

We know where to go, we know who to bring along, and we know the steps to get there. Let’s plan this out.

An architectural vision is multi-dimensional

Who is the target customer (or customers)?

What is the key benefit a customer can get from using our service or product?

Why should they be engaged with you?

What makes our service or product better than our competitors?

(Adapted from Crossing the Chasm)

Info-Tech Insight

It doesn’t matter if you are delivering value to internal or external stakeholders, you need a product vision to ensure everyone understands the “why.”

Use a canvas as the dashboard for your architecture

The solution architecture canvas provides a single dashboard to quickly define and communicate the most important information about the vision. A canvas is an effective tool for aligning teams and providing an executive summary view.

This image contains a sample canvas for you to use as the dashboard for your architecture. The sections are: Solution Name, Tracking Info, Vision, Business Goals, Metrics, Personas, and Stakeholders.

Leverage the solution architecture canvas to state and inform your architecture vision

This image contains the sample canvas from the previous section, with annotations explaining what to do for each of the headings.

1.1 Craft a vision statement for your solution’s architecture

  1. Use the product canvas template provided for articulating your solution’s architecture.

*If needed, remove or add additional data points to fit your purposes.

There are different statement templates available to help form your product vision statements. Some include:

  • For [our target customer], who [customer’s need], the [product] is a [product category or description] that [unique benefits and selling points]. Unlike [competitors or current methods], our product [main differentiators].
  • We believe (in) a [noun: world, time, state, etc.] where [persona] can [verb: do, make, offer, etc.], for/by/with [benefit/goal].
  • To [verb: empower, unlock, enable, create, etc.] [persona] to [benefit, goal, future state].
  • Our vision is to [verb: build, design, provide] the [goal, future state] to [verb: help, enable, make it easier to...] [persona].

(Adapted from Crossing the Chasm)

Download the Solution Architecture Template and document your vision statement.

Input

  • Business Goals
  • Product Portfolio Vision

Output

  • Solution Architecture Vision

Materials

  • Whiteboard/Flip Charts

Participants

  • Business Architect
  • Product Owner
  • IT Leadership
  • Business Leadership

Solution Architecture Canvas: Refine your vision statement

This image contains a screenshot of the canvas from earlier in the blueprint, with only the annotation for Solution Name: Vision, unique value proposition, elevator pitch, or positioning statement.

Understand your value streams before determining your solution’s architecture

Business Strategy

Sets and communicates the direction of the entire organization.

Value Stream

Segments, groups, and creates a coherent narrative as to how an organization creates value.

Business Capability Map

Decomposes an organization into its component parts to establish a common language across the organization.

Execution

Implements the business strategy through capability building or improvement projects.

Identify your organization’s goals and define the value streams that support them

Goal

Revenue Growth

Value Streams

Stream 1- Product Purchase
Stream 2- Customer Acquisition
stream 3- Product Financing

There are many techniques that help with constructing value streams and their capabilities.

Domain-driven design is a technique that can be used for hypothesizing the value maps, their capabilities, and associated solution architecture.

Read more about domain-driven design here.

Value streams can be external (deliver value to customers) or internal (support operations)

    External Perspective

  1. Core value streams are mostly externally facing: they deliver value to either an external/internal customer and they tie to the customer perspective of the strategy map.
    • E.g. customer acquisition, product purchase, product delivery

    Internal Perspective

  2. Support value streams are internally facing: they provide the foundational support for an organization to operate.
    • E.g. employee recruitment to retirement

Key Questions to Ask While Evaluating Value Streams

  • Who are your customers?
  • What benefits do we deliver to them?
  • How do we deliver those benefits?
  • How does the customer receive the benefits?
This image contains an example of value streams. The main headings are: Customer Acquisitions, Product Purchase, Product Delivery, Confirm Order, Product Financing, and Product Release.

Value streams highlight the what, not the how

Value chains set a high-level context, but architectural decisions still need to be made to deal with the dynamism of user interaction and their subsequent expectations. User stories (and/or use cases) and themes are great tools for developing such decisions.

Product Delivery

  1. Order Confirmation
  2. Order Dispatching
  3. Warehouse Management
  4. Fill Order
  5. Ship Order
  6. Deliver Order

Use Case and User Story Theme: Confirm Order

This image shows the relationship between confirming the customer's order online, and the Online Buyer, the Online Catalog, the Integrated Payment, and the Inventory Lookup.

The use case Confirming Customer’s Online Order has four actors:

  1. An Online Buyer who should be provided with a catalog of products to purchase from.
  2. An Online Catalog that is invoked to display its contents on demand.
  3. An Integrated Payment system for accepting an online form of payment (credit card, Bitcoins, etc.) in a secure transaction.
  4. An Inventory Lookup module that confirms there is stock available to satisfy the Online Buyer’s order.

Info-Tech Insight

Each use case theme links back to a feature(s) in the product backlog.

Related Research

Deliver on Your Digital Portfolio Vision

  • Recognize that a vision is only as good as the data that backs it up. Lay out a comprehensive backlog with quality built in that can be effectively communicated and understood through roadmaps.
  • Your intent is only a dream if it cannot be implemented – define what goes into a release plan via the release canvas.
  • Define a communication approach that lets everyone know where you are heading.

Document Your Business Architecture

  • Recognize the opportunity for architecture work, analyze the current and target states of your business strategy, and identify and engage the right stakeholders.
  • Model the business in the form of architectural blueprints.
  • Apply business architecture techniques such as strategy maps, value streams, and business capability maps to design usable and accurate blueprints of the business.
  • Drive business architecture forward to promote real value to the organization.
  • Assess your current projects to determine if you are investing in the right capabilities. Conduct business capability assessments to identify opportunities and to prioritize projects.

1.2 Document dynamic value stream maps

  1. Create value stream maps that support your business objectives.
    • The value stream maps could belong to existing or new business objectives.
  2. For each value stream map:
    • Determine use case(s), the actors, and their expected activity.

*Refer to the next slide for an example of a dynamic value stream map.

Download the Solution Architecture Template for documentation of dynamic value stream map

Input

  • Business Goals
  • Some or All Existing Business Processes
  • Some or All Proposed New Business Processes

Output

  • Dynamic Value Stream Maps for Multiple Use Roles and Use Cases

Materials

  • Whiteboard/Flip Charts

Participants

  • Business Architect
  • Product Owner
  • Application Architect
  • Integration Architect

Example: Dynamic value stream map

Loan Provision*

*Value Stream Name: Usually has the same name as the capability it illustrates.

Loan Application**; Disbursement of Fund**; Risk Management**; Service Accounts**

**Value Stream Components: Specific functions that support the successful delivery of a value stream.

Disbursement of Funds

This image shows the relationship between depositing the load into the applicant's bank account, and the Applicant's bank, the Loan Applicant, and the Loan Supplier.

Style #1:

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.
  3. The Applicant’s Bank that has an account into which the funds are deposited.

Style # 2:

Loan Provision: Disbursement of Funds
Use Case Actors Expectation
Deposit Loan Into Applicant’s Bank Account
  1. Loan Applicant
  2. Loan Supplier
  3. Applicant’s Bank
  1. Should be able to see deposit in bank account
  2. Deposit funds into account
  3. Accept funds into account

Mid-Phase 1 Checkpoint

By now, the following items are ideally completed:

  • Mid-Phase 1 Checkpoint

Start with an investigation of your architecture’s qualitative needs

Quality attributes can be viewed as the -ilities (e.g. scalability, usability, reliability) that a software system needs to provide. A system not meeting any of its quality attribute requirements will likely not function as required. Examples of quality attributes are:

  1. Slow system response time
  2. Security breaches that result in loss of personal data
  3. A product feature upgrade that is not compatible with previous versions
Examples of Qualitative Attributes
Performance Compatibility Usability Reliability Security Maintainability
  • Response Time
  • Resource Utilization
  • System Capacity
  • Interoperability
  • Accessibility
  • User Interface
  • Intuitiveness
  • Availability
  • Fault Tolerance
  • Recoverability
  • Integrity
  • Non-Repudiation
  • Modularity
  • Reusability
  • Modifiability
  • Testability

Focus on quality attributes that are architecturally significant.

  • Not every system requires every quality attribute.
  • Pay attention to those attributes without which the solution will not be able to satisfy a user’s abstract* expectation.
  • This set can be considered Architecturally Significant Requirements (ASR). ASR concern scenarios have the most impact on the architecture of the software system.
  • ASR are fundamental needs of the system and changing them in the future can be a costly and difficult exercise.

*Abstract since attributes like performance and reliability are not directly measurable by a user.

Stimulus Response Measurement Environmental Context

For applicable use cases: (*Adapted from S Carnegie Mellon University, 2000)

  1. Determine the Stimulus (temporal, external, or internal) that puts stress on the system. For example, a VPN-accessed hospital management system is used for nurses to login at 8am every weekday.
  2. Describe how the system should Respond to the stimulus. For example, the hospital management system should complete a nurse login under 10ms on initiation of the HTTPS request.
  3. Set a Measurement criteria for determining the success of the response to the stimulus. For example, the system should be able to successfully respond to 98% of the HTTPS requests the first time.
  4. Note the environmental context under which the stimulus occurs, including any unusual conditions in effect.
    • The hospital management system needs to respond in under 10ms under typical load or peak load?
    • What is the time variance of peak loads, for example, an e-commerce system during a Black Friday sale?
    • How big is the peak load?

Info-Tech Insight

Three out of four is bad. Don’t architect for normal situations because the solution will be fragile and prone to catastrophic failure under unexpected events.
Read article: Retail sites crash under weight of online Black Friday shoppers.

Discover and evaluate the qualitative attributes needed for use cases or user stories

Deposit Loan Into Applicant’s Bank Account

Assume analysis is being done for a to-be developed system.

User Loan Applicant
Expectations On login to the web system, should be able to see accurate bank balance after loan funds are deposited.
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:
  • Response in 10ms or less
  • Data should not be stale
Under Peak Loads:
  • Response in 15ms or less
  • Data should not be stale
Quality Attribute Required Required Attribute # 1: Performance
  • Design Decision: Reduce latency by placing authorization components closer to user’s location.
Required Attribute # 2: Data Reliability
  • Design Decision: Use event-driven ETL pipelines.
Required Attribute # 3: Scalability
  • Design Decision: Following Principle # 4 of the CSA (JIT Architecture), delay decision until necessary.

Use cases developed in Phase 1.2 should be used here. (Adapted from the ATAM Utility Tree Method for Quality Attribute Engineering)

Reduce technical debt while you are at it

Deposit Loan Into Applicant’s Bank Account

Assume analysis is being done for a to-be developed system.

UserLoan Applicant
ExpectationsOn login to the web system, should be able to see accurate bank balance after loan funds are deposited.
User signs into the online portal and opens their account balance page.
Expected Response From SystemSystem creates a connection to the data source and renders it on the screen in under 10ms.
MeasurementUnder Normal Loads:
  • Response in 10ms or less
  • Data should not be stale
Under Peak Loads:
  • Response in 15ms or less
  • Data should not be stale
Quality Attribute RequiredRequired Attribute # 1: Performance
  • Design Decision: Reduce latency by placing authorization components closer to user’s location.

Required Attribute # 2: Data Reliability

  • Expected is 15ms or less under peak loads, but average latency is 21ms.
  • Design Decision: Use event-driven ETL pipelines.

Required Attribute # 3: Scalability

  • Data should not be stale and should sync instantaneously, but in some zip codes data synchronization is taking 8 hours.
  • Design Decision: Investigate integrations and flows across application, database, and infrastructure. (Note: A dedicated section for discussing scalability is presented in Phase 2.)

1.3 Create a conceptual map between the value streams, use cases, and required architectural attributes

  1. For selected use cases completed in Phase 1.2:
    • Map the value stream to its associated use cases.
    • For each use case, list the required architectural quality attributes.

Download the Solution Architecture Template for mapping value stream components to their required architectural attribute.

Input

  • Use Cases
  • User Roles
  • Stimulus to System
  • Response From System
  • Response Measurement

Output

  • List of Architectural Quality Attributes

Materials

  • Whiteboard/Flip Charts

Participants

  • Business Architect
  • Application Architect
  • Integration Architect
  • Database Architect
  • Infrastructure Architect

Example for Phase 1.3

Loan Provision

Loan Application → Disbursement of Funds → Risk Management → Service Accounts

Value Stream Component Use Case Required Architectural Attribute
Loan Application UC1: Submit Loan Application
UC2: Review Loan Application
UC3: Approve Loan Application
UCn: ……..
UC1: Resilience, Data Reliability
UC2: Data Reliability
UC3: Scalability, Security, Performance
UCn: …..
Disbursement of Funds UC1: Deposit Funds Into Applicant’s Bank Account
UCn: ……..
UC1: Performance, Scalability, Data Reliability
Risk Management ….. …..
Service Accounts ….. …..

Prioritize architectural quality attributes to ensure a right-engineered solution

Trade-offs are inherent in solution architecture. Scaling systems may impact performance and weaken security, while fault-tolerance and redundancy may improve availability but at higher than desired costs. In the end, the best solution is not always perfect, but balanced and right-engineered (versus over- or under-engineered).

Loan Provision

Loan Application → Disbursement of Funds → Risk Management → Service Accounts

  1. Map architecture attributes against the value stream components.
    • Use individual use cases to determine which attributes are needed for a value stream component.
This image contains a screenshot of the table showing the importance of scalability, resiliance, performance, security, and data reliability for loan application, disbursement of funds, risk management, and service accounts.

In our example, the prioritized list of architectural attributes are:

  • Security (4 votes for Very Important)
  • Data Reliability (2 votes for Very Important)
  • Scalability (1 vote for Very Important and 1 vote for Fairly Important) and finally
  • Resilience (1 vote for Very Important, 0 votes for Fairly Important and 1 vote for Mildly Important)
  • Performance (0 votes for Very Important, 2 votes for Fairly Important)

1.4 Create a prioritized list of architectural attributes (from 1.3)

  1. Using the tabular structure shown on the previous slide:
    • Map each value stream component against architectural quality attributes.
    • For each mapping, indicate its importance using the green, blue, and yellow color scheme.

Download the Solution Architecture Template and document the list of architectural attributes by priority.

Input

  • List of Architectural Attributes From 1.3

Output

  • Prioritized List of Architectural Attributes

Materials

  • Whiteboard/Flip Charts

Participants

  • Business Architect
  • Application Architect
  • Integration Architect
  • Database Architect
  • Infrastructure Architect

End of Phase 1

At the end of this Phase, you should have completed the following activities:

  • Documented a set of dynamic value stream maps along with selected use cases.
  • Using the SRME framework, identified quality attributes for the system under investigation.
  • Prioritized quality attributes for system use cases.

Phase 2: Multi-Purpose Data and Security Architecture

Phase 1

1.1 Articulate an Architectural Vision
1.2 Develop Dynamic Value Stream Maps
1.3 Map Value Streams, Use Cases, and Required Architectural Attributes
1.4 Create a Prioritized List of Architectural Attributes

Phase 2

2.1 Develop a Data Architecture That Supports Transactional and Analytical Needs
2.2 Document Security Architecture Risks and Mitigations

Phase 3

3.1 Document Scalability Architecture
3.2 Document Performance Enhancing Architecture
3.3 Combine the Different Architecture Design Decisions Into a Unified Solution Architecture

This phase will walk you through the following activities:

  • Understand the scalability, performance, resilience, and security needs of the business.

This phase involves the following participants:

  • Business Architect
  • Product Owner
  • Application Architect
  • Integration Architect
  • Database Architect
  • Enterprise Architect

Enhance Your Solution Architecture Practice

Fragmented data environments need something to sew them together

  • A full 93% of enterprises have a multi-cloud strategy, with 87% having a hybrid-cloud environment in place.
  • On average, companies have data stored in 2.2 public and 2.2 private clouds as well as in various on-premises data repositories.
This image contains a breakdown of the cloud infrastructure, including single cloud versus multi-cloud.

Source: Flexera

In addition, companies are faced with:

  • Access and integration challenges (Who is sending the data? Who is getting it? Can we trust them?)
  • Data format challenges as data may differ for each consumer and sender of data
  • Infrastructure challenges as data repositories/processors are spread out over public and private clouds, are on premises, or in multi-cloud and hybrid ecosystems
  • Structured vs. unstructured data

A robust and reliable integrated data architecture is essential for any organization that aspires to be relevant and impactful in its industry.

Data’s context and influence on a solution’s architecture cannot be overestimated

Data used to be the new oil. Now it’s the life force of any organization that has serious aspirations of providing profit-generating products and services to customers. Architectural decisions about managing data have a significant impact on the sustainability of a software system as well as on quality attributes such as security, scalability, performance, and availability.

Storage and Processing go hand in hand and are the mainstay of any data architecture. Due to their central position of importance, an architecture decision for storage and processing must be well thought through or they become the bottleneck in an otherwise sound system.

Ingestion refers to a system’s ability to accept data as an input from heterogenous sources, in different formats, and at different intervals.

Dissemination is the set of architectural design decisions that make a system’s data accessible to external consumers. Major concerns involve security for the data in motion, authorization, data format, concurrent requests for data, etc.

Orchestration takes care of ensuring data is current and reliable, especially for systems that are decentralized and distributed.

Data architecture requires alignment with a hybrid data management plan

Most companies have a combination of data. They have data they own using on-premises data sources and on the cloud. Hybrid data management also includes external data, such as social network feeds, financial data, and legal information amongst many others.

Data integration architectures have typically been put in one of two major integration patterns:

Application to Application Integration (or “speed matters”) Analytical Data Integrations (or “send it to me when its all done”)
  • This domain is concerned with ensuring communication between processes.
  • Examples include patterns such as Service-Oriented Architecture, REST, Event Hubs and Enterprise Service Buses.
  • This domain is focused on integrating data from transactional processes towards enterprise business intelligence. It supports activities that require well-managed data to generate evidence-based insights.
  • Examples of this pattern are ELT, enterprise data warehouses, and data marts.

Sidebar

Difference between real-time, batch, and streaming data movements

Real-Time

  • Reacts to data in seconds or even quicker.
  • Real-time systems are hard to implement.

Batch

  • Batch processing deals with a large volume of data all at once and data-related jobs are typically completed simultaneously in non-stop, sequential order.
  • Batch processing is an efficient and low-cost means of data processing.
  • Execution of batch processing jobs can be controlled manually, providing further control over how the system treats its data assets.
  • Batch processing is only useful if there are no requirements for data to be fresh and current. Real-time systems are suited to processing data that requires these attributes.

Streaming

  • Stream processing allows almost instantaneous analysis of data as it streams from one device to another.
  • Since data is analyzed quickly, storage may not be a concern (since only computed data is stored while raw data can be dispersed).
  • Streaming requires the flow of data into the system to equal the flow of data computing, otherwise issues of data storage and performance can rise.

Modern data ingestion and dissemination frameworks keep core data assets current and accessible

Data ingestion and dissemination frameworks are critical for keeping enterprise data current and relevant.

Data ingestion/dissemination frameworks capture/share data from/to multiple data sources.

Factors to consider when designing a data ingestion/dissemination architecture

What is the mode for data movement?

  • The mode for data movement is directly influenced by the size of data being moved and the downstream requirements for data currency.
  • Data can move in real-time, as a batch, or as a stream.

What is the ingestion/dissemination architecture deployment strategy?

  • Outside of critical security concerns, hosting on the cloud vs. on premises leads to a lower total cost of ownership (TCO) and a higher return on investment (ROI).

How many different and disparate data sources are sending/receiving data?

  • Stability comes if there is a good idea about the data sources/recipient and their requirements.

What are the different formats flowing through?

  • Is the data in the form of data blocks? Is it structured, semi-unstructured, or unstructured?

What are expected performance SLAs as data flow rate changes?

  • Data change rate is defined as the size of changes occurring every hour. It helps in selecting the appropriate tool for data movement.
  • Performance is a derivative of latency and throughput, and therefore, data on a cloud is going to have higher latency and lower throughput then if it is kept on premises.
  • What is the transfer data size? Are there any file compression and/or file splits applied on the data? What is the average and maximum size of a block object per ingestion/dissemination operation?

What are the security requirements for the data being stored?

  • The ingestion/dissemination framework should be able to work through a secure tunnel to collect/share data if needed.

Sensible storage and processing strategy can improve performance and scalability and be cost-effective

The range of options for data storage is staggering...

… but that’s a good thing because the range of data formats that organizations must deal with is also richer than in the past.

Different strokes for different workloads.

The data processing tool to use may depend upon the workloads the system has to manage.

Expanding upon the Risk Management use case (as part of the Loan Provision Capability), one of the outputs for risk assessment is a report that conducts a statistical analysis of customer profiles and separates those that are possibly risky. The data for this report is spread out across different data systems and will need to be collected in a master data management storage location. The business and data architecture team have discussed three critical system needs, noted below:

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
Needs turnkey geo-replication mechanism with document retrieval in milliseconds
  • Add NoSQL with geo-replication and quick document access

Keep every core data source on the same page through orchestration

Data orchestration, at its simplest, is the combination of data integration, data processing, and data concurrency management.

Data pipeline orchestration is a cross-cutting process that manages the dependencies between your data integration tasks and scheduled data jobs.

A task or application may periodically fail, and therefore, as a part of our data architecture strategy, there must be provisions for scheduling, rescheduling, replaying, monitoring, retrying, and debugging the entire data pipeline in a holistic way.

Some of the functionality provided by orchestration frameworks are:

  • Job scheduling
  • Job parametrization
  • SLAs tracking, alerting, and notification
  • Dependency management
  • Error management and retries
  • History and audit
  • Data storage for metadata
  • Log aggregation
Data Orchestration Has Three Stages
Organize Transform Publicize
Organizations may have legacy data that needs to be combined with new data. It’s important for the orchestration tool to understand the data it deals with. Transform the data from different sources into one standard type. Make transformed data easily accessible to stakeholders.

2.1 Discuss and document data architecture decisions

  1. Using the value maps and associated use cases from Phase 1, determine the data system quality attributes.
  2. Use the sample tabular layout on the next slide or develop one of your own.

Download the Solution Architecture Template for documenting data architecture decisions.

Input

  • Value Maps and Use Cases

Output

  • Initial Set of Data Design Decisions

Materials

  • Whiteboard/Flip Charts

Participants

  • Business Architect
  • Application Architect
  • Integration Architect
  • Database Architect
  • Infrastructure Architect

Example: Data Architecture

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
Needs turnkey geo-replication mechanism with document retrieval in milliseconds
  • Add NoSQL with geo-replication and quick document access

There is no free lunch when making the most sensible security architecture decision; tradeoffs are a necessity

Ensuring that any real system is secure is a complex process involving tradeoffs against other important quality attributes (such as performance and usability). When architecting a system, we must understand:

  • Its security needs.
  • Its security threat landscape.
  • Known mitigations for those threats to ensure that we create a system with sound security fundamentals.

The first thing to do when determining security architecture is to conduct a threat and risk assessment (TRA).

This image contains a sample threat and risk assessment. The steps are Understand: Until we thoroughly understand what we are building, we cannot secure it. Structure what you are building, including: System boundary, System structure, Databases, Deployment platform; Analyze: Use techniques like STRIDE and attack trees to analyze what can go wrong and what security problems this will cause; Mitigate: The security technologies to use, to mitigate your concerns, are discussed here. Decisions about using single sign-on (SSO) or role-based access control (RBAC), encryption, digital signatures, or JWT tokens are made. An important part of this step is to consider tradeoffs when implementing security mechanisms; validate: Validation can be done by experimenting with proposed mitigations, peer discussion, or expert interviews.

Related Research

Optimize Security Mitigation Effectiveness Using STRIDE

  • Have a clear picture of:
    • Critical data and data flows
    • Organizational threat exposure
    • Security countermeasure deployment and coverage
  • Understand which threats are appropriately mitigated and which are not.
  • Generate a list of initiatives to close security gaps.
  • Create a quantified risk and security model to reassess program and track improvement.
  • Develop measurable information to present to stakeholders.

The 3A’s of strong security: authentication, authorization, and auditing

Authentication

Authentication mechanisms help systems verify that a user is who they claim to be.

Examples of authentication mechanisms are:

  • Two-Factor Authentication
  • Single Sign-On
  • Multi-Factor Authentication
  • JWT Over OAUTH

Authorization

Authorization helps systems limit access to allowed features, once a user has been authenticated.

Examples of authentication mechanisms are:

  • RBAC
  • Certificate Based
  • Token Based

Auditing

Securely recording security events through auditing proves that our security mechanisms are working as intended.

Auditing is a function where security teams must collaborate with software engineers early and often to ensure the right kind of audit logs are being captured and recorded.

Info-Tech Insight

Defects in your application software can compromise privacy and integrity even if cryptographic controls are in place. A security architecture made after thorough TRA does not override security risk introduced due to irresponsible software design.

Examples of threat and risk assessments using STRIDE and attack trees

STRIDE is a threat modeling framework and is composed of:

  • Spoofing or impersonation of someone other than oneself
  • Tampering with data and destroying its integrity
  • Repudiation by bypassing system identity controls
  • Information disclosure to unauthorized persons
  • Denial of service that prevents system or parts of it from being used
  • Elevation of privilege so that attackers get rights they should not have
Example of using STRIDE for a TRA on a solution using a payment system This image contains a sample attack tree.
Spoofing PayPal Bad actor can send fraudulent payment request for obtaining funds.
Tampering PayPal Bad actor accesses data base and can resend fraudulent payment request for obtaining funds.
Repudiation PayPal Customer claims, incorrectly, their account made a payment they did not authorize.
Disclosure PayPal Private service database has details leaked and made public.
Denial of Service PayPal Service is made to slow down through creating a load on the network, causing massive build up of requests
Elevation of Privilege PayPal Bad actor attempts to enter someone else’s account by entering incorrect password a number of times.

2.2 Document security architecture risks and mitigations

  1. Using STRIDE, attack tree, or any other framework of choice:
    • Conduct a TRA for use cases identified in Phase 1.2
  2. For each threat identified through the TRA, think through the implications of using authentication, authorization, and auditing as a security mechanism.

Download the Solution Architecture Template for documenting data architecture decisions.

Input

  • Dynamic Value Stream Maps

Output

  • Security Architecture Risks and Mitigations

Materials

  • Whiteboard/Flip Charts

Participants

  • Business Architect
  • Product Owner
  • Security Team
  • Application Architect
  • Integration Architect

Examples of threat and risk assessments using STRIDE

Example of using STRIDE for a TRA on a solution 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 PayPal Bad actor accesses data base and can resend fraudulent payment request for obtaining funds. Integrity Authorization
Repudiation PayPal Customer claims, incorrectly, their account made a payment they did not authorize. Integrity Authentication and Logging
Disclosure PayPal Private service database has details leaked and made public. Confidentiality Authorization
Denial of Service PayPal Service is made to slow down through creating a load on the network, causing massive build up of requests Availability N/A
Elevation of Privilege PayPal Bad actor attempts to enter someone else’s account by entering incorrect password a number of times. Confidentiality, Integrity, and Availability Authorization

Phase 3: Upgrade Your System’s Availability

Phase 1

1.1 Articulate an Architectural Vision
1.2 Develop Dynamic Value Stream Maps
1.3 Map Value Streams, Use Cases, and Required Architectural Attributes
1.4 Create a Prioritized List of Architectural Attributes

Phase 2

2.1 Develop a Data Architecture That Supports Transactional and Analytical Needs
2.2 Document Security Architecture Risks and Mitigations

Phase 3

3.1 Document Scalability Architecture
3.2 Document Performance Enhancing Architecture
3.3 Combine the Different Architecture Design Decisions Into a Unified Solution Architecture

This phase will walk you through the following activities:

  • Examine architecture for scalable and performant system designs
  • Integrate all design decisions made so far into a solution design decision log

This phase involves the following participants:

  • Business Architect
  • Product Owner
  • Application Architect
  • Integration Architect
  • Database Architect
  • Enterprise Architect

Enhance Your Solution Architecture Practice

In a cloud-inspired system architecture, scalability takes center stage as an architectural concern

Scale and scope of workloads are more important now than they were, perhaps, a decade and half back. Architects realize that scalability is not an afterthought. Not dealing with it at the outset can have serious consequences should an application workload suddenly exceed expectations.

Scalability is …

… the ability of a system to handle varying workloads by either increasing or decreasing the computing resources of the system.

An increased workload could include:

  • Higher transaction volumes
  • A greater number of users

Architecting for scalability is …

… not easy since organizations may not be able to accurately judge, outside of known circumstances, when and why workloads may unexpectedly increase.

A scalable architecture should be planned at the:

  • Application Level
  • Infrastructure Level
  • Database Level

The right amount and kind of scalability is …

… balancing the demands of the system with the supply of attributes.

If demand from system > supply from system:

  • Services and products are not useable and deny value to customers.

If supply from system > demand from system:

  • Excess resources have been paid for that are not being used.

When discussing the scalability needs of a system, investigate the following, at a minimum:

  • In case workloads increase due to higher transaction volumes, will the system be able to cope with the additional stress?
  • In situations where workloads increase, will the system be able to support the additional stress without any major modifications being made to the system?
  • Is the cost associated with handling the increased workloads reasonable for the benefit it provides to the business?
  • Assuming the system doesn’t scale, is there any mechanism for graceful degradation?

Use evidence-based decision making to ensure a cost-effective yet appropriate scaling strategy

The best input for an effective scaling strategy is previously gathered traffic data mapped to specific circumstances.

In some cases, either due to lack of monitoring or the business not being sure of its needs, scalability requirements are hard to determine. In such cases, use stated tactical business objectives to design for scalability. For example, the business might state its desire to achieve a target revenue goal. To accommodate this, a certain number of transactions would need to be conducted, assuming a particular conversion rate.

Scaling strategies can be based on Vertical or Horizontal expansion of resources.
Pros Cons
Vertical
Scale up through use of more powerful but limited number of resources
  • May not require frequent upgrades.
  • Since data is managed through a limited number of resources, it is easier to share and keep current.
  • Costly upfront.
  • Application, database, and infrastructure may not be able to make optimal use of extra processing power.
  • As the new, more powerful resource is provisioned, systems may experience downtime.
  • Lacks redundancy due to limited points of failure.
  • Performance is constrained by the upper limits of the infrastructure involved.
Horizontal
Scale out through use of similarly powered but larger quantity of resources
  • Cost-effective upfront.
  • System downtime is minimal, when scaling is being performed.
  • More redundance and fault-tolerance is possible since there are many nodes involved, and therefore, can replace failed nodes.
  • Performance can scale out as more nodes are added.
  • Upgrades may occur more often than in vertical scaling.
  • Increases machine footprints and administrative costs over time.
  • Data may be partitioned on multiple nodes, leading to administrative and data currency challenges.

Info-Tech Insight

  • Scalability is the one attribute that sparks a lot of trade-off discussions. Scalable solutions may have to compromise on performance, cost, and data reliability.
  • Horizontal scalability is mostly always preferable over vertical scalability.

Sidebar

The many flavors of horizontal scaling

Traffic Shard-ing

Through this mechanism, incoming traffic is partitioned around a characteristic of the workload flowing in. Examples of partitioning characteristics are user groups, geo-location, and transaction type.

Beware of:

  • Lack of data currency across shards.

Copy and Paste

As the name suggests, clone the compute resources along with the underlying databases. The systems will use a load balancer as the first point of contact between itself and the workload flowing in.

Beware of:

  • Though this is a highly scalable model, it does introduce risks related to data currency across all databases.
  • In case master database writes are frequent, it could become a bottleneck for the entire system.

Productization Through Containers

This involves breaking up the system into specific functions and services and bundling their business rules/databases into deployable containers.

Beware of:

  • Too many containers introduce the need to orchestrate the distributed architecture that results from a service-oriented approach.

Start a scalability overview with a look at the database(s)

To know where to go, you must know where you are. Before introducing architectural changes to database designs, use the right metrics to get an insight into the root cause of the problem(s).

In a nutshell, the purpose of scaling solutions is to have the technology stack do less work for the most requested services/features or be able to effectively distribute the additional workload across multiple resources.

For databases, to ensure this happens, consider these techniques:

  • Reuse data through caching on the server and/or the client. This eliminates the need for looking up already accessed data. Examples of caching are:
    • In-memory caching of data
    • Caching database queries
  • Implement good data retrieval techniques like indexes.
  • Divide labor at the database level.
    • Through setting up primary-secondary distribution of data. In such a setup, the primary node is involved in writing data to itself and passes on requests to secondary nodes for fulfillment.
    • Through setting up database shards (either horizontally or vertically).
      • In a horizontal shard, a data table is broken into smaller pieces with the same data model but unique data in it. The sum total of the shared databases contains all the data in the primary data table.
      • In a vertical shard, a data table is broken into smaller pieces, but each piece may have a subset of the data columns. The data’s corresponding columns are put into the table where the column resides.

Info-Tech Insight

A non-scalable architecture has more than just technology-related ramifications. Hoping that load balancers or cloud services will manage scalability-related issues is bound to have economic impacts as well.

Sidebar

Caching Options

CSA PRINCIPLE 5 applies to any decision that supports system scalability.
“X-ilities Over Features”

Database Caching
Fetches and stores result of database queries in memory. Subsequent requests to the database for the same queries will investigate the cache before making a connection with the database.
Tools like Memcached or Redis are used for database caching.

Precompute Database Caching
Unlike database caching, this style of caching precomputes results of queries that are popular and frequently used. For example, a database trigger could execute several predetermined queries and have them ready for consumption. The precomputed results may be stored in a database cache.

Application Object Caching
Stores computed results in a cache for later retrieval. For data sources, which are not changing frequently and are part of a computation output, application caching will remove the need to connect with a database.

Proxy Caching
Caches retrieved web pages on a proxy server and makes them available for the next time the page is requested.

The intra- and inter-process communication of the systems middle tier can become a bottleneck

To synchronize or not to synchronize?

A synchronous request (doing one thing at a time) means that code execution will wait for the request to be responded to before continuing.

  • A synchronous request is a blocking event and until it is completed, all following requests will have to wait for getting their responses.
  • An increasing workload on a synchronous system may impact performance.
  • Synchronous interactions are less costly in terms of design, implementation, and maintenance.
  • Scaling options include:
    1. Vertical scale up
    2. Horizontal scale out of application servers behind a load balancer and a caching technique (to minimize data retrieval roundtrips)
    3. Horizonal scale out of database servers with data partitioning and/or data caching technique

Use synchronous requests when…

  • Each request to a system sets the necessary precondition for a following request.
  • Data reliability is important, especially in real-time systems.
  • System flows are simple.
  • Tasks that are typically time consuming, such as I/O, data access, pre-loading of assets, are completed quickly.

Asynchronous requests (doing many things at the same time) do not block the system they are targeting.

  • It is a “fire and forget” mechanism.
  • Execution on a server/processor is triggered by the request, however, additional technical components (callbacks) for checking the state of the execution must be designed and implemented.
  • Asynchronous interactions require additional time to be spent on implementation and testing.
  • With asynchronous interactions, there is no guarantee the request initiated any processing until the callbacks check the status of the executed thread.

Use asynchronous requests when…

  • Tasks are independent in nature and don’t require inter-task communication.
  • Systems flows need to be efficient.
  • The system is using event-driven techniques for processing.
  • Many I/O tasks are involved.
  • The tasks are long running.

Sidebar

Other architectural tactics for inter-process communication

STATELESS SERVICES VERSUS STATEFUL SERVICES
  • Does not require any additional data, apart from the bits sent through with the request.
  • Without implementing a caching solution, it is impossible to access the previous data trail for a transaction session.
  • In addition to the data sent through with the request, require previous data sent to complete processing.
  • Requires server memory to store the additional state data. With increasing workloads, this could start impacting the server’s performance.
It is generally accepted that stateless services are better for system scalability, especially if vertical scaling is costly and there is expectation that workloads will increase.
MICROSERVICES VERSUS SERVERLESS FUNCTIONS
  • Services are designed as small units of code with a single responsibility and are available on demand.
  • A microservices architecture is easily scaled horizontally by adding a load balancer and a caching mechanism.
  • Like microservices, these are small pieces of code designed to fulfill a single purpose.
  • Are provided only through cloud vendors, and therefore, there is no need to worry about provisioning of infrastructure as needs increase.
  • Stateless by design but the life cycle of a serverless function is vendor controlled.
Serverless function is an evolving technology and tightly controlled by the vendor. As and when vendors make changes to their serverless products, your own systems may need to be modified to make the best use of these upgrades.

A team that does not measure their system’s scalability is a team bound to get a 5xx HTTP response code

A critical aspect of any system is its ability to monitor and report on its operational outcomes.

  • Using the principle of continuous testing, every time an architectural change is introduced, a thorough load and stress testing cycle should be executed.
  • Effective logging and use of insightful metrics helps system design teams make data-driven decisions.
  • Using principle of site reliability engineering and predictive analytics, teams can be prepared for any unplanned exaggerated stimulus on the system and proactively set up remedial steps.

Any system, however well architected, will break one day. Strategically place kill-switches to counter any failures and thoroughly test their functioning before releasing to production.

  • Using Principles 2 and 9 of the CSA, (include kill-switches and architect for x-ilities over features), introduce tactics at the code and higher levels that can be used to put a system in its previous best state in case of failure.
  • Examples of such tactics are:
    • Feature flags for turning on/off code modules that impact x-ilities.
    • Implement design patterns like throttling, autoscaling, and circuit breaking.
    • Writing extensive log messages that bubble up as exceptions/error handling from the code base. *Logging can be a performance drag. Use with caution as even logging code is still code that needs CPU and data storage.

Performance is a system’s ability to satisfy time-bound expectations

Performance can also be defined as the ability for a system to achieve its timing requirements, using available resources, under expected full-peak load:

(International Organization for Standardization, 2011)

  • Performance and scalability are two peas in a pod. They are related to each other but are distinct attributes. Where scalability refers to the ability of a system to initiate multiple simultaneous processes, performance is the system’s ability to complete the processes within a mandated average time period.
  • Degrading performance is one of the first red flags about a system’s ability to scale up to workload demands.
  • Mitigation tactics for performance are very similar to the tactics for scalability.

System performance needs to be monitored and measured consistently.

Measurement Category 1: System performance in terms of end-user experience during different load scenarios.

  • Response time/latency: Length of time it takes for an interaction with the system to complete.
  • Turnaround time: Time taken to complete a batch of tasks.
  • Throughput: Amount of workload a system is capable of handling in a unit time period.

Measurement Category 2: System performance in terms of load managed by computational resources.

  • Resource utilization: The average usage of a resource (like CPU) over a period. Peaks and troughs indicate excess vs. normal load times.
  • Number of concurrent connections: Simultaneous user requests that a resource like a server can successfully deal with at once.
  • Queue time: The turnaround time for a specific interaction or category of interactions to complete.

Architectural tactics for performance management are the same as those used for system scalability

Application Layer

  • Using a balanced approach that combines CSA Principle 7 (Good architecture comes in small packages) and Principle 10 (Architect for products, not projects), a microservices architecture based on domain-driven design helps process performance. Microservices use lightweight HTTP protocols and have loose coupling, adding a degree of resilience to the system as well. *An overly-engineered microservices architecture can become an orchestration challenge.
  • The code design must follow standards that support performance. Example of standards is SOLID*.
  • Serverless architectures can run application code from anywhere – for example, from edge servers close to an end user – thereby reducing latency.

Database Layer

  • Using the right database technologies for persistence. Relational databases have implicit performance bottlenecks (which get exaggerated as data size grows along with indexes), and document store database technologies (key-value or wide-column) can improve performance in high-read environments.
  • Data sources, especially those that are frequently accessed, should ideally be located close to the application servers. Hybrid infrastructures (cloud and on premises mixed) can lead to latency when a cloud-application is accessing on-premises data.
  • Using a data partitioning strategy, especially in a domain-driven design architecture, can improve the performance of a system.

Performance modeling and continuous testing makes the SRE a happy engineer

Performance modeling and testing helps architecture teams predict performance risks as the solution is being developed.
(CSA Principle 12: Test the solution architecture like you test your solution’s features)

Create a model for your system’s hypothetical performance testing by breaking an end-to-end process or use case into its components. *Use the SIPOC framework for decomposition.

This image contains an example of modeled performance, showing the latency in the data flowing from different data sources to the processing of the data.

In the hypothetical example of modeled performance above:

  • The longest period of latency is 15ms.
  • The processing of data takes 30ms, while the baseline was established at 25ms.
  • Average latency in sending back user responses is 21ms – 13ms slower than expected.

The model helps architects:

  • Get evidence for their assumptions
  • Quantitatively isolate bottlenecks at a granular level

Model the performance flow once but test it periodically

Performance testing measures the performance of a software system under normal and abnormal loads.

Performance testing process should be fully integrated with software development activities and as automated as possible. In a fast-moving Agile environment, teams should attempt to:

  • Shift-left performance testing activities.
  • Use performance testing to pinpoint performance bottlenecks.
  • Take corrective action, as quickly as possible.

Performance testing techniques

  • Normal load testing: Verifies the system’s behavior under the expected normal load to ensure that its performance requirements are met. Load testing can be used to measure response time, responsiveness, turnaround time, and throughput.
  • Expected maximum load testing: Like the normal load testing process, ensures system meets its performance requirements under expected maximum load.
  • Stress testing: Evaluates system behavior when processing loads beyond the expected maximum.

*In a real production scenario, a combination of these tests are executed on a regular basis to monitor the performance of the system over a given period.

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

  1. Use the outcomes from either or both Phases 1.3 and 1.4.
    • For each value stream component, list the architecture decisions taken to ensure scalability and performance at client-facing and/or business-rule layers.

Download the Solution Architecture Template for documenting data architecture decisions.

Input

  • Output From Phase 1.3 and/or From Phase 1.4

Output

  • Initial Set of Design Decisions Made for System Scalability and Performance

Materials

  • Whiteboard/Flip Charts

Participants

  • Business Architect
  • Application Architect
  • Integration Architect
  • Database Architect
  • Infrastructure Architect

Example: Architecture decisions for scalability and performance

Value Stream Component Design Decision for User Interface Layer Design Decisions for Middle Processing Layer
Loan Application Scalability: N/A
Resilience: Include circuit breaker design in both mobile app and responsive websites.
Performance: Cache data client.
Scalability: Scale vertically (up) since loan application processing is very compute intensive.
Resilience: Set up fail-over replica.
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.
…. …. ….

3.3 Combine the different architecture design decisions into a unified solution architecture

Download the Solution Architecture Template for documenting data architecture decisions.

Input

  • Output From Phase 1.3 and/or From Phase 1.4
  • Output From Phase 2.1
  • Output From Phase 2.2
  • Output From 3.1 and 3.2

Output

  • List of Design Decisions for the Solution

Materials

  • Whiteboard/Flip Charts

Participants

  • Business Architect
  • Application Architect
  • Integration Architect
  • Database Architect
  • Infrastructure Architect

Putting it all together is the bow that finally ties this gift

This blueprint covered the domains tagged with the yellow star.

This image contains a screenshot of the solution architecture framework found earlier in this blueprint, with stars next to Data Architecture, Security, Performance, and Stability.

TRADEOFF ALERT

The right design decision is never the same for all perspectives. Along with varying opinions, comes the “at odds with each other set” of needs (scalability vs. performance, or access vs. security).

An evidence-based decision-making approach using a domain-driven design strategy is a good mix of techniques for creating the best (right?) solution architecture.

This image contains a screenshot of a table that summarizes the themes discussed in this blueprint.

Summary of accomplishment

  • Gained understanding and clarification of the stakeholder objectives placed on your application architecture.
  • Completed detailed use cases and persona-driven scenario analysis and their architectural needs through SRME.
  • Created a set of design decisions for data, security, scalability, and performance.
  • Merged the different architecture domains dealt with in this blueprint to create a holistic view.

Bibliography

Ambysoft Inc. “UML 2 Sequence Diagrams: An Agile Introduction.” Agile Modeling, n.d. Web.

Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practices: Third Edition. Pearson Education, Inc. 2003.

Eeles, Peter. “The benefits of software architecting.” IBM: developerWorks, 15 May 2006. Web.

Flexera 2020 State of the Cloud Report. Flexera, 2020. Web. 19 October 2021.

Furdik, Karol, Gabriel Lukac, Tomas Sabol, and Peter Kostelnik. “The Network Architecture Designed for an Adaptable IoT-based Smart Office Solution.” International Journal of Computer Networks and Communications Security, November 2013. Web.

Ganzinger, Matthias, and Petra Knaup. “Requirements for data integration platforms in biomedical research networks: a reference model.” PeerJ, 5 February 2015. (https://peerj.com/articles/755/).

Garlan, David, and Mary Shaw. An Introduction to Software Architecture. CMU-CS-94-166, School of Computer Science Carnegie Mellon University, January 1994.

Gupta, Arun. “Microservice Design Patterns.” Java Code Geeks, 14 April 2015. Web.

How, Matt. The Modern Data Warehouse in Azure. O’Reilly, 2020.

ISO/IEC 17788:2014: Information technology – Cloud computing, International Organization for Standardization, October 2014. Web.

ISO/IEC 18384-1:2016: Information technology – Reference Architecture for Service Oriented Architecture (SOA RA), International Organization for Standardization, June 2016. Web.

ISO/IEC 25010:2011(en) Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models. International Organization for Standardization, March 2011. Web.

Kazman, R., M. Klein, and P. Clements. ATAM: Method for Architecture Evaluation. S Carnegie Mellon University, August 2000. Web.

Microsoft Developer Network. “Chapter 16: Quality Attributes.” Microsoft Application Architecture Guide. 2nd Ed., 13 January 2010. Web.

Microsoft Developer Network. “Chapter 2: Key Principles of Software Architecture.” Microsoft Application Architecture Guide. 2nd Ed., 13 January 2010. Web.

Microsoft Developer Network. “Chapter 3: Architectural Patterns and Styles.” Microsoft Application Architecture Guide. 2nd Ed., 14 January 2010. Web.

Microsoft Developer Network. “Chapter 5: Layered Application Guidelines.” Microsoft Application Architecture Guide. 2nd Ed., 13 January 2010. Web.

Mirakhorli, Mehdi. “Common Architecture Weakness Enumeration (CAWE).” IEEE Software, 2016. Web.

Moore, G. A. Crossing the Chasm, 3rd Edition: Marketing and Selling Disruptive Products to Mainstream Customers (Collins Business Essentials) (3rd ed.). Harper Business, 2014.

OASIS. “Oasis SOA Reference Model (SOA RM) TC.” OASIS Open, n.d. Web.

Soni, Mukesh. “Defect Prevention: Reducing Costs and Enhancing Quality.” iSixSigma, n.d. Web.

The Open Group. TOGAF 8.1.1 Online, Part IV: Resource Base, Developing Architecture Views. TOGAF, 2006. Web.

The Open Group. Welcome to the TOGAF® Standard, Version 9.2, a standard of The Open Group. TOGAF, 2018. Web.

Watts, S. “The importance of solid design principles.” BMC Blogs, 15 June 2020. 19 October 2021.

Young, Charles. “Hexagonal Architecture–The Great Reconciler?” Geeks with Blogs, 20 Dec 2014. Web.

APPENDIX A

Techniques to enhance application architecture.

Consider the numerous solutions to address architecture issues or how they will impact your application architecture

Many solutions exist for improving the layers of the application stack that may address architecture issues or impact your current architecture. Solutions range from capability changes to full stack replacement.

Method Description Potential Benefits Risks Related Blueprints
Business Capabilities:
Enablement and enhancement
  • Introduce new business capabilities by leveraging unused application functionalities or consolidate redundant business capabilities.
  • Increase value delivery to stakeholders.
  • Lower IT costs through elimination of applications.
  • Increased use of an application could overload current infrastructure.
  • IT cannot authorize business capability changes.
Use Info-Tech’s Document Your Business Architecture blueprint to gain better understanding of business and IT alignment.
Removal
  • Remove existing business capabilities that don’t contribute value to the business.
  • Lower operational costs through elimination of unused and irrelevant capabilities.
  • Business capabilities may be seen as relevant or critical by different stakeholder groups.
  • IT cannot authorize business capability changes.
Use Info-Tech’s Build an Application Rationalization Framework to rationalize your application portfolio.
Business Process:
Process integration and consolidation
  • Combine multiple business processes into a single process.
  • Improved utilization of applications in each step of the process.
  • Reduce business costs through efficient business processes.
  • Minimize number of applications required to execute a single process.
  • Significant business disruption if an application goes down and is the primary support for business processes.
  • Organizational pushback if process integration involves multiple business groups.
Business Process (continued):
Process automation
  • Automate manual business processing tasks.
  • Reduce manual processing errors.
  • Improve speed of delivery.
  • Significant costs to implement automation.
  • Automation payoffs are not immediate.
Lean business processes
  • Eliminate redundant steps.
  • Streamline existing processes by focusing on value-driven steps.
  • Improve efficiency of business process through removal of wasteful steps.
  • Increase value delivered at the end of the process.
  • Stakeholder pushback from consistently changing processes.
  • Investment from business is required to fit documentation to the process.
Outsource the process
  • Outsource a portion of or the entire business process to a third party.
  • Leverage unavailable resources and skills to execute the business process.
  • Loss of control over process.
  • Can be costly to bring the process back into the business if desired in the future.
Business Process (continued):
Standardization
  • Implement standards for business processes to improve uniformity and reusability.
  • Consistently apply the same process across multiple business units.
  • Transparency of what is expected from the process.
  • Improve predictability of process execution.
  • Process bottlenecks may occur if a single group is required to sign off on deliverables.
  • Lack of enforcement and maintenance of standards can lead to chaos if left unchecked.
User Interface:
Improve user experience (UX)
  • Eliminate end-user emotional, mechanical, and functional friction by improving the experience of using the application.
  • UX encompasses both the interface and the user’s behavior.
  • Increase satisfaction and adoption rate from end users.
  • Increase brand awareness and user retention.
  • UX optimizations are only focused on a few user personas.
  • Current development processes do not accommodate UX assessments
Code:
Update coding language
Translate legacy code into modern coding language.
  • Coding errors in modern languages can have lesser impact on the business processes they support.
  • Modern languages tend to have larger pools of coders to hire.
  • Increase availability of tools to support modern languages.
  • Coding language changes can create incompatibilities with existing infrastructure.
  • Existing coding translation tools do not offer 100% guarantee of legacy function retention.
Code (continued):
Open source code
  • Download pre-built code freely available in open source communities.
  • Code is rapidly evolving in the community to meet current business needs.
  • Avoid vendor lock-in from proprietary software
  • Community rules may require divulgence of work done with open source code.
  • Support is primarily provided through community, which may not address specific concerns.
Update the development toolchain
  • Acquire new or optimize development tools with increased testing, build, and deployment capabilities.
  • Increase developer productivity.
  • Increase speed of delivery and test coverage with automation.
  • Drastic IT overhauls required to implement new tools such as code conversion, data migration, and development process revisions.
Update source code management
  • Optimize source code management to improve coding governance, versioning, and development collaboration.
  • Ability to easily roll back to previous build versions and promote code to other environments.
  • Enable multi-user development capabilities.
  • Improve conflict management.
  • Some source code management tools cannot support legacy code.
  • Source code management tools may be incompatible with existing development toolchain.
Data:
Outsource extraction
  • Outsource your data analysis and extraction to a third party.
  • Lower costs to extract and mine data.
  • Leverage unavailable resources and skills to translate mined data to a usable form.
  • Data security risks associated with off-location storage.
  • Data access and control risks associated with a third party.
Update data structure
  • Update your data elements, types (e.g. transactional, big data), and formats (e.g. table columns).
  • Standardize on a common data definition throughout the entire organization.
  • Ease data cleansing, mining, analysis, extraction, and management activities.
  • New data structures may be incompatible with other applications.
  • Implementing data management improvements may be costly and difficult to acquire stakeholder buy-in.
Update data mining and data warehousing tools
  • Optimize how data is extracted and stored.
  • Increase the speed and reliability of the data mined.
  • Perform complex analysis with modern data mining and data warehousing tools.
  • Data warehouses are regularly updated with the latest data.
  • Updating data mining and warehousing tools may create incompatibilities with existing infrastructure and data sets.
Integration:
Move from point-to-point to enterprise service bus (ESB)
  • Change your application integration approach from point-to-point to an ESB.
  • Increase the scalability of enterprise services by exposing applications to a centralized middleware.
  • Reduce the number of integration tests to complete with an ESB.
  • Single point of failure can cripple the entire system.
  • Security threats arising from centralized communication node.
Leverage API integration
  • Leverage application programming interfaces (APIs) to integrate applications.
  • Quicker and more frequent transfers of lightweight data compared to extract, load, transfer (ETL) practices.
  • Increase integration opportunities with other modern applications and infrastructure (including mobile devices).
  • APIs are not as efficient as ETL when handling large data sets.
  • Changing APIs can break compatibility between applications if not versioned properly.

About Info-Tech

Info-Tech Research Group is the world’s fastest-growing information technology research and advisory company, proudly serving over 30,000 IT professionals.

We produce unbiased and highly relevant research to help CIOs and IT leaders make strategic, timely, and well-informed decisions. We partner closely with IT teams to provide everything they need, from actionable tools to analyst guidance, ensuring they deliver measurable results for their organizations.

Member Rating

10.0/10
Overall Impact

$62,999
Average $ Saved

10
Average Days Saved

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve.

Read what our members are saying

What Is a Blueprint?

A blueprint is designed to be a roadmap, containing a methodology and the tools and templates you need to solve your IT problems.

Each blueprint can be accompanied by a Guided Implementation that provides you access to our world-class analysts to help you get through the project.

Need Extra Help?
Speak With An Analyst

Get the help you need in this 3-phase advisory process. You'll receive 8 touchpoints with our researchers, all included in your membership.

Guided Implementation #1 - Identify vision and value maps
  • Call #1 - Articulate an architectural vision.
  • Call #2 - Discuss value stream mapping and related use cases.
  • Call #3 - Continue discussion on value stream mapping and related use cases.

Guided Implementation #2 - Document multi-purpose data and security architecture
  • Call #1 - Continue discussion on value stream mapping and related use cases.
  • Call #2 - Map the value streams to required architectural attribute. Create a prioritized list of architectural attributes.

Guided Implementation #3 - Upgrade your systems availability
  • Call #1 - Document security design decisions.
  • Call #2 - Document scalability design decisions. Document performance design decisions.
  • Call #3 - Bring it all together.

Author

Usman Lakhani

Visit our COVID-19 Resource Center and our Cost Management Center
Over 100 analysts waiting to take your call right now: 1-519-432-3550 x2019