Core Concept Deep Dive: Business Entities Collaborate
This post is part 2 of our 4 part series of deep dives into each of the Data Cloud Architecture core concepts. To read our first part on Data Assets, click here.
When looking at the overall data landscape for a specific organization, there are always logical groupings of people who have specific needs and requirements for the data they are leveraging, from the infrastructure they require to run their business, and from the resources required to build around the data they’ve acquired. Every organization is different, and the needs of every organization are different. Yet ultimately, these logical groupings WILL appear, and as a data leader, you need to find the right way to provide the right capabilities and resources to each grouping. If you can’t provide them what they need, you run the risk of each group going off and finding their own solutions, creating unnecessary silos and shadow IT concerns. Far too often an organization who has become siloed inside of their on-premise deployments will undergo a dramatic cloud transformation with the intent of removing silos and driving a more connected data ecosystem, only to pick up and move those silos to cloud based resources, with no shift in how the business continues to operate. Technology vendors don’t make it any better, continually going after specific use cases in specific areas of the business, trying to peel them off from the previously agreed upon architecture decisions that have been made centrally.
On the flip side, there are plenty of organizations where these logical groupings are intentional, and each have their own IT and Engineering function that supports each group with their respective use cases. While this minimizes friction with the rest of the org, and allows each function to make the technology investments that they need to in order to be successful in their goals, it also further drives the siloed nature of the organization, and minimizes the impact that collaboration can have across the company. Even globally distributed companies, where each line of business might be treated like its own individual company, can benefit from the force-multiplier effect that comes with cross-domain collaboration. The expression “a rising tide raises all ships” comes to mind when discussing the impact that collaboration can have on an organization as they try to steer into a data-driven future. Whether or not your data estate is managed centrally or managed by each individual domain, the Data Cloud Architecture (DCA) can help drive that force multiplier effect both across your organization, and even to the rest of your data network, whether that’s 2nd or 3rd party data providers and partners, or even with your customers. So what considerations should an organization take into account when leveraging the DCA Framework to define their different Business Entities? Ultimately it boils down to how each asset is collaborated on, and what is required to collaborate across the organization’s Data Cloud. The DCA Framework recommends defining a Business Entity at a level in your organization where the Assets being developed have value to other Entities in the organization. So really, it boils down to which Business Entity has true ownership over the asset, and how should the collaborating Business Entity interact with the assets being shared. Let’s take a deeper look at each scenario.
Owning Business Entity
In the previous deep dive post around Data Assets within the DCA Framework, I talked about how each asset being developed should have a measurable ROI that validates the asset even being developed in the first place. But when it comes to thinking about assets in terms of the Business Entities who find value in the asset, it is important to make sure that each asset only has a single Owning Business Entity. Many times, different entities may have different definitions of a particular KPI, or have a particular spin that they put on a physical asset they both need. For example, a large retailer may have multiple Business Entities that engage with their own subset of customers. There may be some overlap in the customers they have, but each Business Entity looks at a different set of KPIs associated with their customers. Therefore, they have each built their own Customer Master physical asset for their Business Entity, which while it has measurable value to themselves, it has minimal measurable value to others in the organization, and is difficult to collaborate on. So, for companies who are adopting the DCA Framework, we would expect that each asset being built has a single Owning Business Entity who is responsible for the development, deployment, and maintenance of that asset, in this case a true Customer Master for the entire organization. The owning Business Entity can leverage whatever tools, technologies, and data architectural approaches required to build the asset, as long as they make the asset available for collaboration to the rest of their organization in a way that is agnostic and interoperable.
By making sure that each asset has a single Owning Business Entity identified and aligned on, that Business Entity can make the relevant tooling and technology decisions it needs to in order to derive the maximum ROI from the asset, and then each of the Consuming Business Entities can build what they need to on top of that asset. So rather than having 5 different customer masters across the organization, the Owning Business Entity can take responsibility for building the single customer master, while other Business Entities can take ownership of other assets, driving better efficiencies across the enterprise. It also opens up many different options in terms of how the broader organization can be structured. For a more central IT driven organization, the central function can take control of the most critical assets for the organization and make them easily available to those other functions who need access to that data, while providing the infrastructure needed for those functions to build whatever assets they need on top of those core assets. For a more decentralized organization, this culture of collaboration should be fostered across the business, giving every function the opportunity to support one another as they collaborate on joint assets, and build their own individual assets as well. But for the owning Business Entity, how can they make sure that what they’re building supports each of the consuming Business Entities?
Consuming Business Entity
As a consuming Business Entity, your focus should be solely on having access to the infrastructure required to run the assets you are interested in consuming. Many times, a group will go off and create their own duplicate assets because they either cannot access the infrastructure required or refuse to accommodate the requirements of the owning business entity. For example, a central IT function may be building and deploying assets in an on-premise Hadoop cluster because they have the engineering talent to do it there and they have made an effort to centralize they’re data stack into a single data lake. However, multiple entities who need to leverage the assets being built on that Hadoop cluster don’t have the engineering talent on their team to access and develop their own assets in the cluster, so they either extract out of the Hadoop cluster, or rebuild the assets themselves in a SQL Server, Access DB, MySQL, etc because they have the skill set to develop there. And then they ask the Central IT function to support what they’ve built in a production setting.
By making sure the consuming Business Entity has the right resources, both from a talent as well as an infrastructure perspective, they can better collaborate with the rest of the organization. And by making flexible and agnostic infrastructure decisions, the consuming Business Entity should be able accommodate the owning Business Entities decisions in terms of how they produce and distribute assets to their constellation (as long as the owning Business Entities distributes their assets in a way that is also flexible and agnostic). The consuming Business Entity should also treat every asset as collaborative. If there is feedback on the asset, they should feel free to provide that feedback to the owning Business Entity. And if they have improvements that they can make themselves to the asset that has broader value for the rest of the constellation, then those should be funneled back to the owning Business Entity as well.
Conclusion
The ability for Business Entities to collaborate is critical for the broader success for an organization’s Data Cloud Architecture. In many other types of data and platform architectural paradigms, a central IT function is heavily dependent upon to build and deploy assets for the business. This has historically been how organizations, from small to large, have been structured, with little opportunity for collaboration with each other. While the Data Cloud Architectural Framework can still support a central IT driven delivery model, the ability to open up collaboration channels both between a Business Entity and Central IT, as well as between Business Entities, allows to better optimization of resources, more focus on what’s important from a development perspective, and ultimately a delivery model that can support both internal asset collaboration as well as external asset collaboration.
