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:
- Part 1: “Cloud at the edge”
- Part 2: “Rounding out the edges”
- Part 3: “Architecting at the edge”
- Part 4: “DevOps at the edge”
- Part 5: “Policies at the edge”
- Part 6: “Models deployed at the edge”
- Part 7: “Security at the edge”
- Part 8: “Analytics at the edge”
- Part 9: “5G at the edge”
- Part 10: “Clusters at the edge”
- Part 11: “Automation at the edge”
- Part 12: “Network slicing at the edge”
- Part 13: “Data at the edge”
- Part 14: “Architectural decisions at the edge”
- Part 15: “GitOps at the edge”
- Part 17: “Storage services at the edge”
- Part 18: “Cloud services at the edge”
- Part 19: “Distributed cloud: Empowerment at the edge”
- Part 20: “Data sovereignty at the edge”
- Part 21: “Solutioning at the edge”
- Part 22: “Connected products at the edge”
- Part 23: “Foundational models at the edge”
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:
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):
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:
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:
- Part 1: “Cloud at the edge”
- Part 2: “Rounding out the edges”
- Part 3: “Architecting at the edge”
- Part 4: “DevOps at the edge”
- Part 5: “Policies at the edge”
- Part 6: “Models deployed at the edge”
- Part 7: “Security at the edge”
- Part 8: “Analytics at the edge”
- Part 9: “5G at the edge”
- Part 10: “Clusters at the edge”
- Part 11: “Automation at the edge”
- Part 12: “Network slicing at the edge”
- Part 13: “Data at the edge”
- Part 14: “Architectural decisions at the edge”
- Part 15: “GitOps at the edge”
- Part 17: “Storage services at the edge”
- Part 18: “Cloud services at the edge”
- Part 19: “Distributed cloud: Empowerment at the edge”
- Part 20: “Data sovereignty at the edge”
- Part 21: “Solutioning at the edge”
- Part 22: “Connected products at the edge”
- Part 23: “Foundational models at the edge”
Learn more
- Architecture Framework in the IBM Cloud Docs
- IBM Edge Application Manager
- IBM Cloud Pak for Network Automation
Related articles
Was this article helpful?
YesNo