Enhance Your Solution Architecture Practices

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.

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).

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:

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

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: 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.

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

1.1 Craft a vision statement for your solution’s architecture

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

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

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

• 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?

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

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.

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

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	Loan Applicant Loan Supplier Applicant’s Bank	Should be able to see deposit in bank account Deposit funds into account Accept funds into account

Example for Phase 1.3

Loan Provision

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

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.

• 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

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:

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

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.

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.

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

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.

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.

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:

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:

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

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

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).

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
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

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

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.

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

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.

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

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.

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.

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.