We have seen the complexity of existing IT infrastructures and the difficulties
for the use in the organization because people have to access a lot
of different systems. Now let's look into an environment of manufacturing
industries, into design and engineering. it can be a car. It can be a tool development.
We have engineers. We have designers. We have managers, different roles.
And we have systems, design systems, CID. We have PD and product data
management systems. We have specific tools for the spare parts,
definitions, certificates for approvals that these products can be sold and
a lot of other tools which we need to develop a product.
Within this data in these tools, there is a lot of IPR,
a lot of knowledge of these companies. There is a secret data because, for example,
in the car industry, this data of a car, these designs are being done four years
before these cars are being produced.
This is highly competitive information
and therefore, whatever has to be done, it's very important to protect this data.
At the same time, in this market there is an issue. You want
to collaborate with partners, but if you want to collaborate with partners
for, let's say, for sizing of a specific know-how, you can't give every partner
access to all your secret data. You have to protect this, and you have
to make sure that the partner is only getting this information
which he needs to perform his work.
And here, data-centric architecture brings relevant value. Let's start
with the people who are using these different tools. And let's start
with the core components of what is being needed to develop
this data-centric architecture.
The first thing that we need is the possibility to exchange this data.
It's a streaming technology, and it could be Kafka or HPE Data Fabric.
Moreover, we need metadata management for all the data being exchanged
because classification, knowledge about secure data, relevance of this data
in a specific lifecycle, all this is important to be managed, and finally,
it's the access control. So who has a right to access depending on this metadata,
specific information on a specific project, or on a specific part?
This is the fundament of the data-centric architecture in an engineering organization.
The next step now is to give this information and make it visible
to these engineers and designers and the manager.
And therefore, we need a layer of microservices to subscribe to this data
and to visualize it on user and role-centric applications.
We receive the data in a user-centric app.
The engineer can access the relevant data for his specific tool or a specific part
that he wants to access, a specific revision he wants to see,
or search for a part number to get the relevant information
and the relevant documents.
He can access a 2D document, a 3D document, all with the scope
to what he is doing and where we get based on metadata with the access to write
that he can access this data so he don't care about how many tools are in use.
Think about, not only these different tools are being used in one engineering
group, but you have different brands, you have different sites,
you have different departments with specific different topics. They would need
to access dozens of tools to get all this data together. With the central view
he easily can access and dive into the relevant systems,
managed via this data-centric architecture.
Now, let's look at the next step into what's in for the management.
What is in for the management? The manager wants to have an overview.
He wants to understand
Where are my data? What are the data related to this specific project?
In which systems are this information and it's there a potential to optimize
my landscape to reduce the number of tools to facilitate the exchange of data?
He wants to understand about the relevance of data as the security and
the protection of this data.
This can be enabled with data-centric architecture by enhancing the data app
with some data store, a data lake and some analytics capability.
What management can get out of the data is now being accessed via an analytics
capability effectively, you can see the interdependencies,
you can see relations between these documents. You can follow this interdependency during
the life cycle. You can see redundancy in the infrastructure, which you might
want to reduce because you want to save the cost, because you want to improve
your process and you can see the improvement of the overall design.
You get your dashboard seeing the development and you have KPIs being monitored
and the easy access to the relevant information that you need.
So with data-centric architecture, we have enhanced the functionalities
and engineering, in collaboration with the engineering department,
in collaboration between different brands, use synergies,
minimize the overlaps of IT functions and improve the insights
in how is engineering being done in the organization. And we have given more
easy access to data without specific adaptations in each and every
of the core components IT products.
Now let's look into the situation. What is in for collaborating with a partner
working in an ecosystem. Working in an ecosystem, working with partners,
it's now important to look into the specific case you want to exchange data because,
for example, your partner is taking care of a production of a specific tool.
So you want to see the designs or you want to exchange designs
with the partner so that he can collaborate in this engineering.
And the first precondition is you need something like a data monetization,
data exchange control system.
This is where you control which data can be exchanged based on the metadata,
and also on legal, additional legal restrictions, just to make sure
that you protect your IPRs. You protect the rights also of your suppliers,
onto the designs, what you are exchanging and that also the collaboration
between partners, if this might be competitors, is legally done in the correct way.
What can you do? You can exchange now based on this digital information,
and with this module, you have a clear exchange of documents which you want
to transfer to the partner.
That is, you have classified the documents you are exchanging
or receiving and you can send them, they are tracked and they are sent directly
out of your digital "twin" of your data set instead of connecting hundreds
of applications to your partner ecosystem. And this is bidirectional.
It's possible the same way around that the partner can send you back the feedback,
his information, his documents on the same way.
And even more, you can enhance this collaboration with the same views
the managers have
in exchanging and enhancing the dashboards, as well as enhancing the information
on the interdependencies of these documents, which documents and which systems,
also on the partner side, are connected together to a specific vehicle,
to a specific tool, and you can see the history and the life cycle
of this engineering campaign.
We have the information in the organization on all the data and
documents being generated over the life cycle. We enhance this for the given
project onto the partner documents during the life cycle. And on top,
we get a report, a single report, a clear single view on every document being exchanged.
What is the maturity of these documents? What is the stage of my design?
All this information is being managed and exchanged by a data-centric
architecture with support of not only metadata management,
access management, but monetization and access control functionalities.
So value generation with data-centric architecture.
First of all, we facilitate the operations within the organization.
Second, we get better insights and recognize redundancy, we can improve
our processes. And third, there is the option for partnering far more easily
because it's a single view and single transfer of data without accessing
hundreds of tools and getting insights into data which are in this shared
and collaborating environment.