Architecting Digital Products: The Yellow Line Collision

CDO Illusion

Boundaries have owners. Commercial digital products have fierce warriors defending their products. In house we have illusions. We imagine customers and owners. We believe the organization chart always tells us decision authority.

Fierce commercial product owners are great stakeholders. They have been given an area of responsibility—the product. They have very clear directions—expectation, constraint, risk appetite. They can assess the value of changes and often articulate very strong requirements. I worked with a digital product owner who needed a 95% transactional cost reduction in their platform. Not features, not just cost improvement. 95% cut in the platform cost to stay competitive.

With product owners like this architecture governance is a dream. You have a crisp authoritative stakeholder. One who understands the authority delegated to them; and the complete context of that authority.

Then we have our internal products. We start with a blurry line about the product and the data. We often have principles that suggest share the data. We imply that because data exists, the Enterprise owns it.

We look in the organization chart and find a Chief Data Officer, or a Data Governance Office. Mainstream thinking runs to the CDO to ask, and explain. They assume the CDO magically owns all the data. Most damaging is the assumption that any work to "monetize", democratize, and create "better decision making" is demonstrably worth doing.

Simultaneously, in development we often confuse slapping in an API, or running an extract, to dump data into the virtual data lake with change that improves our organization.

When we turn to the "Product Owner" we find a glorified business analyst trapped between the technologists and an annoyed user community. They call the user community customers—even though Marty tells us customer must pay, and can walk. These 'product owners' are busy shuffling Jira tickets. They have zero authority. Zero understanding of value. Imagine them knowing that viability was dependent on a 95% OpEX cut, and driving that cut through the digital program.

With product owners like this architecture governance is on life support. We have to use the full architecture governance toolkit to find out constraints surrounding the product, the objectives of the product, and what the organization expects from the consumer's business function.

We know that our organization is a complex web of interactions. In Navigate, to simplify the complexity we we lean on SABSA's risk model and the concept of superior architecture found in TOGAF.

All I'm looking for is the same knowledge and directions my fierce commercial product owners go to sleep fretting—market, positioning, price, competition.

All I'm looking for is someone who can test upside, downside, value, cost, and risk.

All I want are the basics of good governance—the objective, performance expectations, constraints and risk appetite.

And, I want that for every digital product.

The Yellow Line Collision

Once we establish the Digital Product's governance structure, the tension begins.

Most of the time we are working internally. You will be surrounded with ideas from the people who do not face market discipline. People claiming alignment to any strategy, initiative, or leadership statement. People using alignment to justify their preference or local improvement.

You know the deadly alignment argument. It is all about how they support something. Devoid of meaningful contribution. We know that value is made up of benefits worth the squeeze. Especially knowing the uncertainty associated with harvesting the benefit, and the uncertainty of the cost.

In-house you can expect a focus on the tech. Focus on issues like the mechanics of scraping an operational database. Cost is assessed as cheaply as a rushed integration ticket.

The basics of data quality and flow vanish into a rush to do something.

Your organization is using the language of product to drive dangerously.

Let's look at two critical data product risks.

You Cannot Sell What You Stole

Everyone who sells data products sells methodology and provenance.

Everyone.

When you do not have clean terms of use allowing you to re-use data, it is stolen.

Stolen data never has strong provenance and methodology—in data architecture terms: data source and data flow.

Stolen data is not 'monetized' it is fenced. Fences offer massive discounts because no-one can use stolen goods in the mainstream.

In house, stolen data contaminates even a virtual data lake. On the surface, low-quality data lacking methodology looks identical to high-quality data. But it constantly demands more refinement and post-processing just to make it useful.

Eventually, the stolen data creates a compliance issue. Usually coming from PII, customer secrets, or jurisdiction. Then you have to spend more to clean-up what was simply a value-free expensive data puddle.

If you want to have some fun, look hard at the return on your data compost bins. Like most residential compost, I'll bet you see people dutifully dumping peelings in the bin and going to the garden store for fertilizer and soil.

The Custodial Constraint

We fix these issues by good architecture.

We're starting to build subjects around product data. Especially data where our digital product captures customer information. In Navigate we use a model property to distinguish Custodial Data—data that belongs to another organization and may only be used in strict accordance with the contract.

This property is your first post in your fence. These boundaries severely limit integration and require security steps.

Last week, I briefly mentioned ServiceNow. CI's are obviously custodial, they are used by the application but the application provider never has a reason to look. How about user names?

Yes, user names. In a SaaS IT operations management system the customer will set them up to put people in process flows, enable approvals, even send alerts by calling the user's personal phone. Can ServiceNow use them?

It is obviously convenient to use them for access and license. But if the rights are restricted you immediately return to Apple's problem and you might need to find a way to never let the data leak outside the customer's environment. We saw Apple used good application and infrastructure architecture focusing on the assembly boundaries. They guarantee privacy of memories by processing the memories on your device. Remember, they promise no peeking, even if you will be happy this one time.

Take the same thoughts in-house. What data belongs to the digital product? What assembly is required to ensure that you process it inside the product, or for the product, or by the product?

Then what data is available? Then what data is needed by the business?

One of our digital product customers runs a very slim corporate finance. Every product family is accountable for their own cost accounting and cost management. The financial data that pours into the corporate bucket is very restricted.

This seemingly inefficient design lets the different products optimize their business and tax operations. The CEO gets to wander down the hall and ask very pointed questions. P&L owners are expected to know and optimize. There is no room for excuses. We need to bring this same discipline to all our digital products.

Architecture Defence: Non-Compliance Recommendation

Through this conversation I've been highlighting how you chase the boundary. I've been highlighting that digital products are just a specialized governance problem.

Treat them as a subject, a business area. At the same time treat them as a risk or governance domain. I trust that you see every data subject is also a governance domain. A place where there are unique objectives, performance expectations, constraints, and risk appetite. A place where there is a solid key stakeholder.

I didn't say a single decision maker, I said a solid key stakeholder. Stakeholders always live in packs. There are always competing interests and overlapping authority, and conflicting directions. If it were straightforward, we wouldn't need enterprise architecture.

My examples have all been cases where we needed to protect the digital product. Cases where we use assembly to process inside the product, or by the product. That is one case and you need to know when it is true.

The other case is equally true where the product owner—the key stakeholder, governance domain owner, and subject owner—has been told to fit into a greater whole. They are told to use the shared service financial system.

Either model is true. Either model can be your digital product architecture.

When people stop following your architecture optimized for your business and its unique go-to-market they are crossing the Yellow Line. Sooner or later there will be oncoming traffic.

To avoid the Yellow Line Collision we, the enterprise architects step into the firing line.

In method terms we perform implementation governance and create a Non-Compliance Recommendation. Finding the problem is easy, and not very useful. A recommendation tells the stakeholders what they need to do to salvage the value the target was providing. They already know what the non-compliance is providing.

Every non-compliance comes down to:

1. Enforce the Target: Change to deliver the expected target architecture value.
2. Grant Temporary Relief: Defer fixing the problem.
3. Change the Architecture: Accept the loss of original value, and create a new value expectation with a new target.

We frame the choices so the appropriate leaders—stakeholders—make an informed choice. Snip-snap-snoop, you have the best possible organization and the best possible change. It is a very sweet place.

Concluding The Yellow Line Collision

We often assume there is virtue in courageous stakeholders holding the line and enforcing the target. Often there is. Often the non-compliance is a local optimization. Or a project team cutting a corner to hit go-live-day. Or a agile team claiming victory. In all these cases they are destroying the value the target delivers.

I don't have the hubris that I am omniscient. I know that the world moves and changes. New approaches, new tools appear. The sum-total of creative power dwarfs my otherwise awesome consulting team. Most importantly, every morning our enterprise is a new company in a new position.

I create dynamic roadmaps to give my stakeholder the controls to drive. I use every non-compliance as another dynamic opportunity. When we see a better path to a better target we embrace it. Immediately. Then we celebrate! We harnessed all available creativity and brilliance. My architecture is green and growing. Woo!

So here is my challenge this week. Who can authoritatively answer for your digital products? Who carries upside and downside of every choice? What is the market position (enterprise context) and measures of success (directions) for each product? What superior architecture constraints these products?

Use this to know where the yellow line is. And to extend the metaphor what kind of line—those mountain highway double yellow lines with slower speed signs are a clue. Find the constraints that really matter.

Next week, in the final part of this on data and digital products, we'll look at technique. The architect's tools of the trade. Specifically, we'll explore two things. First, the Logical Document model constructs to cross the boundary between the enterprise and a digital product. Second, architecture specifications to translate the data terms of use and assembly into hard guidance.

As always, I welcome your thoughts and feedback.

Have a great day!

Regards,

Dave

Dave Hornford
Conexiam