Most Architects are familiar with Enterprise Architecture Frameworks (EAFs) but not all are familiar with Solutions Architecture Frameworks (SAFs). While the EAF is about understanding what many refer to as The Architecture for a given enterprise, the SAF is about getting to solutions for any given problem. It is a Design Thinking tool that has been in existence for many decades and that has been put to use and tested by some of the most well-known management consulting firms in the world. This publication provides an overview of the IF4IT SAF as a tool for getting to solutions that can and should be adopted by your own Architecture, Engineering, Product Service, and Service Development organizations.
Defining the Solutions Architecture Framework (SAF)
The Solutions Architecture Framework (SAF), also known as the Solutions Architecture Methodology (SAM), is a high-level description of phases, usually represented by chevrons that describe an approach for getting from one or more problems to one or more solutions.
The SAF/SAM is a framework/methodology, based on 100 plus reusable and customizable tools and templates for identifying, framing, and analyzing any problem, with the intent of getting to clearly defined, accepted, and realizable solutions (or to the realization that a solution might not be possible, which does happen).
Some history about SAFs/SAMs: Anyone who has worked in executive management has had the opportunity to work with some of the most well-known management consulting firms. The representatives of these firms almost always come in with a sales presentation that includes their phases for getting to solutions. It will almost always consist of four to seven chevrons that describe the high-level approach they will use to work with you, in order to first understand your problems and challenges, then analyze your environment and target future state, and ultimately get to realizable solutions to address those problems and challenges.
Mature enterprises realize they have internal people who are constantly working on problems and challenges, themselves; people who need to work consistently. They also realize that you cannot bring in expensive management consulting firms for every problem. For these reasons, they strive to establish, communicate, adopt, and follow their own SAF/SAM.
Who Uses the SAF
The people who use the SAF are usually those who act in capacity of a subject matter expert; someone who is qualified to help customers and relevant stakeholders clearly identify and assess different problems and challenges and who can help such customers and stakeholders get to clear decisions and outcomes that adequately address those problems and challenges. Examples of such subject matter experts include but are not limited to: Solutions Architects, Engineers (like Systems Engineers), Management Consultants, and Designers.
Phases of the IF4IT Solutions Architecture Framework (SAF)
The IF4IT Solutions Architecture Framework (SAF), which is freely available to the public for open reuse and adoption, consists of five key phases…
- Direction and Expectations Setting
- Current State Collection and Baseline Development
- Future/Target State Development
- Assessments and Solutions Options
- Strategy Realization Development
It is important to note that while the above phases are listed sequentially, they are by no means intended to be a executed as a sequential waterfall. In fact, it is very common for work from different phases to overlap, depending on when data is collected and available for analysis.
Phase 1: Direction and Expectations Setting
The first phase, sometimes referred to as Problem Scoping, encompasses a methodology for understanding the customer’s problems and challenges, with the specific intent to set clear expectations for Work Scope and to get clear buy-in from the customer (who has the problems and/or challenges) as to what work will or will not be performed. At the end of this phase, the customer and the solutions provider should be in clear agreement about what solutioning work will be done, general timeframes for performing that work, who will be involved in that work, etc. In formal management consulting firms, this often leads to a more detailed Statement of Work (SOW).
Phase 2: Current State Collection and Baseline Development
The second phase, sometimes referred to as Current State Analysis, encompasses a methodology for understanding the customer’s current state and establishing that current state as a baseline for change. This phase includes a significant effort to collect and analyze data about various problem dimensions and concerns (see diagram further on in this publication), with the intent to establish a clear understanding of what is or is not handled, before moving to a Future State solution. At the completion of this second state, the customer agrees that said current state representation is accurate and the person or team(s) performing the solutioning work is/are clear about how things are handled, today.
Phase 3: Future/Target State Development
The third phase, sometimes referred to as Future State Analysis, encompasses a methodology for identifying future state options for change, sometimes referred to as a Future State Architecture or a Target Architecture. The purpose of this third state is to help identify what needs to change in order to get to a desired future state. It also serves as a means for identifying future state options for change. By the time this third phase is completed, the customer and the person or team(s) performing the work have a clearer understanding of what needs to change in order to get to one or more solutions, and they have a better understanding of the different options for getting their. This is important because, often, there is more than one way to achieve the desired future state solution(s).
Phase 4: Assessments and Solutions Options
The fourth phase encompasses a methodology for assessing future state options, including prioritizing them, and getting to an agreed to set of solutions. In this phase, the person or team(s) performing the solutioning work continues to work closely with the customer in order to understand options, evaluate them for viability, get to a prioritized set of recommendations for the customer, and get to a finally selected solution or set of solutions that is fully ratified by the customer. At the end of this phase, all stakeholders clearly understand what the selected solution set is and they begin to coordinate work efforts in order to all move in a consistent direction, together.
Phase 5: Strategy Realization Development
The fifth and final phase of the SAF/SAM focuses on taking the agreed upon solution set and doing what is needed to make it/them real. This is where the proverbial rubber hits the road and teams start defining clearer work plans, securing funding, planning individual programs and detailed projects or releases that will be executed within them, getting to staffing for skills, etc. There is often a tremendous amount of work that results from this phase.
Often, management consulting firms stop here or work with the customer to create new Statements of Work (SOWs) for ongoing future delivery work.
In the case of Architecture Organizations, non-technical Architects tend to stop here, too, while more technically adept Architects continue to work with teams to facilitate anything resulting from this fifth and final phase. This is because in most enterprises, most solutions have very heavy dependencies on many different technologies. The latter type of Architect is referred to as a Coding Architect.
A more detailed representation of the above looks as follows…
How to Use the SAF
While SAF work is not necessary meant to be sequential, decision points within and across phases, usually are.
Starting from the beginning, the user of the SAF (someone working in the capacity of a Solutions Architect, Engineer, Designer, or Expert Consultant) will work with their customer(s) and all relevant stakeholders to collect and develop all information necessary to adequately support each phase of the SAF. The user creates each necessary artifact for each phase in a manner that allows clear analysis, sheds light on next steps, and helps get to clear decisions that lead to firm next steps. As the user develops each of the supporting artifacts and moves through each of the SAF phases, he/she works with the customer(s) and stakeholders to establish decision data, analyze the materials, make decisions, come to clear consensus for each phase, and ultimately establish clear direction for solutions. By the time one or more solutions is selected, in the fourth phase of the SAF, everyone involved is clear on what solutions are being selected, why they’re being selected, how they’re being selected, when they’re being selected, who will perform relevant work, etc. All stakeholders are clearly aligned and there are no surprises about decision directions. This is important for moving into the fifth phase, which is about ensuring the development of all artifacts to identify and progress with initiatives, programs, projects, releases.
By the end of the methodology, the SAF user(s) has established significant quantities of supporting data, covered most concerns, and collected clear decisions (all that act as auditable reference materials).
The Benefits of Establishing an Enterprise Solutions Architecture Framework (SAF)
There are many benefits for establishing your own SAF. Some of the most relevant include but are not limited to:
- Having a consistent internal framework or methodology that internal resources can follow. This leads to things like consistent and reusable data/knowledge artifacts, consistent and reusable tools for performing work, and consistent outcomes.
- Having your own clearly established and well-documented SAF makes it easier to get external consultants and vendors to work your way, instead of you always working their way. One of the biggest challenges when dealing with multiple different management consulting firms is that they each work different (but similar) ways. Having your own SAF, in the cases where you can get them to follow it, puts your enterprise in control.
- Employees work more efficiently because they more clearly understand what they’re supposed to do, how they’re supposed to work, when deliverables are expected, etc.
- Having a clearly documented SAF makes it easier and faster to onboard new employees and consultants.
- It provides IT organizations with a consistent vernacular and approach that can more easily be understood by non-IT business counterparts.
Ownership and Accountability for the SAM/SAF is Usually in Architecture
Given that the SAF/SAM is used by most Solutions Architects (and other Architect types), its definition, ownership, maintenance, support, and communications is usually placed in the Architecture Organization, as a responsibility of the Chief Architect (a.k.a. Head of Architecture).
In this capacity, the Chief Architect works with his staff to develop the framework (e.g. roles, processes, tools, templates, etc.) so that it can be consistently used by all Architects, Engineers, Product Development organizations, Service Development Organizations, and any other stakeholder that has a role in the design of complex solutions.
By taking on this responsibility, the Chief Architect has a clear stake in enterprise work consistency, ensuring that anyone involved in problem analysis and design thinking is working in a highly orchestrated manner that lends itself to higher levels of efficiency and effectiveness.
SAF Tools and Templates
A thorough SAF has clearly defined and available tools and templates that can be used within and/or across any of its phases. The reason for this is that the SAF is a repeatable pattern that will be applied, over and over again, to solve many different problems and challenges.
Because there needs to be a centralized organization that owns, shares, coordinates, improves, and supports such tools and templates, this type of work almost always falls to the Chief Architect and the Architecture Organization.
The IF4IT SAF list of templates consists of over 100 individual templates that can be leveraged for SAF-related work. You can contact the IF4IT to learn about its available SAF-related courses, tools, and templates.
The Architecture Reference Book (ARB)
The Architecture Reference Book (ARB), also referred to as the Architecture Reference Document (ARD), is a combined set of artifacts that are collected, coordinated, and polished, throughout all phases of the SAF/SAM. When a management consulting company completes its work, it delivers to the customer a binder consistent of all its work. The sections of this document are often aligned with the phases of the SAF. In the more modern digital age, this ARB/ARD acts as an electronic knowledge artifact, complete with embedded links, to critical data, information, and knowledge that are associated with the solutioning effort. This means that any stakeholder, in the present or in the future, can open up the artifact and dive into details within or across any of the phases.
Note that in a very mature enterprise, the materials collected for each phase of the SAF for a given engagement are used by the Architecture Organization and its employees to update other live enterprise tools and artifacts such as but not limited to: The Digital Enterprise Library, Enterprise Models, Enterprise Taxonomies, Service Frameworks and Service Catalogs, Enterprise Capability Models, and much more. This means that if you open up the ARB/ARD, it has links to many different tools and artifacts, many of them interactive. This is critical to understand because all people working with the SAF, throughout an enterprise, are constantly improving Enterprise Knowledge Management (EKM). In other words, they’re constantly collecting, curating, feeding, improving, aligning, correlating, maturing, and sharing data, information, and knowledge learned about the enterprise in a manner that can be leveraged by everyone else in the enterprise.
SAF versus other Design Thinking Frameworks and Tools
There are multiple other Design Thinking frameworks and tools someone can use, when trying to get to creative solutions. None is wrong but all take different approaches for understanding and solving problems. The important thing to realize about the IF4IT SAF is that, while it can be used for any problem, it more specifically targets and facilitates Design Thinking or Solutions Thinking for the types of problems and solutions that are more in line with enterprises (e.g. businesses and government agencies). This means that the SAF more explicitly and intentionally covers the areas, dimensions, and concerns that are critical for getting to solutions which can be successfully offered by or used by an enterprise. Examples include but are not limited to:
Because the SAF explicitly covers all these dimensions and concerns, it forces its users to explicitly think about and address many different specific things that most other Design Thinking frameworks and tools ignore. It also espouses consistent work and generated work product(s) across many different architecture engagements or design thinking efforts. This results in the consistent build up and representation of critical knowledge across multiple different efforts.
It is strongly believed that because of the above differences, the SAF betters direct the people using it toward a higher probability of successful outcome than other Design Thinking frameworks and tools.
SAF versus EAF
The Enterprise Architecture Framework (EAF) is a mechanism that concerns itself with the development of The Enterprise Architecture, otherwise known as The Architecture. The SAF is different from the EAF in that it is intended to focus on a given set of problems and/or challenges with the intent to drive to specific solutions that will solve or overcome such problems and challenges. The EAF is broad while the SAF is far more specific.
This being said, the SAF is extremely important for feeding and maintaining the EAF and its resulting Enterprise Architecture (the noun form). Many different roles throughout an enterprise are constantly solving problems and coming up with solutions for them. The SAF represents a mechanism for helping them get to such solutions, regardless of their role or station in the enterprise. Additionally, if implemented correctly, different steps within the SAF will constantly leverage the existing Enterprise Architecture for reference and constantly feed data back to it, in order to help maintain it and evolve it, over time. This is extremely important in very large enterprises where a centralized Architecture Organization cannot possibly scale to work with many tens of thousands of employees and consultants, simultaneously, in a globally and geographically dispersed enterprise.
SAF versus SDLC
The Systems Development Life Cycle (SDLC), which in the case of software is often referred to as the Software Development Life Cycle (SDLC), is methodology that defines the high level phases for delivering systems or software from inception, through to installation, operations, and end-user use. [Read more about the IF4IT Systems Development Life Cycle (SDLC) Framework.]
The SAF differs from the SDLC in that it is focused on coming up with solutions that will be partitioned and fed into the SDLC framework, its methodologies, and its processes. The output(s) of the SAF often represent a coarser view of what will eventually be broken down to one or more SDLC Release Cycles (i.e. an iteration through the SDLC). For example, a solution that is discovered and agreed upon as part of the SAF often results in many different teams working in different SDLC streams, and possibly even iterations, to deliver those solutions. In such cases, the outcomes of the SAF often act as aggregating programs (i.e. Program Management) for smaller projects and releases. In fact, for bigger problem spaces, it is not uncommon for the output of one SAF process to act as an overarching Initiative or Program for many other smaller Initiatives and Programs, each further using the SAF to decompose them, until realizable work can be fed to many different SDLC streams.
One Important Caveat
If you plan to use the SAF, you’d better be qualified to dig into and pick solutions. Most enterprise solutions require heavy amounts of process automation (software, robots, machinery, etc.), new technologies, transition plans for old technologies, understanding how to evaluate existing and new technologies, etc. If you are not qualified to do these things, you might be in over your head. However, if you are qualified and apply the SAF properly, it will help you achieve higher levels of productivity, higher levels of repeatability and reuse, and will help you appear even professional to your customers.
If you lead an Architecture Organization in a role like a Chief Architect or if you’re part of an Architecture Organization as an Enterprise or Solutions Architect, the SAF is a powerful framework and set of tools for helping you and your organization be even more successful in helping your customers get to solutions.
- The Coding Architect – Expecting More From Your Architects
- Blueprint for Information and Technology Management (ITM)
- Enterprise Taxonomies
- Consider Letting Architecture Own Service Management
Contact the IF4IT to Learn More
The IF4IT offers education and certification courses, consulting services, tools, and templates related to Solutions Architecture. If you or someone in your enterprise is learning more about Solutions Architecture and the Solutions Architecture Framework (SAF), or for any other area of Architecture, feel free to contact the IF4IT to learn more.