Data-centric Architecture — A Different Way of Thinking

Data-centric architecture can have many benefits for industrial projects. Executing large capital projects is a difficult and challenging process and involves many parts that all need to come together to achieve a common goal.

Project teams need to balance:

  • different systems
  • complex and, sometimes, competing requirements
  • the participation of multiple disciplines and organizations

However, most large capital projects are fraught with issues that can result in a project being late, over budget, or both.

There is a Better Way

data-centric architecture - a different way of thinkingData-centric architecture (or model) is a solution that addresses the issues of conventional capital project methodology and delivers positive results. Data-centric execution architecture has been around for a few years and has been used in a limited way by some owners and operators in Alberta.

Adopting data-centric architecture does not change a capital project’s development phases—feasibility, concept and design basis, front-end engineering design, detailed engineering, construction, and start-up and commissioning—but radically changes how work is performed in these phases.

The most important aspect of data-centric architecture is data. Without accurate and timely data and the means to analyze it, there is no valid basis for making decisions. Click To Tweet

 

What does data-centric mean?

A data-centric outlook is a core concept in data-centric architecture, where data is viewed as a critical and perpetual asset used in support of applications to produce deliverables. Within data-centric architecture, the data model precedes the implementation of a given application and remains valid long after the application is gone.

In a data-centric approach, data must drive the development of projects, designs, business decisions, and culture. The emergence of cloud computing and storage enables organizations to remotely access and analyze large databases to make more objective, risk-mitigating, and profitable decisions.

 

Document-Driven Execution

The traditional project execution method relies on document-based deliverables produced at certain times throughout a project’s development.

Producing deliverables are important events, as they are used to measure project progress. More importantly, these documents are a physical embodiment of the project data and knowledge: they are the means by which data and knowledge transfer between project disciplines, project tasks, and between project phases.

Data-knowledge transfer can also occur between different engineering companies, as it is common practice for owner-operators to use different engineering companies for different phases of a project.

The document-driven model has several issues:

  • errors and misalignment of data
  • slow response to change
  • the data is static
  • information silos with multiple data instances

These issues lead companies to make decisions using poor-quality information.

Data Silos

All too often, for a variety of reasons, data contained on a deliverable does not align with data on other deliverables or across the various information systems.

Slowly and progressively, data discordance builds within the project. This situation results in a low level of confidence in project information and data, forcing users to verify the accuracy of the data before being confident enough to use it.

This verification activity is especially important when there is a changeover in engineering contractors between project phases.

Change is inevitable in projects and being able to manage change orders effectively is crucial. Nowhere is this more important than in the latter project phases, where change can have a significant effect on cost and schedule.

In practice, implementation of changes in the document-based method is slow, complicated, and open to error.

Documents are static things that present information at a particular point in time. This is not necessarily bad, it’s just not optimal, particularly in dynamic and complex systems, such as capital asset projects.

In the early project phases, a design can be quite fluid and undergo many iterations to find the best design option. Data changes trigger document updates, which will in turn trigger changes in the dependent documents.

It takes time for the information to work its way through the various project deliverables and systems, and some documents might not be updated, while others are incorrectly updated.

Project execution has evolved to use a plethora of information systems (e.g. applications such as CAD) to manage the many tasks involved in a project. While essential to the execution of complex capital projects, these systems can lead to information silos.

data silos
Traditional document-centric project execution often leads to inefficient data silos.

Each system has its source of data, which results in multiple instances of data occurring across the project. Managing data congruence across these silos is time-consuming and inefficient.

The article Top 10 Engineering Documents and Data Management Challenges explores the issues of the document-driven model further.

Data-Centric Architecture

Data-centric execution methodology is based on the premise that data is the primary and permanent asset of a project and everything else revolves around the data. The data-centric execution method has two key advantages over the conventional document-driven method:

  1. a single source of truth (SSOT)
  2. up-to-date data

The SSOT involves creating a single data model that is used by all project personnel and information systems. Using a single project-wide data source eliminates information silos created by information systems and their attendant data sources and structures, thus eliminating multiple instances of data. All systems and project participants use data that originates from the SSOT.

There is no data discordance in a data-centric environment, as there is only one instance of the data. As data is created or changed, it is made available to all connected information systems—there is no lag waiting for someone to take action and update a deliverable or system and the accuracy of the data is very high.

The value of the SSOT is significant, as it provides decision-makers with the most accurate and timely data on which to act.

A project data model must be created to establish the SSOT. The data model is a graphical representation of the attributes of things, the relationships between entities, and the flow of data.

The model comprises several layers of increasing detail and specificity. Each functional application, such as a CAD or procurement system, will read and write through the shared data model.

Data modelling for an engineering design project involves defining:

  • the types of assets (tags), such as mechanical and electrical equipment and instrumentation
  • the attributes that make up each asset type, such as pump attributes for each pump type (the number of attributes assigned to an item can be in the hundreds)
  • the entity relationships to ensure the flow of data between information systems (which entities need to interact with each other)
  • who (the commercial entity and specific person) is responsible for populating each attribute
  • who requires each attribute and when

The Data-Centric Project

A data-centric organization understands the importance of data as a project driver and collecting data is an important first step. The data-centric project must:

  • eliminate silos and analyze data simultaneously
  • centrally manage data
  • improve efficiencies based on new information learned

Although data is of primary importance to the project, data-centric execution architecture requires people and systems to create a holistic project execution model. Adopting digital execution architecture and data centricity will transform the nature of project execution for oil and gas capital assets.

Related Posts

See all posts →
Scroll to top