Solution Architecture Concepts
Solution architecture describes the "big vision" of a particular solution to business and technical stakeholders, facilitates integration of contracting, infrastructure, and systems engineering activities, and fosters collaboration among stakeholders - adapted from Gartner and mitre.org
Solution architecture is typically an initiative-level activity performed during the ACT strategy implementation phase. Solution architecture must be aligned with the enterprise architecture that is developed during strategy formulation. Solution architecture scope can include initiatives (projects or programs), products, systems (applications, their technologies, processes, and information), and infrastructure services.
Enterprise, Solution and System Architecture
Enterprise, solution, and system architectures operate at different levels. Enterprise architecture is more at the conceptual and contextual level. It has a high strategy focus and a broad view of technology. System architecture is at the other end of this matrix. It is specific to a technology and has low level of strategic focus. Solution architecture forms the middle ground by combining enterprise and system architectures. Solution architecture spans conceptual, logical level and physical views of the solution and aligns strategy and technology.
Table below summarizes the focus and scope of different architecture types.
Enterprise Architecture
Strategy - High
Technology - Broad
Enterprise - entire organization
Project Solution Architecture
Strategy - Medium
Technology - Broad to specific (medium)
Limited to a project
Program Architecture
Strategy - High
Technology - Broad
Limited to a program
Business Segment Architecture
Strategy - High
Technology - Broad
Limited to a business line
Operations/Process Architecture
Strategy - Low
Technology - Specific
Enterprise - entire organization
Application/System Architecture
Strategy - Low
Technology - Specific
Limited to a system
Product Architecture
Strategy - Medium
Technology - Specific
Limited to a product or product line
Principles of Solution Architecture
Solution Architecture should:
be developed for every initiative which requires a technology solution
be developed by a Solution Architect with the appropriate skills and experience
influence, guide, and support the full life cycle of an initiative
focus on enabling success at the component/Initiative level
align with all IT development approaches (e.g., agile, waterfall, hybrid).
not add to the initiative timeline, and delay initiative activities
evolve in an incremental, iterative manner throughout the initiative life cycle
Advantages of the solution architecture
A solution architecture increases the likelihood of successful implementation of an initiative by ensuring that the solution:
translates current business requirements into a technical solution
fits into the existing enterprise environment
is positioned to meet evolving business needs
aligns with enterprise architecture and technology roadmaps
creates a foundation for continuous improvement of enterprise technology
facilitates the integration of various activities such as integration, infrastructure, and system design
helps estimate the resources required to execute an initiative
influences, guides, and supports technology decisions and activities
documents, delivers, and shares the technical vision of the initiative
Role of Solution Architect
Solution architects are seasoned business and technology professionals who lead the solution architecture work and support enterprise architecture activities. Solution architects should have the ability to understand business strategies including objectives, key results, guiding policies, choices and decisions made, capabilities, business and operating models, and functional and non-functional requirements. Sound understanding of business is necessary to ensure that the solution delivers business value and is fit for purpose.
Scope of Solution Architect’s work
Understand business context and requirements of the initiative
Deep knowledge of technology trends and their use cases
Translate business need into a technology solution
Advise on matters related to technology solutions
Lead and manage solution architecture deliverables
Collaborate with other architects e.g. enterprise, segment , and system architects
Facilitates to deliver outcomes
Mentor junior architects
Experience and Credentials
Bachelors degree or equivalent experience
Minimum five years of experience for lead solution architect
Exposure with or experience of different programming languages, IT stacks and components, systems and applications and environments
Knowledge or experience Microservices architecture, DevOps, Agile delivery
Relevant industry experience
Skills and Competencies
Programming languages such as Java, Javascript, Go etc.
Database technologies SQL and NoSQL
Web and mobile application development using HTML, CSS, Javascript
Knowledge of frameworks such as Zachman, TOGAF etc.
Planning, analysis, ideation, organizational, communication, modeling and documentation skills
Components of Solution Architecture
The solution architecture consists of three components:
The Conceptual Architecture: an overall view of the problem and solution from 30,000 feet. It should identify the major functional components of the solution and how they relate to each other. The conceptual architecture should be documented from the perspective of senior management decision makers who are interested in the key deliverables and changes
The Logical architecture: a more detailed view of the solution that includes software components, information flow, and control flow. This should provide a 10,000 foot view of the solution and include a mapping of functional components to software components, which may be custom software or vendor software.
Physical Architecture: a mapping of software components to hardware components, whether deployed on-premises or in the cloud. It is a ground-level view of the solution that includes computing, network, storage, server, and container components.
Solution Architecture Deliverables
Solution Options - Various options considered to solve the business problem. Detailed information is recorded for each option, including: Description, title, decision, reasons for decision, recommendation, ratings, advantages and disadvantages, risks, limitations, etc.
Solution Gap Analysis - maps the requirements to each solution and identifies the degree of the gap. It helps you determine the management, configuration, or customization effort required for each solution.
Design Patterns - what design patterns are used for each solution
Mapping to Building Blocks - map solution to building blocks such as applications, stacks, interfaces, business functions, processes, data entities and end users.
The following diagrams may support the deliverables and are documented using Visio, MS Powerpoint or Archimate. These diagrams present different view of the systems, which are representation of the system from the perspective of a viewpoint. There are several different viewpoints: context, functional, information, development, deployment and concurrency viewpoints.
Conceptual Diagrams
Solution Concept Diagram
A high-level depiction of solution boundary, functional building blocks and their relationship shown as arrows. The building blocks include application, users, function, process, organization etc. Its purpose is to describe the vision and context of the solution. Viewpoint: Context, Functional
Business Process Diagram
Provides an overview of the business activities performed by the solution. It documents the trigger, actor, function and usually presented as a swim lane diagram. BPMN notation is often used. Viewpoint: Functional
Layered Architecture Diagram
Presents different layers of the architecture showing building blocks in each layer. Viewpoint: Functional
User Interaction Diagram
How end users in different roles interact with the solution. Viewpoint: Functional
Logical Diagrams
Logical Business Process
More detailed view of the process
Functional Decomposition
Functions performed by the system in each layer
Interface Diagram
Shows interfaces of the system
Information / Control flow Diagram
How information flows through the system
Physical Diagrams
Physical Business Process
Detailed physical process
System Components
Physical components of the system
Technical Specifications
Technical details of the solutions
Solution Architecture Knowledge base
It is a repository of all solution architecture artifacts and information. It provides
Single source of information about the solutions
AS-IS and TO-BE solutions
Captures solution options, solution decision, rationale
Requirements mapping and gap analysis
Non-functional Requirements (NFR)s
Solution architecture diagrams
Design Patterns used in the solution
Non-Functional Requirement (NFR)
NFR:
"..is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements -- Wikipedia
Some key points about NFRs:
Functional requirements define "what" a system shall do and NFRs define "how" the system shall do
They define system attributes: scalability, reliability, security, performance, maintainability, and usability. Therefore, they are often called quality attributes of a system.
They are constraints or restrictions on the design of the system which the implementation team must adhere to.
Deviation of an application from any nonfunctional requirement leads to technical debt, which is potential future rework.
Technical Debt
The term technical debt was coined by Ward Cunningham in 1992. He describes it as:
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
Technical debt can arise due to different reasons as described below:
Deliberate technical debt: Such a situation arises when developers have to meet deadlines for bringing the product to market and are thus forced to take the shortest possible route to delivery. They should keep in mind that this debt must be repaid, otherwise future changes to the software will be more time-consuming and expensive.
How to address it: track it in the backlog
Debt to outdated design: Such a debt arises over time. Developers try to future-proof their software, but there is a limit to how far they can go without exceeding the time-to-market deadlines. Over time, as requirements and technologies change, this kind of technical debt slowly creeps in.
How to address it: refactor a system routinely say, every other year
Debt due to frequent incremental changes: This is a function of time and change. As incremental changes occur, and especially if they are made by different teams of developers this type of debt may accumulate.
How to address it: continuously refactor a system
Solution Architecture compared with other deliverables
Business Requirement Document (BRD) or Specification (BRS)
Documents "what" the initiative or software must do from a business, end user and stakeholder perspective. Requirement is a thing that is needed.
Business Analyst
Solution Architecture
Describes the "big-picture" vision of the solution to business and technical stakeholders for an initiative. Based on BRD.
Solution Architect
System Requirement Specification (SRS)
Documents the functional, non-functional and implementation requirements. It is the "how". A detailed description of the design and materials used to make something. Guided by Solution Architecture.
System Analyst/Architect
Further Reading
Guide for Solution Architecture - mitre.org
https://www.scaledagileframework.com/nonfunctional-requirements/
Last updated
Was this helpful?