As we first introduced within the first part of the Data Vault Use Cases article series, the Enterprise Data Warehouse (EDW) can do more than just simple reporting and dashboarding.
We previously explored how the EDW can help to improve data quality by implementing data cleansing rules.
This can be applied by write-back operations that affect the source systems directly. Though this was only one example of how to add more value to the EDW.
The scalability and flexibility of Data Vault 2.0 offers a whole variety of use cases that can be realized, e.g. to optimize and automate operational processes, predict the future, push data back to operational systems as a new input or trigger events outside the data warehouse, to name a few.
AN EXTERNAL INTERFACE FOR BUSINESS PROCESS AUTOMATION
The next use case
to be introduced in the series is an overall concept of business process
automation.
The EDW can be used as the central storage not only for data cleansing rules
but also for a business process automation framework.
Typically, when a
business is running, content in operational systems will be created, deleted or
updated.
As soon as these operations arrive in the EDW, an automated process can act
upon it. This can either happen by business process automation frameworks, an
Enterprise Service Bus in a Service-Oriented Architecture, or an ordinary shell
script, to name just a few.
To filter for specific events, business rules need to be defined and
implemented as Business Vault entities.
To initialize the business process application, it needs information in a
specific structure, namely those contain the trigger criteria.
For this, the information marts can be used as interfaces, drawing upon their
first appearance as we already have called them interface marts in part 1 of our series.
Using virtualized Tables (Views) is a good practice in this case as one does
not need to move data again and changes can be applied very quickly.
One example is to use new entries in a view as a trigger event, followed by an
action in operational systems, the EDW itself or other third party systems.
Here is an example of how we can use such a process to feed our knowledge management system (KMS) with combined information from different sources:
Our operational systems act as short-term memory of the organization with the latest data available while the EDW acts as the long-term memory, storing all cleansed and history data.
When the integration into the EDW is done, virtualized tables in the Business Vault apply business rules to cleanse and enrich KPIs to the data. The interface mart, also virtualized, selects data from the Business Vault by applying a filter criteria.
The final result is what is the desired set to be forwarded to the KMS automatically. The following image provides an overview regarding the architecture:

The Knowledge
Management System (KMS) is used to store thousands of pages with business
processes, development documentation, project experience reports, training
materials, Data Vault knowledge, and quite a bit more.
To create and maintain this knowledge, a significant amount of manual work is
required.
This is the reasoning behind automating the process as much as possible.
Therefore, we apply the business process automation to documentation work:
As soon as specific objects enter a predefined status in one of our source
systems, it is caught by the Interface Mart where the business automation
framework is waiting for new records.
It then acts on newly created record events and creates a new page with a
pattern based SQL-Statement which is used by a database plug-in in the KMS.
For security reasons we created a special user account, which has only access
to the KMS interface mart and does not have access to other areas in the data
warehouse.
In use cases as such, the EDW provides great additional value by adding documentation pages which are automatically maintained, which in turn saves a significant amount of working hours.