Solution Architecture Principles, an Approach

Overview and Approach to Solution Architecture

In the previous article about solution architecture principles, we talked about the history of solution architecture and a little bit about the origin of agile software development. In this article we’ll focus on more concrete topics. We’ll focus on how solution architecture can be applied to different operating models. We’ll look at some core concepts and tools that can be used to build solution and technology roadmap.

With that in mind, lets talk about what solution architecture is concerned with. Solution architcture is concerned with selecting an optimum set of technologies, practices, and processes that can be used to deliver a solution to a business problem; this is a little bit self-referntial, but can be summarized as follows. Solution architecture will:

• provide a technology roadmap that relevant stakeholders can understand, and

• ensure that the roadmap provides a solution to the specified business problem

Some would argue that solution architecture is technology agnositic; however, practically speaking, technology almost always plays a key role in solving business problems.

Operating Models, or How Technology Teams Work

Depending on where you work and the structure of your team, the way you approach solution architecture will change. There are two common patterns that are used for software development: a project based approach, and a product based approach. In the former, the development lifecycle is centered around the product. In the latter, development might be focused around an aspect of a product, or several products that need to be changed to solve a problem. There is a third approach: program based development. However, program management and program solutions are outside the scope of this article.

I’ll try to outline the core solution architecture principles from a practical perspective. Specifically, with a focus on agile development and how to create a solution architecture roadmap with limited information. We’ll also look at how to break down complex problems and solutions. Finally, we’ll start building a toolkit that will let us create a technology roadmap.

Lets start with the main concerns within agile solution architecture:

• Problem domain definition

• Pattern encapsulation

• Enterprise architecture integration

• Solution constraints

• Managing uncertainty

• Engagement model

The above will be discussed in more detail throughout the rest of the articles in this series; however, for convenience, we’ll summarize our tools below (kind of like a cheat sheet).

Problem Domain Definition

The problem domain is the set of properties and behaviors that can be used to describe the core business problem.

Pattern Encapsulation

Encapsulation implies that we want hide complexity, in this case we want to identify patterns that hold true across the solution and encapsulates them as a more broadly defined set of behaviors. An example would be: define system to system interaction pattern; where the encapsulation would be facilitated via REST interactions. Then we can define what REST means and include as part of the solution architecture. However, here we have an opportunity to utilize well known patters and reference common resources.

Enterprise Architecture Integration

Integration between solution architecture and enterprise architecture is akin to converting strategy into tactics. Specifically, tactical alignment with enterprise architecture is key. As an example, where there is a push for enterprise identity management strategy, tactically, we would evaluate framework such as SAML or OIDC, where we can enable identity management capabilities.

Solution Constraints

Solution constraints frequently take the form of components that are immutable within the architecture. For example, a legacy system can provide a set of solution constraints; that system cannot be modified and must be included as part of the architecture. These kinds of constraints frequently inform the shape of the overall architecture.

Managing Uncertainty

Part of the tactical decisions within a solution architecture are used to limit uncertainty. This implies that given the information available on-hand, decisions are made tactically, while the gaps are filled in with best effort assumption. The implication around uncertainty management is that the shape of the solution architecture will evolve as more information becomes available. This is especially important within an agile development environment.

Engagement Model

The engagement mode broadly describes the role of the solution architect within the context of the problem domain. Depending on the phase of the project, or the maturity of the product, the role of the solution architect changes. This important, since the role of an architect will change throughtout the development life-cycle.

Now that we have a few definitions under our belt; lets talk about how they apply to the different types of teams: product based, and project based.

Product Development and Solution Architecture

This approach revolves revolves around a central core problem; generally this is a business problem that the product is trying to solve. Therfore, understanding the core business problem is key to building en effective solution architecture. This mean that focusing on the problem domain is key to designing an effective architecture. However, as a product evolves, it goes through several different phases in it’s lifecycle. Furthermore, the phases are not linear, as product development will sometimes pivot to address a more fundamental business problem.

Below are some common phases of product development lifecycle:

• Concept

• Design

• Development

• Deployment

• Iteration

• Deprecation

In addition, larger products can apply the same phases to a specific product feature. In this way, you can move up and down the architecture and design stack in a consistent way.

Additionally, the focus of a solution architect changes though each of phase of the product lifecycle. During the concept phase, the focus is on understanding the problem domain; during the design phase, the focus is on minimizing uncertainty; during the development phase, the focus is on minimizing complexity; during the deployment phase, the focus is around maintainability; during the iteration phase, the focus is on minimizing technical debt; finally, during the deprecation phase, the focus is on understanding the downstream impacts of removing the product.

With that in mind, lets look at what changes when we deal with projects.

Projects and the Art of Solution Architecture

For projects, the approach to solution architecture is different, it focuses around understanding project dependencies and how those dependencies fit together. A project lifecycle is different than that of a product; specifically, projects typically focus on a specific area of improvement and can span several products or areas to achieve that goal. While understanding the problem domain is important; frequently understanding the solution constraints is critical when dealing with a project based lifecycle. A common project lifecycle can be summarized as follows:

• Discovery

• Planning

• Implementation

• Closing

Much like the product approach, the focus of a solution architect will also change with each phase of the project lifecycle. During discovery, typically the focus is around understanding the solution constraints; during planning, the focus is around identifying any area of uncertainty; during implementation, the focus is around managing technical debt; during closing, the focus is on ensuring that the architecture remains maintainable and the project meets its business objectives.

Key Solution Milestones

For both the product and the project based approach there are common solution milestones. The table below summarizes each milestones and lines it up to each solution concern.

StepMilestonesNotesProblem Domain DefinitionProblem briefThis can be informal, a one page document or email that summarizesPattern EncapsulationSolution architecture document outlineBased on the problem domain, relevant patterns should emergeEnterprise Architecture IntegrationFirst solution architecture draftBased on identified patterns and problem definition, a basic draft can be created and validated against published enterprise architecture principles, or an impact assessmentSolution ConstraintsSolution architecture document refinementConstraints will prune certain paths within the solution, as a result the solution architecture document should reflect these constraintsManaging UncertaintyUpdated solution architecture document and roadmapAs the product matures, technology will evolve. Having a roadmap that aligns with the published solution architecture will enable the product to mature while maintaining a serviceable level of technical debt

Key Technology Milestones

In addition to the solution milestones, there are key technology milestones that need to be defined. The table below provides a correlation between each solution architecture concern and technology milestones.

StepMilestoneNotesProblem Domain DefinitionTechnology stackA summary of the proposed technology stackPattern EncapsulationTechnology proof of conceptAny new components in the technology stack need to be understood, including usage and installationEnterprise ArchitectureIntegration Framework componentsAny common components that are to be used across the solution, or the enterprise need to be defined and createdSolution ConstraintsTechnology reviewReview the technology stack and ensure that it complies with solution constraintsManaging UncertaintyImplementation reviewReview the implementation to ensure it conforms to the architecture; ensure changes are not accruing unnecessary technical debt

The Road Ahead

In this article we’ve covered some core concepts and a basic overview of two common operating models. We’ve also summarized how solution architecture concepts related to specific milestones; and we’ve started building the foundation of our solution architecture toolking. Throughout the rest of this series we’ll look at each of the tools outlined here and how they can be applied to create agile solution architecture.

Stay tuned for more. Meanwhile if you have questions around solution architecture or specific details; you can always get a hold of me via: dany (at) calicologic (dot) com.