Classifying Company Business Archetypes

Hello. Last lesson mapped the industry by functions: infrastructure, applications, distribution, and the services that connect them. A company can occupy several positions on that map. This lesson turns the map into a way to classify firms without mistaking a product feature—or a corporate description—for the business itself.

You will learn to distinguish enterprise software, cloud, multi-sided platforms, AI-native businesses, and infrastructure providers, then decide when hybrid is the more honest answer. The purpose is not to memorize labels. It is to choose the right starting point for competitor analysis and client discussions. Allow about 40 minutes, including the video and readings.

1. Classify the business at a stated level

“Is this a platform company?” sounds like a straightforward question until platform means three different things: software for developers, a marketplace connecting participant groups, or an entire corporate ecosystem. Before assigning an archetype, state what you are classifying: a service, a business line, or the corporation.

For example, a cloud division may have a clear cloud archetype even when its parent company also sells applications and operates a marketplace. Conversely, an enterprise software vendor might call its product a platform because customers can build on it; that does not establish that the firm operates a multi-sided market.

Use four questions in order:

1. What capability or exchange does the customer obtain? A finished business workflow, computing capacity, a connection to another participant group, an AI-generated result, or a physical input?
2. Who must participate for the offer to work? Is the provider chiefly serving a customer, or coordinating distinct groups whose participation affects one another?
3. What does the firm control and operate? Consider the application, model, rules of exchange, cloud service, physical asset, and route to customers—not merely the technology it purchases.
4. Is more than one mechanism central to the business? If so, identify a primary archetype and material secondary ones, or classify the firm as a hybrid.

The first answer is a working classification, not an immutable identity. It should tell you which evidence to investigate next. “Cloud provider” directs attention to workloads and service responsibility; “multi-sided platform” directs attention to participant groups and exchange rules. Later lessons will examine their economics in detail.

These categories are deliberately not all the same kind of label. Enterprise software describes a customer-facing use; cloud describes a mode of supplying computing capabilities; multi-sided platform describes an exchange structure; AI-native describes how the core proposition is built; and infrastructure identifies foundational inputs. Their overlap is analytically useful rather than a flaw to eliminate.

2. Separate enterprise software, cloud services, and physical infrastructure

The hardest boundary in many enterprise cases is not whether software uses the cloud—it usually does—but what the customer is actually being provided. Watch this short comparison of service models with that question in mind.

The visual is helpful, but IaaS, PaaS, and SaaS classify services, not entire corporations. NIST makes that distinction precise. Read its criteria rather than trying to turn the three models into a corporate taxonomy.

The practical distinctions are these:

An enterprise software business primarily sells organizations a usable application: a workflow, record-keeping capability, creative tool, or other business function. Some such applications are SaaS; others need not be. The customer can configure a SaaS application, connect it to other systems, and perhaps extend it through APIs. Those options do not automatically make its principal offer PaaS. The decisive question is whether the customer is chiefly using the provider’s application or developing and deploying its own application.

A cloud service business supplies computing capabilities to other operators of workloads. At the IaaS end, the customer can provision resources such as compute, storage, and networks and run a range of software on them. PaaS takes on more of the development or deployment environment. A provider can sell both, alongside its own SaaS applications. Calling that provider simply “IaaS” would hide part of its business.

An infrastructure provider supplies a more foundational input: for instance, processors, servers, data-center space, or connectivity. A chip designer does not become a cloud provider because cloud firms buy its chips. A colocation operator leasing data-center space does not necessarily provide a customer with an IaaS environment in which it can provision virtual resources. The distinction matters commercially: selling scarce physical capacity and operating an on-demand software-defined service involve different customers, responsibilities, and constraints.

A useful boundary case is an enterprise workflow vendor with a substantial developer toolkit. If customers primarily buy its ready-to-use workflows, enterprise software remains a defensible primary label. The toolkit may be an important secondary capability. If a separate offering primarily enables developers to deploy their own applications, classify that offering as a platform service. Do not let the word “platform” make the decision for you.

3. Identify a multi-sided platform by its exchanges

For a multi-sided platform, the key fact is neither cloud hosting nor the presence of an app. It is intermediation between distinct groups. Read the OECD’s definition and its account of ecosystems before considering company examples.

An online marketplace connecting independent sellers and buyers is an intuitive example. Sellers value access to buyers; buyers value relevant sellers and their offerings. The operator determines matters such as entry, visibility, transaction rules, and dispute handling. A social or advertising platform may coordinate creators, audiences, and advertisers instead. What the groups exchange differs, but the classification logic is similar.

Contrast that with a vendor selling an application to thousands of enterprise customers. More customers may improve the vendor’s finances or generate data for product improvement. That does not alone establish a multi-sided market: the customers need not be obtaining value from transactions with a distinct group coordinated by the vendor. Likewise, an API or an app gallery is evidence of possible platform activity, not conclusive proof that it defines the whole business.

A sharper test has three parts:

• Name the sides. “Users” and “more users” are not enough; specify the distinct participant groups and what each seeks.
• Describe the dependence. Why would the presence or quality of one group change the other group’s willingness to participate?
• Find the operator’s rules. What does the firm govern—access, discovery, matching, exchange terms, or trust?

This test avoids misclassifying a payments processor merely because merchants and shoppers are both present in a card transaction. You would need to establish whether the specific business being classified operates and governs an exchange between participant groups, or instead supplies processing technology into an exchange governed elsewhere.

It also helps with a subtle case: merchant-enablement software versus a marketplace. Both support commerce, but a firm helping individual merchants operate their own stores is not necessarily pooling buyer demand and matching buyers with sellers on its own marketplace. A company may have substantial activities in both categories; the exchange test tells you which activity you are describing.

4. Decide whether AI is native to the proposition—and whether one label is enough

“Uses AI” is a weak classification rule. A mature software vendor can add powerful AI functions to its existing application. An AI-native venture might buy foundation-model access rather than train a model itself. Neither the vendor’s age nor ownership of a model settles the question.

For this course, use AI-native when AI is indispensable to the core result the customer buys and the business is organized to deliver and improve that result around AI capabilities. Consider a support-workflow supplier. If its main product remains a conventional ticketing system with an optional drafting feature, “enterprise software with AI features” is initially more precise. If its primary proposition is resolving support work through AI, with workflow design, evaluation, human controls, and operating costs built around that capability, “AI-native application” may be defensible—even if it rents model access and compute. Those are illustrative judgments, not certifications.

The supplied scorecard is useful because it separates AI assistance in individual functions from a more comprehensive AI-native business model. Read it as a diagnostic illustration, not a universal threshold that assigns companies to archetypes.

Notice the uneven profile: a company could be advanced in AI-powered operations while its customer proposition, revenue model, or channels change much less. The sample’s overall score combines chosen weights; a different strategic question might require different emphasis. For classification, ask where AI is essential to customer value and the operating model, rather than accepting an overall score as proof.

Now add the hybrid question. A hybrid archetype is appropriate when more than one business mechanism is material at the scope under review. A corporation can operate enterprise applications, cloud services, and a multi-sided marketplace; a model provider might also sell an AI application and developer access. “Hybrid” should not mean “too complicated to examine.” State its components: for example, enterprise software plus cloud services, or AI-native models and applications with a developer-facing service.

Nor should every complementary feature force a hybrid label. A minor add-on marketplace may strengthen an enterprise software product without becoming a coequal economic engine. Evidence of materiality might include a distinct customer group, a substantial line of business, independent demand for the offering, or a strategic control point that changes how the firm competes. These are prompts for investigation, not fixed numerical thresholds.

Finally, keep hybrid company distinct from hybrid cloud. The latter describes a deployment composition involving distinct cloud infrastructures. It does not tell you whether the provider’s company combines software, marketplace, and infrastructure businesses.

5. Turn the label into a defensible company profile

Here is how the method handles familiar names at different scopes. The labels are starting hypotheses for analysis, not claims that every activity of these firms has been captured.

When preparing a brief for a senior discussion, make your conclusion auditable in one paragraph. State the scope and date of classification, the primary offer and customer, your primary and secondary labels, and the fact that would most likely change your judgment. For the hypothetical support vendor, that last fact might be whether customers chiefly buy automated resolution or a conventional workflow product with AI attached. For a merchant technology firm, it might be whether it controls a shared buyer–seller discovery and exchange venue or principally equips merchants to serve their own customers.

This discipline is more valuable than debating terminology in the abstract. It exposes where evidence is missing and prevents a competitor set from being built around superficial similarities. An enterprise application, its cloud supplier, and a marketplace through which it is distributed may all be called “platforms,” but they need not be direct competitors.

Conclusion

Classify the stated business at the stated scope, not its logo. Enterprise software supplies applications for organizational work; cloud businesses supply computing and development capabilities as services; multi-sided platforms govern exchanges among participant groups; AI-native businesses make AI integral to their core proposition; and infrastructure providers supply foundational inputs. Use hybrid when multiple mechanisms are genuinely material, and name them.

The most useful label is one that identifies the right economic questions while remaining open to contrary evidence. Next, we will take these archetypes into revenue analysis: subscriptions, consumption, transactions, advertising, services, and hardware can coexist within one company, but they reveal different ways its businesses capture value.