Foundry：集中したデータから顧客成果へ

Key points from this chapter

This chapter uses the speaker's explanation of Palantir's Foundry to examine how a data platform supports a customer's work. The important point is that gathering data in one place is not the final goal by itself.

What customers really want is not organized data as such, but results in their work that come from using that data. For example, they may want to place products on the right shelves or make sales flow faster. The speaker therefore explains an approach that combines a software product with a service that understands the customer's situation and implements a solution.

Think of Foundry as three layers

In the speaker's simplified explanation, Foundry is a software platform that gathers an organization's data, organizes its meaning, and supports building applications on top of it. Here, a platform is not just one particular screen. It is a shared technical foundation that can serve multiple customers and use cases.

The flow can be written simply as follows.

1. Gather data that is split across the organization
2. Give that data business meaning
3. Build applications using the meaningful data
4. Produce business results for the customer through the applications

1. Gather the separate tables

A company's data is not always in one form from the beginning. Information about sales, inventory, customers, and logistics may be stored in separate tables or systems. Even when two systems refer to the same product, their names or IDs may differ.

The speaker presents the idea of gathering these multiple tables in one place and creating a single source of truth that the whole organization can consult. This allows everyone to make decisions from the same data.

However, putting data in one place does not yet make its business meaning clear. Even if the numbers are together, users cannot directly use them in their work unless it is clear which product they refer to and how they relate to customers or orders.

2. Name the business objects

This is where an ontology is used. In the simplified sense used in this talk, an ontology is a way to give names and relationships to the business objects in data. For example, it identifies objects such as products, stores, orders, and customers and handles how they are connected.

There is an important limitation here. The speaker does not explain Foundry's actual data structure or every technical meaning of ontology. This chapter stays within the explanation that separate tables are organized into objects that are easier to understand in business work.

Example (for explanation):

• Treat A-17 in the inventory table as Product A
• Treat S-03 in the store table as the Tokyo store
• View how many Product A items are in the Tokyo store and how many were recently sold within the same set of relationships

The important point in this example is not simply adding columns. It is enabling users to think about data in business terms such as product and store. This makes it easier to build the next application without decoding the technical differences between tables every time.

3. Build applications

Once the data and the relationships among business objects are organized, applications can be built on top of them. The application layer is the part that displays or analyzes data and carries out business procedures.

For example, you can build a screen that shows inventory and sales conditions for each store. Instead of requiring users to manually compare the inventory, sales, and store tables, the screen uses information that has already been organized. In this sense, an application is a concrete work tool built on the data platform.

Organizing data is not yet a customer outcome

This is the speaker's central point. Organizing data and creating a single source of truth has value. However, customers usually do not decide to buy simply because the data will be neatly organized.

Customers want to use that organized data to solve business problems. As examples, the speaker mentions deciding which shelves should hold products and increasing the volume or speed of sales operations. In other words, customers want a change like the following.

Data is gathered in one place → The business objects and their relationships become clear → A useful application runs → The customer's business results improve

Without this final arrow, the customer may end up having only installed the platform's capabilities. Gathering data is a means. What customers evaluate is how their work changed because of that means.

The adoption burden on the customer

Even when a platform has useful features, customers may not get results immediately. The speaker points out that customers pay for the platform, train people to learn how to use it, and only then can people inside the company build useful applications.

Here, this burden is called the adoption tax. The word tax is a metaphor for the time and effort required for adoption in addition to the product's price. At minimum, the customer's burden includes the following.

• The cost of buying the platform
• Time to prepare the data and adapt it to the organization's situation
• Training for employees to learn how to use and build with it
• People needed to build the actual applications and business workflows

Providing training alone does not remove this burden. People who receive the training still have to understand their own work, handle the data correctly, and finish the necessary applications. Especially with a technically deep platform, knowing its features is not the same as producing results in the customer's business.

Example (created by the teacher):

Suppose a retailer buys a platform that combines inventory and sales data. Even after employees receive training, a screen that helps them decide which products to move to which stores will not appear automatically. Employees must check what the data means, understand the stores' work, and build the screens or processing. If nobody can carry out that work, organized data will not improve shelf placement or sales.

This example was created by the teacher to explain the structure of the speaker's argument. It is not a claim that this result actually occurred for a particular customer.

How to combine products, services, and outcomes

It is easier to understand this discussion by distinguishing three ways of selling.

Sell a software product

As a product, the platform provides a way to gather data, organize its meaning, and build applications. It is a reusable technical foundation. However, customers may not be able to create results on their own from that foundation.

Sell people's working time

At the other extreme, if people are sent to each customer only to do work for that customer, the offering comes close to providing engineers' labor. This approach can respond easily to each customer's situation, but if everything is built from scratch each time, it becomes difficult to maintain later. This model is close to a simple development company or contract development.

Deliver the customer's business outcome

Customers usually want neither the product itself nor working hours themselves, but the business outcome that results from them. The approach the speaker describes combines a product and a service in order to achieve that outcome.

The platform provides a shared technical foundation. People on the service side understand the customer's work and move forward with the necessary configuration and application building. This means customers are not required from the start to learn how to use the platform and build everything entirely by themselves. At the same time, the provider does not need to create a separate technical foundation for every customer.

Therefore, this model is neither software alone nor simply lending people. It combines a reusable product foundation with a service that implements a solution for the customer's situation. A later chapter will look more closely at how the customer-facing software engineers who provide this service work.

Common misunderstandings

Misunderstanding 1: Organized data automatically creates value

Even when data is in one place and the objects have names, the customer's work does not improve automatically. Users must build the applications they need and use those applications in their actual work. A data platform is an important foundation, but it is not the outcome itself.

Misunderstanding 2: Training lets customers adopt it by themselves

Training helps with adoption. However, customers need both knowledge of their business and the ability to implement with the platform. The challenge continues through making the desired improvement concrete, connecting the right data, and turning it into something usable in real work.

Misunderstanding 3: All customer-specific work is contract development

The existence of customer-specific implementation does not mean that a separate system must always be built from scratch. In the speaker's explanation, a shared platform exists, so the customer solution is built on top of it. The important point is to balance the individual nature of the service with the reusability of the technical foundation.

What this chapter establishes

The speaker's explanation can be summarized as the following causal chain.

1. An organization's data is split across multiple tables or systems.
2. A platform such as Foundry gathers the data and organizes the business objects and their relationships.
3. Applications used in the customer's work are built on the organized data.
4. Customers want business results such as better shelf placement or faster sales flow, not organization by itself.
5. Reaching those results may require not only the product but also a service that understands the customer's work and implements a solution.

The customer examples and value explanation here are based on the speaker's account. This talk alone cannot verify the details of Foundry's actual architecture or the results for individual customers. The next chapter examines what combinations of products and customers require this kind of customer-facing engineering.