Mapping the Software & Platforms Industry Stack

Hello. This module builds an industry map you can use to place competitors, suppliers, partners, and potential bottlenecks before analyzing individual companies. Today’s task is to trace the stack from chip inputs to the services that make software useful—and to recognize where the familiar picture of a neat, linear value chain breaks down.

The six-category graphic you supplied is a useful starting inventory of providers. It does not, however, show much of the semiconductor supply chain, and its boxes can make firms that span several layers look like they belong in only one. We will build a map that works for enterprise software, consumer platforms, cloud providers, and AI-native businesses alike. Allow about 40–45 minutes, including the short readings and video segments.

---

1. Start below the server: semiconductors and systems

An application ultimately runs on physical equipment, whether that equipment is in a customer’s building, a cloud data center, or a user’s device. “Chip supplier” is too broad a label to explain this foundation. The firm designing a processor, the firm fabricating it, and the firms supplying memory, manufacturing equipment, and packaging may all be different.

Watch this overview first. It uses an AI accelerator—a demanding example—to make the division of labor visible; the same types of roles matter beyond AI.

The central distinction is between designing a chip and manufacturing a chip. A fabless designer specifies what a chip should do and develops its design; a foundry turns a manufacturable design into silicon. Other specialists supply reusable chip-design intellectual property, electronic design automation (EDA) software, fabrication equipment and materials, memory, and packaging or test capacity. A finished processor still needs to be integrated with networking, storage, power, cooling, and software before a customer can use it.

The following report gives you a more general map than the accelerator example. Its Exhibit 5 is deliberately simplified, which makes it useful for identifying roles without getting lost in fabrication detail.

For this course, retain three points. First, hardware capability depends on specialized upstream inputs, not just a processor brand. Second, a chip is not a data center: servers and network equipment must be assembled and supplied with facilities, electricity, connectivity, and cooling. Third, supply relationships can be strategically important even when an input represents a small share of the final product’s price. Later modules will examine semiconductor control points and AI-compute capacity in depth; for now, we need their positions on the map.

---

2. From physical capacity to cloud infrastructure

A data center provides physical capacity. An infrastructure provider makes some of that capacity usable by customers, often supplying compute, storage, and networking on demand. A customer might instead own equipment, lease space in a colocation facility, or combine these arrangements. Public cloud is therefore a major delivery model for infrastructure, not a synonym for all infrastructure.

Above basic compute and storage sit services that remove work from application teams: databases, identity services, developer environments, data processing, monitoring, and other managed capabilities. The boundary is commercial as well as technical. A provider offering a managed database is taking responsibility for some tasks that a customer would otherwise perform, while gaining another point of contact with the customer’s workload.

This is where the word platform needs care. A cloud platform service is a building block on which developers run or build software. A multi-sided platform connects participant groups—for example, merchants and buyers—and governs their exchanges. One company can do both, but they are not the same industry layer.

Read the software value-chain account with that distinction in mind. It places infrastructure, development tools, publishers, distribution, and engineering services in one view; our map will adapt it to include the semiconductor foundation and AI.

Here is the resulting working map. The rows describe functions, not mutually exclusive company categories.

Position in the stack	What it contributes	Illustrative participants
Semiconductor inputs and production	Chip IP, design tools, designs, fabrication, memory, packaging, and test	Arm, NVIDIA, TSMC, memory suppliers
Systems, facilities, and connectivity	Servers, networking, data-center space, power, cooling, and network access	Equipment makers, colocation firms, network providers
Compute and cloud infrastructure	Usable compute, storage, networking, and related capacity	AWS, Microsoft Azure, Google Cloud, private infrastructure operators
Software-building and data capabilities	Developer tools, databases, APIs, identity, data services, and managed platforms	GitHub, database vendors, cloud platform services
Applications and digital experiences	Software that performs an end-user job or enables an interaction	ServiceNow, SAP, Adobe, a marketplace application
Distribution and customer access	Discovery, sales, procurement, installation, and access to users or buyers	Direct sales, app stores, cloud marketplaces, partners
Implementation and ongoing services	Integration, customization, migration, support, and operations	Internal teams and external service providers

The table is a map of roles, not a compulsory route to market. A mobile app and an enterprise system may rely on similar underlying compute while reaching customers through very different channels. A company may build its own infrastructure, buy a managed service, or blend both. Services can support chip design, cloud operations, application implementation, or customer adoption; they do not occur only “at the end.”

---

3. Where AI fits—and where it does not

AI adds important capabilities to this map, but it does not replace the layers beneath it. A provider may supply a foundation model; another may supply data preparation, retrieval, or orchestration tools; an application company may combine those components into a workflow that a customer will actually use. Each still depends on compute and must find a route to users.

The IBM Technology video offers a concise vocabulary for this AI-specific stack. Its layers are a view within the broader Software & Platforms industry map, not a separate physical universe.

Suppose a company offers an AI assistant for customer-support staff. Its visible product is an application embedded in a support workflow. Underneath may be a model supplied by another firm, retrieval from approved company information, a database, identity controls, cloud compute, and ultimately data-center systems and chips. It might be sold directly to enterprises, distributed through an existing software ecosystem, or both. An implementation partner may connect it to customer systems.

Calling that company “AI-native” describes something about its product and operating approach; it does not tell you which parts of the stack it owns. It could own the application and workflow while buying model access and compute. That distinction matters when comparing its competitors with its suppliers.

---

4. Applications, distribution, and the customer-facing edge

The application layer is where a user obtains a result: completing a business workflow, creating a document, finding content, or transacting with another participant. Enterprise applications often sit within a customer’s existing systems and data. Consumer and commerce platforms may also coordinate large groups of participants and manage search, matching, rules, or trust.

Getting an application built is not the same as getting it adopted. Distribution concerns how customers discover, purchase, access, and continue to use it. Direct enterprise sales, partner channels, app stores, websites, and cloud marketplaces offer different kinds of reach and customer access. Distribution can itself become a powerful position in the stack when an operator controls discovery or access to an established customer base.

Consider two products that use the same cloud infrastructure:

• An enterprise workflow application may reach a buyer through a sales team and implementation partner. Its usefulness depends heavily on integration into the buyer’s processes.
• A consumer marketplace may rely on a mobile operating system for access to users, while using its own search and matching experience to connect buyers and sellers.

Neither example is explained well by putting the whole company into one box marked “software.” You need to identify both the technology it uses and the route through which it reaches customers. Payments, advertising, logistics, and support may be crucial complements in particular businesses, but they should not be inserted as mandatory stages for every application.

This also prevents a common analytical error: assuming that the firm closest to the end user necessarily owns all the underlying technology. Equally, owning infrastructure does not automatically confer ownership of customer demand. Companies may extend into adjacent layers precisely because that boundary is commercially consequential; we will assess such moves after we have a firmer grasp of each business model.

---

5. Use the map as a set of questions, not a catalog of logos

For industry analysis, a stack becomes useful when it explains relationships. Take any software or platform company and ask:

1. What does it deliver to the end user? Identify the application or exchange, rather than starting with its corporate label.
2. What must work underneath it? Locate its critical chips or devices, systems, infrastructure, data, models, APIs, and developer capabilities as relevant.
3. How does it reach the customer? Separate its product from the channel that supplies discovery, procurement, or access.
4. Who makes it work in practice? Locate internal and external integration, support, and operating services.
5. Which positions does it own, and which does it rent or depend on? Do not infer ownership merely because two capabilities appear together in the customer experience.

That last question gives the map its strategic value. A cloud provider can be an application company’s supplier, distribution channel, partner, and potential competitor in different contexts. An enterprise software vendor can provide an application while also operating a developer ecosystem around it. An AI application can compete on workflow and customer access without producing a foundation model. These are not exceptions to the stack; they are why the stack is worth drawing.

For consulting diagnosis, the same map keeps four kinds of problem distinct. A weak product or route to customers calls for a different investigation from constrained compute capacity. Neither is identical to an integration or ongoing-operations problem. End-to-end transformation may involve all of them, but the dependencies should be made explicit rather than folded into a single “technology” category.

---

Conclusion

The Software & Platforms industry has a physical foundation in semiconductors, systems, facilities, and connectivity. Infrastructure and software-building capabilities make that foundation usable. Applications create customer-facing outcomes; distribution connects them with customers; services help build, integrate, and operate solutions across the stack. AI introduces model, data, and orchestration roles that sit within this broader picture.

Most importantly, a layer is a function, not a permanent label for a company. The map lets you see what a firm owns, what it depends on, and where its partners might also compete. In the next lesson, we will use that foundation to classify company archetypes—including enterprise software, cloud, multi-sided platforms, AI-native businesses, infrastructure providers, and hybrids—without forcing complex firms into a single misleading box.