Solutioning is a recent term that has entered the IT lexicon that means the process and method of producing an IT solution.

An IT solution is a set of related software programs and/or services that solves one or more business problems. IT vendors, service providers and value-added resellers (VARs) market software bundles or product offerings as part of the solution repertoire.

In this blog post, we will look at solutioning from an IT architect’s perspective—more specifically, what it means to come up with a solution in the edge computing domain. Whether it is working with a business to define requirements, working with business partners to frame opportunities, managing vendors to deliver the solution or working with internal staff to use the solution effectively, IT projects can be complex. We will also take a brief look at complex solution architecture.

Please make sure to check out all the installments in this series of blog posts on edge computing:

The solution architect’s role in solution design

End-to-end solution design involves creating a solution architecture containing artifacts, including assumptions, diagrams (context, networking and data flow), and a service management and responsibility RACI matrix. The end goal is to meet customer requirements.

The role of a solution architect (SA) is to create a comprehensive, end-to-end architecture to solve a particular business problem and associated set of requirements. The SA should demonstrate how the solution fits into the existing enterprise architecture (which typically comprises technology and business layers) along with a set of well-defined principles and strategies typically established by an organization’s enterprise architecture. Solution architects design and describe the solution, and they ensure the solution addresses service management aspects like operations and maintenance. Most importantly, they provide the linkage between the business problem and requirements to the technology solution.

Solution architects use diagramming tools, design templates, business models, sequence diagrams and architecture frameworks to craft the relevant solution architecture artifacts that address functional and non-functional requirements (NFRs). Figure 1 shows one such solutioning framework, which is a matrix of domains and aspects:

Figure 1: Domains and aspects in an architecture framework.

There are two key factors that cannot be overlooked: business and technology. Technology is the enabler for desired business capabilities. Once the technology components in the various domains are identified, it is an exercise in making sure they are well integrated and the solution can be delivered in an acceptable amount of time.

Edge computing as a solution domain

In previous blog posts, we have described edge computing as the discipline that brings the power of the data center out to devices at the edge. That could be the network edge, enterprise edge or the far edge (see Figure 2):

Figure 2: The edges in edge computing.

Each edge offers its own set of challenges, from the type of compute to network latency to the amount of available storage. A network edge-related solution for a telecommunications company may not encompass other edges, whereas a camera-based far edge retail solution could encompass all three edges.

Solutioning in edge computing

When it comes to solutioning at the edge, solution architects must think small—as in small footprint, limited-to-no storage, disconnected mode, etc. Examples of devices could include the Intel NUC, Nvidia Jetson, 1U computers, robots, mobile phones, smart cameras, cars and even programmable sensors. Often these devices cannot run Red Hat OpenShift, so one might have to consider the use of Red Hat MicroShift, Single Node OpenShift (SNO), K3S or RHEL for Edge with podman.

As an example, let’s look at the creation of a private 5G solution for a customer. This would fall into the “modernization” business category. In Figure 3 below, all the domain cells highlighted in light green would be in play. This provides a quick view of the domains in scope and forces the solution architect to start thinking of the various interactions and architectural decisions to be made (or components to be chosen), which correspond to those solution domains:

Figure 3: Domains in play for an edge-related solution.

Given this use case is 5G-related, there would be greater focus on the network edge. A 5G network essentially consists of three elements: a packet core, a radio access network (RAN) and user equipment (UE) or far edge devices. The next step would be to create a solution architecture diagram showing the infrastructure, network, security and integration details.

Key architectural decisions would have to be made regarding network function virtualization (NFV), whether to use VNFs (virtual network functions that are VM-based), or CNFs (cloud-native network functions) to run the networking functions and other platform resources like compute and storage. The transition from physical elements to VNFs and now to CNFs categorizes it as a modernization journey. Hyperscalers like IBM would have to decide which communication service provider (CSP) to partner with to provide the RAN. Finally, one must consider the placement, deployment and management of workloads on the far edge devices.

Based on the architecture decisions, the solution architect creates a software stack and a bill of materials (BOM) for the solution. For example, IBM Cloud Pak for Network Automation offers many of the necessary network functions in this solution. A product like IBM Edge Application Manager can perform the placement, deployment and management of workloads. A version of Red Hat OpenShift can run the containerized workloads. All these artifacts make up the solution package that is given to the implementation team. Refer to “Architectural Decisions at the Edge” for edge-related architecture decisions.

Complex solutioning as a discipline

With the rise of IT solutions that involve multiple clouds and hundreds of microservices that require significant interoperability, solution architects are forced to design solutions that meet stringent requirements and integration complexity. This has given rise to a new discipline called complex solution architecture and correspondingly the role of complex solution architect (CSA). A major facet of complex solutioning is risk assessment and risk mitigation.

What makes a solution complex?

A challenging client environment, the client’s digital transformation maturity, deployment in multiple geographies and languages, multiple products from multiple vendors, numerous integrations, security, compliance requirements, and FOAK (First of a Kind) implementations make for a complex solution. While iterating through solution design, it is imperative that solution architects come up with a solution that not only provides value to the customer but also fits the customer’s budget.

Wrapping up

Designing an edge solution that involves analysis of visual data captured by cameras within a private 5G network is complex. Design decisions come into play at every layer—from infrastructure to network to applications running in far edge devices.

Solution architects have many tools at their disposal, but an architecture framework helps guide the solution design process and ensures no aspect and related domains are overlooked when designing end-to-end solutions to meet customer requirements.

Let us know what you think.

Thanks to Joe Pearson and Jose Ocasio for providing their thoughts and reviewing the article.

Please make sure to check out all the installments in this series of blog posts on edge computing:

Learn more

Related articles


More from Cloud

Kubernetes version 1.28 now available in IBM Cloud Kubernetes Service

2 min read - We are excited to announce the availability of Kubernetes version 1.28 for your clusters that are running in IBM Cloud Kubernetes Service. This is our 23rd release of Kubernetes. With our Kubernetes service, you can easily upgrade your clusters without the need for deep Kubernetes knowledge. When you deploy new clusters, the default Kubernetes version remains 1.27 (soon to be 1.28); you can also choose to immediately deploy version 1.28. Learn more about deploying clusters here. Kubernetes version 1.28 In…

Temenos brings innovative payments capabilities to IBM Cloud to help banks transform

3 min read - The payments ecosystem is at an inflection point for transformation, and we believe now is the time for change. As banks look to modernize their payments journeys, Temenos Payments Hub has become the first dedicated payments solution to deliver innovative payments capabilities on the IBM Cloud for Financial Services®—an industry-specific platform designed to accelerate financial institutions' digital transformations with security at the forefront. This is the latest initiative in our long history together helping clients transform. With the Temenos Payments…

Foundational models at the edge

7 min read - Foundational models (FMs) are marking the beginning of a new era in machine learning (ML) and artificial intelligence (AI), which is leading to faster development of AI that can be adapted to a wide range of downstream tasks and fine-tuned for an array of applications.  With the increasing importance of processing data where work is being performed, serving AI models at the enterprise edge enables near-real-time predictions, while abiding by data sovereignty and privacy requirements. By combining the IBM watsonx data…

The next wave of payments modernization: Minimizing complexity to elevate customer experience

3 min read - The payments ecosystem is at an inflection point for transformation, especially as we see the rise of disruptive digital entrants who are introducing new payment methods, such as cryptocurrency and central bank digital currencies (CDBC). With more choices for customers, capturing share of wallet is becoming more competitive for traditional banks. This is just one of many examples that show how the payments space has evolved. At the same time, we are increasingly seeing regulators more closely monitor the industry’s…