USA
Belgium
France
UK
Australia
India
Singapore
Executive Summary
Authors: Sash Purohit, CTO – Products, and Justin Carlson, Vice President Lead – Product
Cloud technology has been in the mainstream for over a decade now, and enterprises both big and small have adopted it to varying degrees based on their business needs. Enterprises have turned to cloud to become more agile and to transition from legacy IT service approaches to digital products. This journey has been challenging for many companies due to the growing diversity of cloud services, the shortage of cloud talent, and the move to adopt cloud native solutions. Adding to the problem, companies must address these issues while also ensuring that security and governance controls are implemented appropriately within this new cloud-based environment.
To address these challenges, some enterprises partnered with a single hyperscale cloud vendor, while others were more cautious and adopted hybrid multi-cloud approaches. The latter approach was driven by many technical and business considerations, but the chief concern was to avoid cloud vendor lock-in. In either scenario, enterprises faced the need to extend IT architectures to include cloud services. This meant developing core competencies in the applicable public and private cloud services along with management tools, so that security and governance can be handled appropriately in this extended enterprise architecture context. This is a daunting task due to the magnitude of change introduced by cloud but also due to the advanced technical skills required to implement these changes. The ongoing industry shortage of qualified human resources only compounds this problem.
The IT industry is undergoing unprecedented, rapid change—the transformation from IT projects to digital product management as brought on by digital transformation and accelerated by the COVID-19 pandemic. Today, even a low-tech company manufacturing commodities must include a software application as part of its product offerings. The days of treating IT as a cost center to build technical solutions though projects and conventional outsourcing strategies are over [1]. Business and IT teams are evolving into digital product teams that manage end-to-end product lifecycles by leveraging platform-based approaches that rely on cloud services.
The Open Group published the Cloud Ecosystem Reference Model [2,3] to serve as a guide for enterprise architecture as it evolves to include cloud services. The reference architecture lists many management functions that we collectively refer to as “cloud ecosystem management.” We assert that cloud ecosystem management based on The Open Group’s reference architecture is a superior approach to hybrid multi-cloud—unlike other approaches that are based on cloud-vendor specific management tools or other homegrown approaches that do not consider the reference model. We demonstrate that it is necessary to adopt a wholistic approach to cloud that supports anyAAS and extends beyond IT DevOps teams to include FinOps, App teams, Support (SRE) teams, Partner teams, and business leadership. A cloud ecosystem management platform (CEMP) encompasses this wholistic approach to cloud. We leverage the work of The Open Group’s Cloud Ecosystem Reference Model (Standard) [2] to describe the important technical and functional capabilities of a CEMP. This is followed by a description of how to apply reference model principles to create a CEMP. We then describe the functional architecture of a CEMP for internal use by an enterprise.
Introduction
While enterprises often recognize the business growth potential that digital and cloud products and offer, this is often stymied by the technological and human resource challenges that cloud presents. There are two major undercurrents affecting enterprises—the explosive growth and diversity of cloud service offerings from the major public and private cloud providers as well as the move to digital product from conventional IT services. As enterprise IT architecture moves towards a product-based [3] and multi-cloud approach, enterprises face the daunting task of mastering a diverse collection of hundreds of different cloud service offerings by the hyperscale cloud providers (also known as hyperscalers); this is in addition to new IT capabilities [2] introduced by the cloud ecosystem and the changes necessitated by the move from project-based to product-based operating models.
Not recognizing and adapting to this transformed landscape can prove problematic for enterprise IT and their digital transformation and cloud initiatives. Smarter enterprises strategically aligned with a single or multiple hyperscalers often struggle to reap the promised transformative benefits of cloud. Some end up with siloed capabilities where multiple teams offer redundant capabilities that are often fragile, unrepeatable, not scalable, and hamstrung by an ongoing shortage of qualified human support resources. Others pass the problem on to an MSP/SI who then experiences the same problems, amplified by the complexity of supporting a robust and varied customer base of differing size and industry. In either scenario, the enterprise sees ballooning operating expenditures with a lack of visibility, governance, or simple understanding of who is using what and how much it costs. The smartest enterprises recognize that the cloud ecosystem and product centricity pose a new set of challenges that they need to address in a different way.
Diverse Cloud Offerings from Hyperscalers and Private Cloud Vendors
1,000+ cloud services across 80+ categories
In such a diverse and technically rich cloud service landscape, enterprises can only hope to master a small subset of cloud service provider offerings. However, even that can be a daunting task as most inevitably choose the top two or three hyperscalers, such as AWS, Azure, and GCP—still adding up to several hundred different services. On top of that, achieving mastery over even a single vendor’s cloud services requires time, money, and skilled technical staff who can pass the certification exams offered by these vendors. Even if some enterprises succeed in achieving mastery over the popular cloud service provider offerings, the success is temporary and difficult to scale due to manpower movements and scarcity of talent. Some enterprises adopt the “learn-it as you need it approach.” While such an approach may work in very small deployments, it is non-starter for the complexity and needs of mid-market and large enterprise cloud environments.
Digital Product Centric Operating Model
In The Shift to Digital Product, [4] the authors argue that IT-enabled products and services are becoming the norm in every market. A major consequence of this change is that IT and Business need to work together as one digital product team. Gone are the days where Business can view IT as project brokers, order takers, and machine operators. They go on to propose that IT management should become digital portfolio management as it changes the way enterprises need to think about lifecycle management, dependencies, accountability, IT investment practices, IT financial management, and IT ROI. The Open Group updated the IT4IT Standard releasing Version 3.0 that provides a reference architecture used to manage the business of IT and the associated end-to-end lifecycle of digital products.
Figure 2: Transition from IT Service to Digital Product.
comparison by The Open Group (see Figure 2). The main change is that a digital product model removes all services provided by human labor and replaces them with technology or software code. This has major implications for enterprises: traditional IT outsourcing that provides human resources to develop IT solutions is not a viable business strategy for digital product. Digital product requires innovation and software-based automation, so enterprises must be ready to develop packaged software accelerators (modules) that become integral parts of customer digital products.
COVID-19 also accelerated the shift to digital, as documented by numerous articles and publications. Digital transformation has remained the dominant theme for the last decade despite its low success rate. Yet, due to the inevitability of digital products and services, faith in digital transformation is still very strong. Project to Product [1] describes the impact of digital disruption on traditional models of enterprise IT. In its foreword, Gene Kim states that in the age of software, the methods that served us well for over a century—such as IT project management, managing technology as a cost center, traditional outsourcing strategies, and relying on software architecture as the primary means to increase developer productivity—are coming to an end. We completely agree!
Figure 3: Digital Transformation drives digital product revenue.
Considering these tectonic shifts in the enterprise IT landscape, it is unsurprising that enterprises are impacted in multiple ways. As illustrated in Figure 3, over time typical IT projects will ramp down, giving way to digital products. Enterprises that adapt to this change and develop software accelerators can expect to see greater success rates in their digital transformation and cloud initiatives. For example, enterprises will be looking to create digital platforms for the consumption and brokerage of cloud services as new digital products. A wholistic AnyAAS platform can help address these requirements.
Vendor Specific Management Tools Provide Limited Benefits
As mentioned previously, enterprises often strategically align with leading hyperscalers; this then leads them to build applications and software solutions using the providers cloud services. Once their infrastructure footprint grows beyond a couple dozen or more clusters, the problem of managing these resources becomes extremely important; this includes provisioning, orchestration, governance, cost, security, auditing, reporting, compliance, and more. The natural approach to solving the management problem is to use the cloud provider’s management toolset. As a result, the Enterprise is locked into the vendor’s software and cloud services, and it becomes extremely difficult to abstract away and apply the same solution using a different hyperscaler. Ultimately, this approach leads to multiple solutions—one or more per hyperscaler—that must be individually maintained and evolved as the hyperscaler adds more services.
Enterprises are not only adopting multi-cloud approaches, but they also have a significant private cloud footprint. As a result, the same problem across multiple hyperscalers now repeats itself with private clouds. Further, enterprises that choose a single hyperscale vendor for their infrastructure services (IaaS) use multiple clouds when you include SaaS subscriptions from software vendors. It is therefore safe to conclude that this approach is not scalable and leads to vendor lock-in along with fragile and non-scalable solutions. Besides vendor lock-in, such approaches also prevent knowledge, expertise, integrations, and code from being centralized and institutionalized. It is imperative that for centralizing and institutionalizing cloud integrations into code it is necessary to minimize or eliminate the use of cloud vendor specific management tools in multi-cloud and hybrid cloud environments.
The question that naturally arises is how to create a solution that works across multiple cloud vendor stacks when no two vendors are equal. Would abstraction lead to loss of functionality, resulting in software that delivers the lowest common denominator for capabilities?
In the quest to address this challenge, it is important to first understand the entire cloud context. This is where a cloud ecosystem approach that defines the various participants and their roles within the ecosystem offers hope of a proactive, cloud agnostic, and universal approach. In 2014, The Open Group created the Cloud Ecosystem Reference Model [2]. What follows is a quick overview of this reference model along with how it can be used to address the challenge.
Cloud Ecosystem Reference Model
Enterprises have long recognized the need for business agility. When combined with existing enterprise architectures, cloud services and solutions not only promise to provide greater business agility while reducing cost, but they also address any gaps in an enterprise’s capabilities. To deliver this agility and cost saving, it was necessary to build an enterprise architecture for the cloud ecosystem. In 2014, The Open Group created the Cloud Ecosystem Reference Model [2]. As illustrated by the reference model diagram (see Figure 4), the requisite software capabilities can be grouped into the following categories:
- Accounting & Billing Service
- Auditing & Reporting Service
- Availability & Continuity Service
- Compliance & Policies Service
- Consumer Service
- Contract & Agreement Service
- Metering Service
- Order Service
- Service Demand Service
- Subscription Service
- Capacity & Performance Service
- Incident & Problem Handler Service
- Inter-Cloud Connection Service
- IT Asset & License Service
- Rapid Provisioning
- Service Life Cycle
- Service Orchestration
- SLA Compliance Service
- Template Service
Supply Services, including:
- Product Catalog Services
- Resource Catalog Services
Cloud Security Services, Performance Services, and Interoperability & Portability Services are also included. In the interest of brevity, we will focus only on management services and supply services in this white paper. Detailed definitions can be found in the referenced source [2].
Figure 4: The Open Group Cloud Ecosystem Reference Model
Applying the Cloud Ecosystem Reference Model
The ecosystem reference model can serve as the architecture for software that automates many of the business support, operational support, security, performance, interoperability, and service supply services. A new breed of software, cloud ecosystem management software, provides these services and integrates various components of the cloud ecosystem in a vendor-agnostic manner, which can help address the challenges enterprises face in managing their multi-cloud and hybrid-cloud architectures.
Integration is a fundamental problem in any digital ecosystem. In cloud ecosystems, it takes on a whole new meaning with hundreds of different cloud services from hyperscalers to thousands of services, if you include SaaS vendors. It is a problem that not only needs to be addressed by any ecosystem platform, but it also needs to be solved in a way that makes integration low-code, scripted, abstracted, configurable, reliable, scalable, and secure. A complementary approach is to offer platform on-boarding APIs that can be used by cloud vendors to integrate with the ecosystem platform. However, cloud vendors may need business incentives to undertake the integration work, so it is initially preferable to build these integrations into the ecosystem platform out-of-box.
Low-Code, Scripted, and Configurable API-Based Integrations
Adopting a low-code, scripted, and configurable meta-data driven approach to API-based integrations makes the ecosystem platform easier to integrate with hundreds or thousands of cloud services. Low-code means that many aspects of integration, such as connection setup, connection thread pools, communication protocols, authentication models, and interface code generation from Swagger/Open APIs or using provider API SDKs, are already baked into or configured in the platform. That leaves development resources available to focus on coding cloud domain and provider specific functionality.
Figure 5: Integration Framework
Figure 5 shows a low-code integration framework that leverages meta-data driven code generators (domain object factory and service factory) to reduce the integration effort involved in onboarding a new cloud API. There are two main scenarios: (a) when the cloud API provides an SDK; (b) when no SDK is available for the cloud API. In the latter scenario there is a little more effort, but the framework effectively generates an SDK (coded once) so that the rest of the integration pattern remains unaffected.
UI Objects generated by the code generators can be used by UI Widgets (cloned from existing cloud integrations) to display data on dashboards by executing backend scripts that make outbound API calls to cloud APIs. Scripting is a powerful technique that provides flexibility without having to rebuild the platform code. Vendor real-time operations shown in Figure 4 are implemented using scripting.
Besides invoking cloud API operations in real-time to support dashboards, there are other types of integration operations where data needs to be persisted within the ecosystem platform. For example, ordering and provisioning operations often require multiple cloud API requests with stateful updates to domain objects. Such integrations can be supported using configurable workflow management capabilities. In addition, software abstraction can be used to separate vendor specific objects and functions from vendor agnostic objects and functions to minimize the amount of integration specific code required.
Cloud Agnostic Software
At a high level, we must divide ecosystem platform software into two parts—cloud agnostic software and cloud vendor-specific software—where cloud agnostic software deals with management objects that are abstracted from any cloud vendor, and cloud vendor specific software solves a problem using cloud vendor specific services. For example, Order Service (a business support service) can support ordering any cloud vendor’s services using a product catalog via rapid provisioning and service orchestration (both being operational support services), while the cloud vendor specific software would leverage Amazon’s EKS APIs or Azure AKS APIs to create a K8s cluster. Such an approach does not suffer from the lowest common denominator problem mentioned above. Certain solutions on the market take the lowest common denominator approach by creating a common blueprint that can work across multiple clouds, but such approaches cannot keep up with the pace of innovation of hyperscalers and the differences in capabilities offered.
By applying the principles of low code, scripting, configuration, and abstraction to all cloud interfaces and building each of the different business support, operational support, supply side, security and performance services, a cloud ecosystem management platform (CEMP) can be created. A CEMP addresses the major IT trends towards multi-cloud adoption and product centricity identified earlier. Supply side services essentially codify product centricity by providing a catalog of offers. The CEMP captures the agile nature of the cloud where different components of the ecosystem come from different sources and providers, but they must all co-exist in a smoothly functioning system. It is important to note that with the paradigm shift towards cloud computing, even physical hardware (bare-metal servers) is included in the ecosystem and must be supported by a CEMP.
Scaling Requirements
Large organizations using hyperscaler services often have thousands of accounts/subscriptions and use hundreds of different cloud services across IaaS, PaaS, SaaS, or AnyAAS. The ecosystem platform should seamlessly scale to handle the load; it is therefore imperative that the platform offers ways in which each interface can be tested at scale. However, testing at scale is a challenge since cloud vendors often charge for API usage and/or limit the number of requests per hour. An approach to address this challenge is to provide the ability to emulate cloud services for load and performance testing.
Extensible Platform
Like most ecosystems, the cloud ecosystem is not static. This means that CEMP capabilities and integrations will need to evolve over time. While many changes can be handled through configuration, low-code updates, or scripting, new capabilities may require development at the platform level. It is therefore imperative that the CEMP offers an SDK (Software Development Kit) to be used by developers to add or customize platform capabilities.
Future of Integrations
Because integrations are the lifeblood of a cloud ecosystem, it is imperative to understand how integration technology may evolve in the future. In his book, Flow Architectures [5], James Urquhart argues that the future of software integration is in event driven streams (known as Flows) that will ultimately lead to the creation of the Work Wide Flow (WWF), similarly to the way the World Wide Web evolved from HTTP. Flow interfaces and protocols will handle all aspects of setting up a connection, managing the flow of data, and identifying the type of payload, encryption, authentication, etc. However, consumer processing of the data received would still be payload dependent and require payload specific code to handle. Streams-based integration technology, which is very much in the early stages of maturity and adoption, offers a glimpse into how integration might look like in the future. AWS EventBridge and Lambda functions are some early examples of streams-based integrations. However, even with streams-based integrations, the payload that is received by the integrating party must still be processed. So, the approach identified earlier that leverages software abstraction would still be necessary.
Cloud Ecosystem Management Platform (CEMP)
A CEMP implements the capabilities defined within the ecosystem reference model, while considering the requirements for low code, scripted, configurable, and abstracted integrations. The platform would need to support multiple tenants and be highly scalable, secure, highly available, and able to be deployed on-premises or in the cloud. These software capabilities are essential to enterprises for successful multi-hybrid-cloud adoption and repeatable digital product delivery at scale.
The Open Group’s Cloud Ecosystem Reference Model can be mapped into three high-level areas of CEMP functionality: cloud provisioning, cloud operations, and cloud governance.
Cloud Provisioning
CEMP should act as an agnostic cloud service broker—providing self-service order management services, workflow management, rapid provisioning and orchestration, and service lifecycle management across IaaS, PaaS, SaaS, etc. (AnyAAS).
Within a CEMP storefront or marketplace, cloud agnostic order services facilitate self-service rapid provisioning and orchestration. CEMPs leverage cloud native resource deployment blueprints (i.e., AWS CloudFormation, Azure ARM, GCP Deployment Manager, Oracle Resource Manager, VMware vRA Blueprints, etc.) to rapidly provision resources in the cloud. Dedicated CEMP cloud provisioning services inspect templates from each cloud provider and abstract them into the centralized product catalog. Providing vendor dedicated cloud provisioning services leveraging native templating delivers best-in-class capability, ensuring CEMP users can always take advantage of the latest cloud innovations (without suffering from the lowest common denominator of cloud service abstraction – as discussed above).
Once onboarded, these cloud services are productized as offers by the CEMP complementing them with vendor agnostic roles-based self-service, order configuration, cost/pricing, and business process automation. By productizing these services as configurable digital products, we can easily deploy and redeploy them across a varied spectrum of end user, customer, and industry use cases.
Cloud Operations
CEMP should provide management tools for IT operations and financial-operations (as companies move away from projects to products and include infrastructure costs as part of the digital product portfolio), such as a single-pane-of-glass for performance and availability monitoring, cloud events and alerts, and rolled up costs by service, etc.
Without CEMP, cloud service lifecycle management is fraught with intense manual white-glove services requiring human resources to switch between multiple cloud interfaces, consoles, and ITSM systems to fulfill service requests and monitor resources.
To fulfill service requests, CEMP embedded workflow services support service orchestration and lifecycle management across IT infrastructure and financial operations. With CEMP workflow, cloud service lifecycle activities from initial creation and ongoing management through decommissioning are automated with defined business processes. In this way, leading CEMPs are often viewed as the “Orchestrator-of-Orchestrators,” facilitating the business process across supporting systems and tooling thereby greatly minimizing manual intervention.
Within CEMP, centralized performance and availability monitoring is essential. Leading CEMPs provide a flexible single-pane-of-glass (SPOG) that, again, takes advantage of vendor-specific and vendor-agnostic software approaches. Like the modern approaches for service catalogs and rapid provisioning we have discussed, CEMPs create vendor-specific discovery services that consume monitoring and observability information via API, synthesize it through a governance model, and display the information in an abstracted SPOG UI/UX that can vary across user personas.
Cloud Governance
CEMP should centrally manage identities, permissions, roles, accounts, and policies for access to cloud resources/entitlements facilitating compliance/audit reporting and usage metering (cost and billing).
CEMPs provide a centralized governance model in which cloud resources are bound directly to the individual identities that are responsible for them. This governance framework and organizational model provides a 360° view of cloud resources, their utilization, cost, and compliance.
A governance model’s core foundation is the understanding of the organization’s identities, projects, budgets, departments, and other hierarchical business units. Leading CEMPs auto-discover this model from existing sources of identity or organizational hierarchy (e.g., 0365/AD, CMDB, ITSM, etc.) and dynamically manage it as it evolves. By centralizing the acquisition of new cloud resources in the self-service storefront or marketplace discussed above, all new resources are organized and accounted for appropriately.
Based on the profile of the user(s) in the system, CEMPs enforce compliance and security standards via locale, project assignment, permissions, and other organizational characteristics. For example, CEMPs can enforce a GDPR compliant architecture for a developer ordering infrastructure assigned to a Customer Relationship Management (CRM) project working with clients in the EU by deploying an infrastructure resident in an EU region datacenter.
To support accounting and billing services, CEMPs aggregate costs and monitor/meter usage to adhere to budgetary restrictions. With costs properly accounted for, internal chargeback/show back, or customer billing, can be automatically reported directly to the responsible financial/billing systems. Advanced CEMPs allow for the implementation of detailed price books that aggregate—in addition to raw cost of services from a cloud provider—labor costs, software costs, and other contributing costs for delivering digital cloud products. In go-to-market scenarios, these price books may include additional markup on products and services establishing a cloud service monetization platform.
CEMP High-level Architecture
Figure 6: High level architecture of a CEMP
UX Portals
The platforms consist of a UX layer to provide different views and the capability to support various user personas within the enterprise cloud ecosystem. These “portals” commonly include (at a minimum) a storefront or marketplace experience for end users, governance or compliance portals for operations personas, and an administrative portal system/app managing users and developers.
In line with the low-code / no-code expectations of a CEMP, user experiences (UX) need to be highly configurable (no-code), customizable (low-code), easy to manage, and easy to deploy. Advanced CEMPs (resembling leading PaaS like Salesforce or ServiceNow) provide no-code, WYSIWYG tools to “configure” a user interface. To accomplish this, the CEMP will have a designer or studio palette to drag-and-drop user interface (UI) building blocks on to a page and configure them with metadata fields. This UX builder will provide enterprises the ability to white label the application with their brand specifications and resources (logos, styles, colors, fonts, etc.). To accomplish this, advanced options should be provided in the form of low-code customizations. As configuring users make no-code and low-code changes to these interfaces, the experiences are instantly available with a simple refresh of a browser window without any lengthy code deployments, staging, or promotions.
Microservices
We have discussed the importance of separating CEMP software into two parts: cloud agnostic software and cloud vendor-specific software; providing a modern microservices architecture is imperative to achieving this. Leading CEMPs abstract cloud agnostic capabilities into a set of platform microservices and build integration microservices to support vendor-specific services. The diagram above shows many of the management and supply services outlined in the Open Group’s Cloud Ecosystem Reference Model as vendor agnostic microservices. In contrast, you can see vendor specific integration microservices (summarized into cloud, development, and operations) to support and leverage key provisioning, operations, and governance capabilities from cloud providers and supporting ecosystem tooling (i.e., configuration and monitoring tools, etc.)
Again, given the importance and wide variety of the integrations needs of cloud ecosystem management, vendor-specific microservices and their integrations need to be architected to support low-code rapid onboarding extensible and consumable via a well-documented SDK.
Through Cloud Provisioning, Operations, and Governance, CEMPs can transform the way enterprises deliver and manage cloud and digital products. CEMPs aim to provide a centralized suite of services that realize many of the requirements outlined in The Open Group’s Cloud Ecosystem Reference Model. Enterprises implementing CEMPs are reducing costs and dependence on human resources, productizing cloud service delivery, and innovating faster than their competitors.
Conclusion
A cloud ecosystem management platform (CEMP) based on The Open Group’s Cloud Ecosystem Reference Model is a superior approach to managing cloud services and digital products when compared with other approaches. CEMPs federate, codify, and institutionalize cloud integrations, provisioning, orchestration, governance, and operations. CEMPs address the needs of IT DevOps teams, FinOps, App teams, Support (SRE) teams, Partner teams, and business leadership by providing a wholistic view of cloud services and digital products. Enterprises can develop or purchase a cloud ecosystem management platform to successfully manage their multi-cloud, hybrid-cloud, and digital product initiatives.
Author Bios
Sash Purohit is the Chief Technology Officer for the Innova Solutions product portfolio based in Dallas, Texas. He is a passionate technology evangelist, entrepreneur, inventor, and information technology executive with over 25 years of experience with cloud and telecommunications management systems. Purohit has built and delivered complex software systems for Tier One telecom companies across the globe, with teams ranging from startup-size to hundreds of engineers as part of multiple digital transformation initiatives. At Innova, he drives product engineering as part of the Global CTO office, while working with internal teams responsible for delivering cloud services to customers.
Justin Carlson is the Vice President of Product Development at Innova Solutions and leads the team responsible for developing cloud products & cloud managed service (MSP) solutions. Throughout his career, Carlson has built and guided highly cross-functional teams and managed product development processes from ideation to go-to-market. His expertise is focused on product management and enterprise SaaS, having previously built market leading software in governance, risk, and compliance (GRC.)
References
- Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, Mik Kersten, November 20, 2018
- The Open Group Cloud Ecosystem Reference Model, Open Group Standard, Document Number C141, January 2104
- A Digital Product-Centric Reference Operating Model, The Open Group White Paper, October 12, 2022
- The Shift to Digital Product, A Full Lifecycle Perspective, The Open Group White Paper, Mark Bofman, ServiceNow and Dan Warfield, CC&C Europe, December 2020
- Flow Architectures: The Future of Streaming and Event-Driven Integration. 1st Edition, James Urquhart, O’Reilly Press
