Retail at Speed: Unified Commerce and the Olympian Perspective

Apr 08, 2020

Just as a building architect’s schematic shows a common picture of the basic elements of a large and complex edifice, a business architecture enables a business to picture itself to itself.  When everyone can agree on what the business is and does, the likelihood of getting people to understand their own role in a strategic initiative increases many-fold.

Empowering the Retailer through Business Architecture” — Thematix

[This is 3rd of 4 “Retail at Speed” installment on the subject of Unified Commerce.  The previous installment, An Expansive Model for Unified Commerce, highlighted the blueprints, designs, device interfaces, interface standards, data models, best practices, RFPs and other frameworks to which Thematix has access via the Object Model Group.]

In this article, we will apply the core concepts of business architecture – Value, Capability, Information and Organization – to the topic of Unified Commerce, and show how these tools allow us to understand Unified Commerce as a whole, rather than as a bunch of technological piece parts.

First, recall that Unified Commerce is really an extension of the concept of omnichannel, except that the orchestration and cooperation of discrete channels (web, mobile, social, store) is now extended ‘horizontally,’ end-to-end across many different value streams: i.e., those having to do with sourcing and supply chain, distribution, warehouse, stocking, point-of-sale, delivery, installation and so forth.  The power of networked computers now extends to things, and by extension to the very products that customers are being delivered.  In a sense, retail will soon be a presence in the customer’s household, long after the sale.

But how do we make sense of the blooming, buzzing confusion of available and anticipated technology?  How to understand the strategic significance of robots, sensors, camera, IoT devices and drones alongside the already complex and crowded array of gizmos that have become part of everydayness (such as the mobile phone)?   What is the framework in which we can understand the significance of the tools of Unified Commerce for both business vision and bottom line?

Business Architecture is this framework.  It provides an “Olympian View” of the business; it is a vantage point from which a comprehensive understanding of the business can be focused on the opportunities provided by Unified Commerce.  It is means of tying business strategy to even fined grained technological choices.

Any business exists to provide value to its stakeholders – primarily, but not exclusively, the customer.  For this reason, the starting place for a business architectural analysis is the Value Stream.  A Value Stream is “a visual depiction of how an organization achieves value for a given stakeholder or stakeholders within the context of a given set of business activities.”[1]

A business might support many Value Streams for many different stakeholders.  In retail, these Value Streams include (but are not limited to) the following:

Hypothetical Retail Value Streams

In Unified Commerce, the effort is to connect many Value Streams in as seamless a way as possible.  Thus, a Unified Commerce initiative involving robotics might seek to integrate and improve the Stock Items, Locate Items, Inventory Management and Direct Store Delivery value streams.  Whereas each of these Value Streams might have been ‘disconnected’ from one another in the past, the advent of robotics and accompanying automation means that the flow of tasks among value streams can be united and continuous.  For example, the very same robotic system for stocking items for sale can be used to locate the items, count the items in inventory and even deliver the items to the point of sale.  Using such a value-oriented analysis, we can for the first time get a glimpse of the business benefit of adopting robotic technology across Value Streams.

But the analysis does not end there.  We have yet to fully understand what the relationship is between robotic technology and the operation of any given Value Stream.  To get out this, we have to understand what the business does in order to deliver value in a Value Stream.  Business architecture uses the concept of a Capability to describe the kinds of things the business must be able to do to deliver value. Capabilities are fundamental abilities, powers and potencies that the business possesses or uses, which enable it to produce value for customers and other Stakeholders.  Many different Capabilities will come into play over the lifetime of a Value Stream.  For example, the “Stock Items” Value Stream might rely on the retail-oriented  Capabilities depicted in Figure 2 in order to deliver value to a retail warehouse manager (the stakeholder for whom the Stock Items Value Stream exists)

Capabilities Underlying “Stock Items” Value Stream

The Stock Items Value Stream weaves these Capabilities into a harmonious whole.  Robotics may play a role in reducing the cost of providing these Capabilities, reducing the error rate in a given Capability or enhancing the speed and volume that a given Capability might be capable of handling.  It is when robotics is understood in terms of the Capabilities that a retailer already employs that we can see the business rationale for using robotics.  When we assess how robotics might enhance existing Capabilities (and the Value Streams that depend on them), we can begin to understand the business criteria for technological innovation: i.e., concepts like return on investment, cost of inventory, throughput of inventory, just-in-time inventory and the like.

A third business architecture concept – Information – now comes into play in understanding the essential business concepts that the business uses in communicating about its value streams and that Capabilities use in creating, modifying or otherwise using data about inventory.  An analysis of Information in the context of Value Streams and Capabilities gives us a picture of what Information might be deficient or lacking when discussing the functioning of Capabilities.  For example, we may find upon inspection that the Stock Items Value Stream that the number of items in the warehouse at a given time is inaccurate because the Information model for the warehouse is wrong – it is perhaps counting individual components of an item when it should instead be counting the aggregation of those items that form a single sale-able product in inventory.

Finally, business architecture connects these abstractions of Value Stream, Capability and Information back to the concrete business by means of Organization mapping.  Organization is concerned with identifying those Business Units that are involved in the Value Stream by virtue of their ‘owning’ the Capabilities required in order to effectuate the Value Stream.  Therefore, to assess the impact of robotics on the Organization, we would identify which Business Units in the organization are responsible for delivering the Capabilities that the robotics initiative will affect.  Once this is understood, we can understand the organizational implications of robotics for the human beings that work for or with the business.

Theory is great but one has to implement solutions.  In Part 4 of this series, we will show a model called iVURM (interactive Virtual Unified Retail Model) that will help guide the implementation of the things discussed in this series of papers.   This will be followed up by a YouTube video showing how to use this for “Customer in a Unified Commerce World”.

If you want to dig deeper into how business architecture can help you realize a Unified Commerce strategy, please contact us at Thematix.  We offer architecture services as well as training in business architecture – virtually, for the time being. 

Connect at

–       Richard Halter

–       Rob Kost

–       Larry Smith

[1] A Guide to the Business Architecture Body of Knowledge (BIZBOK), Business Architecture Guild, Version 8.5, 2020, The Business Architecture Guild.  (Hereinafter: BIZBOK).

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *