The service consumer is the customer of the IT department in an organization. It is the responsibility of the IT department to determine the needs of the service consumer through continuous dialog.

The service consumer is primarily an application developer who is looking for a way to efficiently accomplish a repeatable task. This task is part of a larger process and commonly achieved through microservices in modern development approaches.

The background of the service consumers and their skills vary based on their application development experience. Regardless of background, the service consumers are focused on their specific area of work without concern or knowledge of the underlying intricacies of the systems that are hosting the services that they want to use.

The service consumers are expected to deliver code updates in short iterative cycles while also working on code defects. The quicker development cycle is driving the need for services that can be delivered quickly to the consumers. At the same time, consumers should not need to understand or be responsible for the underlying system components.

In this chapter, the authors share Walmart’s journey working with the consumers, the typical needs of the service consumers, and the criteria for success that Walmart discovered during the development of their initial service offering.

This chapter includes the following topics:

 

It is important to understand the requirements of the consumers before a solution is selected for a specific need. After the requirements, such as service level agreements (SLA), I/O rates, CPU rates, and accessibility needs are gathered, an informed decision can be made about the best way to satisfy those requirements.

This ideal approach is not always reflective of reality, though. Traditional processes in enterprise IT departments are commonly not conducive to the needs of the application developers.

The ability to deliver new capabilities quickly is as important as the ability to address technical specifications. Decisions based on speed might sometimes be made in lieu of properly addressing other requirements. This situation presents a challenge to infrastructure and platform engineers in many cases, but it also represents an opportunity. This scenario provided the platform engineers in Walmart an opportunity to truly address all of the needs of a consumer.

A team of Walmart developers required a distributed caching solution to support new features that were being incorporated into their application. This distributed non-z/OS application required storing and retrieving session information from any node in the server farm across which the application was hosted.

The functional requirements for the new capability were well-defined. The caching solution needed to employ ubiquitous communications protocols to ensure accessibility from a broad array of platforms and programming languages. The information that was being stored and retrieved required a unique key to identify the information, which might be in any number of formats and would be of variable length up to 3.2 MB. The solution also needed to support automatic expiration of cached objects at user-defined durations.

The non-functional requirements were not as clearly understood in the early stages of development. This issue led to the selection of a caching solution that did not meet the demands of the application. Problems with performance and availability became pervasive with the chosen product. An issue like this issue is never welcomed, but it did lead to increased communication between the developers and platform engineers and allowed the engineers to gain a better understanding of the needs of the application.

The increased communication also led to a better understanding by the platform engineers of the needs of the consumer. Awareness of functional and non-functional requirements is critical when providing a particular capability to solve a business problem. Ensuring that a capability is quickly acquirable, highly accessible, and flexible is as critical when providing for consumers’ needs. This concept drives the need to deliver capabilities as services, and provides the basis for the cloud computing service delivery model.

This publication follows the creation of a caching service by the Walmart z/OS platform engineers based on the needs of the developers. The means by which the functional and non-functional requirements of the service were satisfied are described in Chapter 3, “The service provider” on page 13, Chapter 4, “The CICS systems programmer” on page 27, and Chapter 5, “The z/OS systems programmer” on page 45. The remainder of this chapter focuses primarily on needs of the consumer and how Walmart addressed these aspects.

As the design for a caching solution was being solidified, the Walmart engineers also remained focused on satisfying the consumers. Based on a recognized need within their environment (along with an awareness of trends in the IT industry), the engineers decided to ensure that their solution did satisfy technical requirements and would be easily acquired by the developers.

The engineers iterated through numerous builds of caching service instances to ensure that the process was fully documented and understood. Then, they automated the build process. With the automated process in place, consumers could contact the engineering team and acquire a service instance in a matter of minutes. To further improve consumer responsiveness, the engineers developed an online web portal with which consumers can start requests and acquire service instances within seconds.

Consumer feedback continues to drive the capabilities that were enabled by the service providers. The evolution of the request portal is shaped by ongoing input from the service consumers. The current iteration of the self-service facility is based on a service-enabled design and includes APIs for the provisioning functions that can be used from any other entry point in the network. The high-level architecture of this capability is shown in Figure 2-1. For more information about the self-service facility, see Chapter 3, “The service provider” on page 13.

The ability for consumers to quickly and autonomously acquire a particular IT capability is immensely powerful. Immediate benefits include increased agility through the ability to deliver new business capabilities faster and to minimize negative effects by addressing defects and issues more responsively. However, the indirect benefits of this consumer-oriented feature are as compelling, if not more so. On-demand access to services enables experimentation, which allows creativity and innovation to flourish in the IT organization.

Most enterprise IT environments consist of various platforms, operating systems, and programming languages, each with particular features and capabilities that are suited for a specific need in the organization. Often, there are different groups of consumers that are related to each technology, which results in a diverse set of consumer needs. However, there also can be certain requirements that are common across the different groups of consumers.

A prime example of common concern, which is born out of this diversity, is the need for ubiquitous communications mechanisms. It often is necessary for various platforms to communicate and share information. Consumers want the services that they use and develop to integrate easily within the environment.

Communication across platforms is achieved with message queuing products, such as IBM MQ, in an asynchronous manner, or over HTTP, which can be used in synchronous or asynchronous ways. HTTP is most commonly employed by using SOAP web services or the ReST architectural style.

Of the cross-platform communication options available, ReST over HTTP provides the broadest compatibility, while being light-weight, highly flexible, and easy to use. For these reasons, ReST became the method that is expected by service consumers and the de facto standard in cloud computing. For more information about ReST, see Chapter 3, “The service provider” on page 13.

On occasion, there might be some overlap of the service requirements and consumer needs. In the case of the caching service in Walmart, the application required the cross platform communications that are provided by HTTP and the flexible data formats that are provided by ReST.

However, the application developers requested particular functionality with the HTTP requests that was a deviation from the specification. The change was intended to provide ease of use and simplify development activities. The consumers requested the following behavior:

Although this behavior departs from a strict adherence to the HTTP standard, it was implemented to address the needs of the consumer by reducing development effort.

Although most consumers of the caching service in Walmart are x86-based applications, there are also CICS applications that use the service. It is worth noting the basic requirements here for the use of services from CICS.

As a CICS consumer or client, the following API commands are required:

The WEB SEND and WEB RECEIVE commands can be consolidated as one by using the EXEC CICS WEB CONVERSE CICS API.

When a service is consumed, a CICS application must know the URI of the target system and service. This information can be defined to CICS in a client URIMAP.

Figure 2-2 shows an example of a client URIMAP that contains the path name, host name, and port of the target server and service.

Figure 2-3 shows how a CICS consumer program might issue an EXEC CICS INQUIRE URIMAP command to retrieve URIMAP information, such as the host name, port, and path names, which are used on the WEB OPEN and WEB SEND commands.

This chapter highlighted the importance of fully understanding all needs of the service consumer. Before deciding on architecture or design, these requirements must be gathered. They then form the basis of the choices of a service provider when a service is designed and how to deliver it.

Whatever the requirements, z/OS and CICS can be a beneficial place to host services, with no need for your service consumers to understand the intricacies of z Systems.

For more information about the requirements of the consumer and the responsibilities of the service provider, see Chapter 3, “The service provider” on page 13.