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