March 24, 2023 By Ashok Iyengar
Doug Eppard
6 min read

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

Was this article helpful?

More from Cloud

IBM Tech Now: April 8, 2024

< 1 min read - ​Welcome IBM Tech Now, our video web series featuring the latest and greatest news and announcements in the world of technology. Make sure you subscribe to our YouTube channel to be notified every time a new IBM Tech Now video is published. IBM Tech Now: Episode 96 On this episode, we're covering the following topics: IBM Cloud Logs A collaboration with IBM and Anaconda IBM offerings in the G2 Spring Reports Stay plugged in You can check out the…

The advantages and disadvantages of private cloud 

6 min read - The popularity of private cloud is growing, primarily driven by the need for greater data security. Across industries like education, retail and government, organizations are choosing private cloud settings to conduct business use cases involving workloads with sensitive information and to comply with data privacy and compliance needs. In a report from Technavio (link resides outside, the private cloud services market size is estimated to grow at a CAGR of 26.71% between 2023 and 2028, and it is forecast to increase by…

Optimize observability with IBM Cloud Logs to help improve infrastructure and app performance

5 min read - There is a dilemma facing infrastructure and app performance—as workloads generate an expanding amount of observability data, it puts increased pressure on collection tool abilities to process it all. The resulting data stress becomes expensive to manage and makes it harder to obtain actionable insights from the data itself, making it harder to have fast, effective, and cost-efficient performance management. A recent IDC study found that 57% of large enterprises are either collecting too much or too little observability data.…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters