Architecting Digital Products: Start with the Terms of Use

The Struggle with Digital Products

A Digital Product is fundamentally different because the customer is inside the machine. The product is embedded in activity. The customer often does it activity without us.

Think about ServiceNow—mainstream IT operations platform. The customer uses it to enter their CIs, their application portfolio. If we don't draw the line between product, and don't start with subjects, we face the infinite loop. Nor can we apply our Subjects (Business Activity) inside the product.

CIs were easy. We can clearly see ServiceNow corporation can have a CI used to operate the product and they have nothing to do with what is inside the product. The challenge is data that crosses the line. When the customer is engaged in our business process—when the customer creates a ServiceNow ID used to manage tickets and provide access to the product. That ID is now material to ServiceNow's Security Subject, Billing Subject, Customer Service Subject.

We cross the event horizon when we use data material to the product for our operations. Things are very weird when you cross the event horizon.

Quite simply, don't cross the event horizon.

Explicitly separate the Product Data Architecture from the Enterprise Data Architecture. The moment we start that journey we run into the elephant in the room: The Data Terms of Use.

Are You the Post Office or Facebook?

Separating Product Data from Enterprise Data, brings up the fundamental constraint—what are the terms of use of the data. We use Terms of Use everywhere in Navigate because it gives us the a key architectural constraint. Back in the Service-oriented Architecture days I used the 'bus test' to explain terms of use. A bus is a shared service, with strict terms of use. 1 ticket gets you one rider. 1 ticket at a bus stop gets you one rider on a pre-programed route. That ticket, route, and stop are only useful at scheduled times.

The driver doesn’t ask where you want to go, when you want to arrive, or if you want a ride home. Nor will the driver let a Zebra use the ticket. Clear Terms of Use.

We use a simple, stark comparison in our consulting engagements. When you build a digital product, are we the Post Office, or are we Facebook?

The Post Office provides a vital service: routing messages from a sender to a receiver. To do this, they need highly constrained metadata—the destination address, the return address, and the level of service you paid for. But here is the absolute constraint: They never look inside the envelope. Their architecture, their governance, and their data models are built around the assumption that the payload is none of their business. If a Post Office employee opens the mail to parse your letters and sell you targeted advertisements, that isn't a clever monetization strategy. It's a crime.

Now, Facebook. Facebook is the exact opposite. Yes, just like the Post Office they mediate communication. They keep track of relevant meta data to operate the service. But the content of your messages is the primary fuel for their business model. They open every message and parse it. They track what the message receiver does. They compare recipients and senders and topics and everything. They may as well root through our sock drawer to monetize contents, brand, type, and wear. Because the Terms of Use say they can.

Any term of use can work. Some terms of use, like WhatsApp are designed for intense privacy. Some, grant access to everything. Remember this isn't privacy—even Facebook doesn't publicize your hopes, dream, and obsessions. But they use them. They use them because the product terms allow them to. When you break terms of use you have a massive architectural failure. You failed to govern the boundary.

Terms of Use are always set by the owner. Service owner, product owner, facility owner, business area owner. It doesn't matter. Pragmatically, we reach for the Product Owner. Not any lightweight rep on an agile team—the person accountable for the product offered to our customers. The person who can balance the terms of use acceptable to customers with the terms acceptable to the business. Remember, many transit customer want a full time driver. Someone patiently waiting to take them wherever they want to go. And that service exists, at a different price point.

Assembly as the Ultimate Enforcement

Terms of Use give you a governable boundary. Tension lives at every boundary. Architecture thrives in addressing boundary conditions.

Apple's Photo "Memories" feature drives the tension. Apple provides common storage and sharing across their platform, which looks a lot like Facebook's community mediation. However, Apple's core value proposition is privacy. They ferociously defend their terms of use. They will go so far as to withdraw services from markets when they cannot provide you assurance there is no way for anyone to look in your Apple sock drawer without your active involvement.

On an internal side they do not spend a dime processing customer data to serve a warrant. Because they cannot look. They assert in court there is no backdoor.

Then they offer a service that looks at, and curates, your photos for you—memories. Yet their terms of use assure absolute privacy.

They address these hard constraints—Apple cannot look and your photos are curated—with strong application architecture. In Navigate terms, it's just using the Assembly Model.

Assembling functionality is a central task for an application architect. Assembly drives integration boundaries, lifecycle, and dependency—it is the critical application architecture challenge. We know that functionality can be placed anywhere. Literally anywhere. You can embed it in an enterprise application, expose it in a micro-service, or even hard-wire it into an ASIC.

To meet the data Terms of Use, Apple deliberately chooses to deploy AI Worker functionality directly onto the edge device—your iPhone. By pushing the compute and the data together, Apple physically separates themselves from the data. They knowingly abandon the upside of monetizing the customer.

Ignore what you’ve declared and the downside swoops in like vultures. Liability forces after‑the‑fact protection, breeding complexity, piling on technical debt and cost—plus a box of liability tucked in a dark corner.

When you have terms of use on your digital product, follow Apple. Create the application architecture, technology architecture, and security architecture that deliver on requirements.

Conclusion: Cut the Knot

If you do not start with product data and know your terms of service—Facebook who peeks for a living, Post Office who peeks when directed to, or Apple who cannot peek— your architecture inevitably drifts to liability.

Your hardest challenges are where your business operations are improved by using product data. The easy example is using the identities maintained by your customer inside your SaaS product to support access control, or support authorization.

You'll never untangle the knot by tweaking your "Sales", "Support", or "IT Operations" subjects. That is like pulling harder on the rope. It only tightens the knot. It is no different than having one more meeting about who owns customer.

My challenge this week is look at your Digital Products. Do you clearly and cleanly separate out Digital Products in your application architecture? How about your Data Architecture? Or do you blur everything into a tangle with the data to operate your business and the application support your business? Start pulling out your digital products as subjects. Start explicitly stating the Terms of Use. Start governing your architecture by following the directions you have been given.

Next week, I will show you exactly how we cut the knot. We will look at how to architect the boundary, establish clear constraints. We simply start by extending the out-of-the-box DAMA enterprise data model and treat every digital product as a DAMA Subject.

As always, I welcome your thoughts and feedback.

Have a great day!

Regards,

Dave Dave Hornford Conexiam

P.S. If untangling your data architecture is on your critical path, look into our Data Architecture Foundation Workshop. We’ll help you map your Subjects, define your Data Contracts, and ensure your Terms of Use are driving your architecture, not breaking it.