From disconnected data silos to a unified, knowledge-centric organization—discover how two multinational organizations reshaped their data culture with a semantic model-driven Enterprise Information Architecture.
Enterprise Information Architecture success stories
If you read our previous article about Enterprise Information Architecture (EIA), you’ll know that an EIA can enhance efficiency and collaboration within your organization, foster innovation, and enable better-informed decision-making based on meaningful, contextualized insights. And the next step is bringing this vision to your organization!
In this article, we’ll explore how two of our customers accomplished this feat and the steps they took to make it happen. We’ll also share key lessons learned that can help you successfully build your own EIA and ensure a smooth and sustainable transition.
Table of contents
-
Enterprise Information Architecture use cases in the real world
-
The solution for both use cases: A single point of truth for Business Objects
What is Enterprise Information Architecture?
Before we dive into the how of things, let us first quickly recap our definition of Enterprise Information Architecture. We define an EIA as:
“An Enterprise Information Architecture includes a digital asset at its core called the semantic layer (or model), which holds all required metadata from all involved enterprise systems and stakeholders to facilitate communication, planning and coordination. It enables you to model, assess, structure, analyze, organize, manage and visualize an organization’s data and information assets across various systems, technologies, departments, processes and stakeholders – all in a human- and machine-interpretable format.”
Our definition includes a semantic knowledge model at the core of the EIA—we believe your EIA should be grounded and centered on a model that enables you to capture meaningful context about your enterprise systems, processes and structure. Instead of merely documenting what systems exist, an EIA based on a semantic model captures what they are about, how they connect to the enterprise and its other systems, why they are used and who is responsible for them, which can help you glean more valuable insights from your enterprise IT landscape.
For an in-depth explainer and to learn how our definition differs from terms like ‘enterprise architecture’ or ‘information architecture’, or even other existing definitions of EIA, you can read our EIA introduction article for a thorough breakdown.
Enterprise Information Architecture use cases in the real world
Anytime you introduce a new technology or way of doing things, especially in a global and well-established organization, it always involves several phases and requires alignment with multiple stakeholders. These organizations likely operate with a variety of existing systems and numerous procedures, adding a layer of complexity to implementing any form of enterprise-wide change. And while it may seem intimidating at first, a data culture transformation is entirely achievable and completely worthwhile. Take a look at two of our customers who are currently in the process of transforming their organizations’ data culture with the support of metaphactory.
How a leading German automotive giant shifted to knowledge-centricity with an Enterprise Information Architecture
One of the customers we’ll explore in this article is a large German multinational manufacturer of premium vehicles and motorcycles. They partnered with us to advance their journey to becoming a data-driven and knowledge-centric company, which included objectives such as:
-
increasing the transparency of their information landscape, information architecture and data journeys,
-
simplifying data discovery and query design, and
-
harmonizing and standardizing their information landscape.
This customer is a typical example of a long-standing organization with extensive existing systems. We determined that they wanted to achieve a joint understanding and transparent connected metadata basis with relations, meaning and context information as a single point and source of truth—where all relevant stakeholders not only would have easy access to this information but could quickly and easily understand it, search it and extract insights from it. Following our discussions with the customer, we established that they wanted to be able to answer questions such as: How is the vehicle information connected with the customer information? Or in which IT systems can I find all information about product master data?
Answers to these questions would be accessible in a centralized portal, and also be enriched with meaningful context, e.g., linking it with various business glossaries to bridge the terminology used across different areas of the business, connecting it with data catalogs to capture metadata and core data product and data source information about individual systems, or linking it to GRC systems (governance, risk and compliance) to capture governance guidelines and responsibilities–ultimately ensuring that it can be understood clearly and in its entirety. All of this enables end users to quickly answer complex questions about the organization’s information landscape, understand how this affects business processes, and make informed business decisions based on the comprehensive information they would then have at hand.
The main enterprise data challenges
We determined that one of the key motivations for implementing an EIA EIA was to harmonize existing silo solutions into an overarching solution. They had multiple solutions, consisting of various systems and applications – like business glossaries, data catalogs or GRC systems, that were disconnected and isolated, each with varying permissions and ownerships. They weren’t seeking a replacement of these systems, but a way to connect the information held in these disparate systems.
For example, it could link metadata across three systems: one that manages the ownership and governance of data within a data source, another that provides information about the data content available in the source, and a third that tracks the business processes using data from that source. Connecting these systems in a metamodel that describes how they relate to each other and the business, would offer a single entry point to the data, allow for regular validation of data accuracy and make clear who is responsible for those updates.
Another key challenge we identified was the semantic gap existing within the organization—each department and team had its own set of terminology to describe a particular object, function or process, leading to miscommunication and inconsistencies when using various applications. For example, when referring to “product”, the manufacturing department might define it as the output of their manufacturing process—like a crankcase or a piston, which would then later get assembled into the final sold product, a vehicle. Meanwhile, the sales department might refer to it as the final shipped product that a customer would buy—like a specific model of a vehicle.
We needed to help the customer create a consistent, shared understanding of the meaning of their data by getting alignment on Business Objects (BO) across all departments. These BOs represent a wide variety of real and virtual objects in the business world, as well as the input and output result of business processes, and serve as the foundational building blocks of these organizations’ EIA. For example, Business Objects can represent entities or ‘things’ used within the organization, departments, roles, products, results, processes, tools, etc., central to the Enterprise Information Architecture.
In our example, with an EIA based on a semantic knowledge model, modelers and stakeholders would align on what is considered a ‘product’ – let’s say the agreement is that “product” refers to the final shipped item – and capture that definition in the unique BO “Product” – together with other relevant metadata like synonyms (e.g., “Final Goods”), ownership and relations to other business objects. Separate BOs would be created to describe the other entities some departments referred to when using the term “product”. In our example, they might define a BO “Part” to describe what the manufacturing department referred to, namely the entity that results from a manufacturing process – and capture its definition together with relevant metadata and relations, for example, that a “Product” might be assembled from several “Parts”. This approach eliminates ambiguity, making it easy for everyone to understand and use the correct terminology.
In the EIA interface, the end user would be able to see the combined metadata from all synonyms for ‘Product’, information from the systems that hold information about ‘Products’, as well as the separate BOs that are related to ‘Product’ (such as “Part”). With this information, you would be able to search for ‘product’-related information using defined terms and synonyms, for example—again resulting in more transparency and clarity for all.
How an American multinational food corporation leveraged an EIA to save time and cost when managing their complex IT landscape
Another customer of ours, an American multinational food corporation, had very similar goals to the German automotive customer described above. Their primary goal, however, was to reduce the time (and money) spent on analyzing their complex IT landscape of ERP systems when preparing for system migrations, upgrades, integration or consolidation. Many of these systems had been inherited through mergers and acquisitions with no up-to-date documentation of the overall landscape. It was impossible to keep documentation current in a constantly changing environment where new systems—and the APIs that enabled new applications—were continuously added. Every time a new system needed to be integrated or changes or updates had to be made to the IT landscape, several experts were required to review all systems and draw a new map of how these systems connected, the different business processes they powered, the APIs connected to them to support applications, etc. – before being able to modify anything. Such projects would easily take weeks or even months, and if supported by external consultants, would cost several hundred thousand dollars.
Overall, this customer aimed to reduce cost and accelerate change and innovation, while also maintaining security and stability. The multinational food corporation set out to build a “documentation culture” that empowers and encourages employees to document necessary systems and processes, by making it easy to do so. The result of our project together was an Enterprise Information Architecture based on a semantic layer, which then also unlocked other benefits, similar to those experienced by the previous customer.
The solution for both use cases: A single point of truth for Business Objects
The solution for both of these large enterprises was to integrate metadata about business objects, business processes and IT systems and applications into a single, coherent business object framework—aka the semantic model. By creating and implementing a semantic model with metaphactory, metadata from disparate systems can be consolidated into one place, providing a central entry point to the data, as well as creating a consistent and unified understanding of the BOs.
Rather than having to chase colleagues or face roadblocks due to access restrictions to various systems, the semantic model can capture and connect all of these existing systems and processes in a digital manner that is then made readily available and accessible to relevant stakeholders. While the systems that hold this data are not replaced, they are seamlessly connected to ensure that end users have a single entry point to the information in these systems, they’ll also be able to know which systems they will need to access to answer specific questions, how to access them or whom to contact for more information.
With a semantic model, these customers can create user-friendly interfaces that utilize semantic search and provide immediate answers to complex questions by integrating all relevant metadata about systems, processes and people into a comprehensive knowledge graph—all of which is done with metaphactory. The German automotive corporation has fully implemented the solution and are now expanding its use, but the end goal is to empower knowledge modelers and data stewards to design and connect business objects effectively. This process will ultimately break down silos and political boundaries, enabling quick and accurate answers to sophisticated questions, such as:
-
Which IT systems contain information related to a specific business object?
-
Which team members are involved in executing a specific business process?
-
Which processes are responsible for updating business objects?
-
In which systems is input data for a specific business process stored?
-
Which business processes are affected by a system shutdown?
-
Which business processes are most impacted by supply chain disruptions?
-
What are the potential reasons for a business process running unexpectedly slow?
-
What critical business risks arise from reliance on third-party data sources?
-
Which IT systems would be impacted by a new data protection law?
Lessons learned
We’re thrilled with the ongoing success of both customers implementing an Enterprise Information Architecture with metaphactory. Along the way, we also discovered additional learnings that are beneficial for customers wanting to accomplish the same thing:
#1: Governance is critical
One of our key takeaways from the project is that having proper governance for processes such as getting approvals on Business Objects is absolutely critical for success. Careful planning and involvement of all relevant stakeholders in a clear, organized manner ensures that any complexities that arise can be managed without disrupting the flow of getting necessary input throughout the process.
Governance is not only essential for laying the framework of EIA implementation but also supports smooth adoption and maintenance as it is often an ongoing process. It should not only detail information ownership (e.g., BO descriptions, who owns the business object name, or mapping to other Business Objects) but also existing roles, responsibilities and how these roles would collaborate. For example, with the multinational automotive company, the roles were clearly defined from the outset (e.g., Data Owner, Data Stewards, Information Architect), as well as how each role would interact with each other. In this case, Data Owners were responsible for scoping the BOs and their governed metadata, and they would nominate Data Stewards to be responsible for BOs in their area of responsibility.
#2: Legacy data as the single source of truth for modeling
Another lesson we learned is that there are most likely various systems already in place in the organization that important information required for the modeling process. This information can include (but isn’t limited to) a directory of business terms (glossary), processes, users/persons and organizational units, as well as the roles of these persons and organizational units, data catalog information on the physical data sources, and many more. These existing systems are the single source of truth for such information and therefore a modeling solution should ideally improve virtual access (federation) of the data and be able to present it to the user during modeling so that this legacy information can be referenced in the modeling process.
#3: AI can guide and automate the modeling process
Business Object modeling can leverage AI to extract as much information as possible from existing sources in preparation for modeling. Since much of this information is hidden in unstructured data, manual modeling alone can be overwhelming and AI can reduce the amount of manual labor and accelerate the process. AI can provide valuable guidance and even potentially automate parts of the modeling process (while this approach is still being fully explored, we believe it is feasible and are actively investigating implementation with metaphactory to the fullest extent.)
#4: Build in training and onboarding
While all business users are capable of modeling Business Objects, they may not have had semantic modeling experience in the past and would have to learn how it is conducted and what to watch for to ensure that the semantic model properly captures all required information.
As well, training is needed to guarantee that the final model satisfies any quality and standards requirements. Building in “Modeling support sessions” as part of the implementation process can ensure a good model, and these sessions are hosted by a modeling expert who uses core competency questions (either provided or collected by the trainer) to guide the trainee through the modeling process. Training can also reduce the initial anxiety that surfaces when having to interact with a new system.
#5: UX must meet brand standards
It’s important that the system end users are interfacing with has a familiar look (i.e., follows corporate design standards), is accessible and is even responsive to some degree (due to differing devices, working environments and accessibility needs). We discovered that users will quickly turn away from software that is seemingly too complex or unfamiliar to them, therefore one that follows corporate design standards offers some familiarity and approachability to the new system.
Additionally, using a web-based solution will eliminate the need for any software installation or technical rollout and can make for more seamless implementation, improve collaboration, and foster an overall collaborative experience when building models with other teammates.
#6: Hidden benefits
While the solution’s benefits are clearly outlined above, we also uncovered that we could also resolve issues that weren’t initially on our radar. For example, in the case of the American multinational food corporation we mentioned earlier, creating APIs was a standard part of their IT process for delivering new services to users. We discovered that creating these APIs was a largely manual process, requiring significant time from IT experts. While this wasn’t an issue we initially sought out to address, we found that by implementing a semantic model in the EIA, we could automate the creation of APIs. This significantly reduced the need for manual intervention, allowing users to simply select the schema, relevant classes, relationships and attributes for the API.
These reflections not only enable us to better serve our customers in the future, but we hope that they also give you insight into what to expect and prepare for when embarking on your own journey to implement an Enterprise Information Architecture.
Try it for yourself
Now that you’ve read how an EIA helped these companies address their existing data challenges, you can accomplish the same by introducing EIA in your own organization.
Speak with one of our experts to discuss your organization and specific use case, and learn how metaphactory can support your EIA journey. Ask for a demo or free 4-week trial of metaphactory.
Contact us»
