DELL Technologies: The Layer In Between

DELL Technologies: The Layer In Between

In a previous post I used the diagram below to highlight two Dell Technologies organizations:

  1. DELL Client, which possesses a set of “endpoint” technologies
  2. DELL EMC, which possesses a set of “cloud infrastructure” technologies

The interplay between these two technology layers has the potential to form a next-generation Digital Business Platform that treats data as a capital asset. The diagram below also communicates that pre-acquisition assets from the two companies have joined and intermingled into these two new organizations.

DELLTechnologies

EMC has certainly contributed technologies into the “Endpoint Technologies” category. Before the acquisition, however, EMC’s ability to monitor and control these endpoints was limited. This left the company at a disadvantage in its ability to influence the internet of things and people (IoT&P) in an automated fashion.

DELL has certainly contributed technologies into the “Cloud Infrastructure” category. Before the acquisition, however, Dell’s ability to ingest, analyze, store,  and protect the broadest span of enterprise workloads was limited. This was a disadvantage for making immediate (data-centric) business decisions in an automated fashion.

By overlapping the two company’s technology portfolios, however, a picture can be drawn showing the solution to two of the biggest business challenges of the 21st century: (a) creating data capital out of the volume, variety, and velocity of incoming data, and (b) using this data capital to actuate real-time business decisions. The two high-level organizations can combine to form a system that can be described as a Digital Business Platform for data capital:

DT DBP

The diagram above highlights the following:

  1. DELL Technologies’ endpoint capabilities capture unstructured (analog) data that is ingested into a cloud infrastructure.
  2. A data pipelining process begins (typically all in-memory data manipulation) to transform the analog data into a digital format that is suitable for decision-making. Once the formatting is complete the analog data has been turned into “data capital” that has business value.
  3. The data is then put to work (e.g. as input into analytic models).
  4. A business decision is arrived at by using (in part) the data capital. The goal is for this decision to be implemented automatically (as soon as possible).
  5. The decision is actuated via programmatic control: the calling of actuators that communicate to people (e.g. social media) and things (e.g. thermostat controls).

The diagram above explains, at a high level, the architecture required to stimulate business outcomes based on incoming data. A drill-down on either level of the diagram (the top or the bottom) would be useful, and I plan to spend some time drilling down in future posts.

But this simplistic architecture presents to the reader an immediate problem: it looks and feels too much like a client/server architecture and does not take into account the geographic distribution of endpoints and cloud infrastructure.  In other words, there is an architectural need to describe the interplay between the endpoints and multiple underlying cloud infrastructure instantiations.  This architectural component is described below as the “Cloud Services” layer.

CloudServices

The Cloud Services portfolio between the two companies is enormous, so large in fact that I will dedicate an upcoming post to drilling down into the variety of available services.

Steve

https://stevetodd.tech

Twitter: @SteveTodd

Dell Technologies Fellow