The Role of the "Logical Data Structure Layer" as collaboration layer between Domain Experts and IT Professionals
A Business do not only exist through Data and Applications
1) A Domain Expert specifies a Business Process
2) someone creates a solution for performing the Process
3) the Domain Expert approves the solution before starting to use it.
This process, with start and end at the Domain Expert, has always been- and will continue to be the same with- or without access to Data- and Software Development Teams for solution development and execution.
With Digitalization of the entire business and introduction of Data- and Software Development Teams taking ownership of much solution design, it is unfortunately getting increasingly difficult for the Domain Experts to take proper ownership of the initial task specification as well as the final solution approval. This is partly because the Business operations have a tendency of getting expressed through data under control of the Data- and Software Development Teams, to where Domain Experts may not have the same easy and immediate access. Furthermore, Data- and Software Development Teams only work with the processes and operations when physical data are available or can be created to represent the processes and operations. There are many Business Processes that lack data but are very real and important to the Business.
However, this challenge can be solved if Domain Experts are not limited to only describe and specify Business Processes when data is already available through Data- and Software development Teams. Data shall not be seen as the Business, but merely something that may support- and represent areas of the Business. By recognizing that Data- and what the Data represents are independent of each other, it becomes possible to separate Business Specifications of Processes done by Domain Experts from the IT managed Data and Applications. The Business Ecosystem specified by Domain Experts do not require data, as it rely on a mapping of actual processes and operations regardless of data available from the processes. How to perform this separation and the huge benefits achieved by doing so is explored further in this article.
Metadata as the binding tissue between user groups
The importance of Metadata as the driving force when developing Data Products and Applications in large and complex organizations is becoming widely accepted. However, much of the development within this area is driven by thought leaders and vendors developing optimal solutions for Data- and Software Development Teams. While proper tools for such Teams surely is needed, it is not all organizations that will benefit by a thigh coupling between Domain Expert input and the Data- and Software Development Teams. This situation e.g., holds true for Engineering Consultants where it is not possible to have a Data- and Software Development Team also knowing the Domain Experts insights for each specialist area. The working dynamics of the two groups are also very different which require them to work independently and integrate through a collaboration layer without limiting each other in working following their own best practices.
This article will demonstrate how Metadata also can be used to empower Domain Experts to freely specify Business Areas and Processes by introducing a metadata layer called the Logical Data Structure Layer (LDSL).
The Logical Data Structure Layer
The LDSL serves as the connecting tissue between the other main elements of the Business (Business Domain, Business Ecosystem, Subject Area, Business Application, Physical Data, IT Applications) described in this article.
Development of the LDSL is driven by the Business, as they formulate the original Business requests. IT shall consume the specification through the LDSL and develop accordingly. In case of uncertainty, IT shall respond with clarifying questions or requests for improved specifications. IT must never take ownership of the solution by interpreting a bad specification as the same specification is also used to QA the final deliverables from IT.
It is important to emphasize that the specification process is done by Domain Experts and not Data- and or Software Development Teams, meaning that the recognized Data Structures will represent the areas of focus to the Business.
The LDSL prevents a tight coupling between the Business Organization outline and the physical data and Applications maintained and developed by IT. The LDSL enable Domain Experts and IT professionals to meet, understand each other, discuss solutions, and reach final agreements through the new collaboration layer.
By having Domain Experts specify requirements through the LDSL, the Business specification becomes driven by Domain Experts without dependency on Data- and Software Development Teams. Through the LDSL, collaboration between Domain Experts and IT professionals becomes greatly improved to gain full benefit of the strengths from both groups.
Finally, physical data can be linked to the Logical Data Structures and thereby be coupled together with both Business Terms and Business Applications.
The following sections will elaborate on the main elements of the Business and how the LDSL facilitate connection in between them.
Recommended by LinkedIn
Business Domain
The highest conceptual level that an organization can be described with, is by subdividing it into Business Domains. A Business Domain is characterized by an area where value is created for the Business. For Engineering Consultants, it will often represent an area from where clients would purchase a service such as Groundwater, Utilities, Offshore Wind Energy. The Business Domain is specified by Domain Experts through a further specification of Subject Areas and Business Processes, both contained within the Business Domain.
Subject Area
Each Business Domain can be further subdivided into Subjects areas. Subject areas are similar to specialist areas, which to a large degree are business independent, but together support delivering a service within a Domain. This also means that Subjects Areas may be duplicated if they are used within different Business Domains because their usage focus will differ. Examples of Subjects areas for the Groundwater Business Domain could be: Hydrogeology, Geology, Geochemistry.
Each Subject Area can be described in further detail by breaking it down into individual Business Terms. When this is done, the Subject Area becomes a Subject Model of Business Terms. Core components of a Business Term can be; the Term itself, a Description, default Unit. Examples of Business Terms for the Geology Subject Model could be: “Borehole Type”, “Borehole Depth”, “Geological Unit”, “Geological Layer”. Metadata for the Business Terms can be further extended with e.g., confidentiality, approved values, GDPR identification, etc.
By visualizing all Subject Models within the organization, a map of the Specialist areas of the organization is created across all Business Domains.
Business Processes
Domain Experts see Business Processes as representing their individual work areas and tasks. If stitched together, it becomes a Business Service.
All Business Processes can be represented by one or more Data Structures for information input as well as output. The Business Process is responsible for the transformation between the input- and output information, whether it is done by by a person or a machine.
When identifying the relevant Data Structures to represent the Business Process, it is up to the Domain Experts to define the level of detail for the Data Structures that is sufficient to represent them within the LDSL. A Data- or Software Development Team that would be given the task of developing the corresponding Application or Data Pipelines, may argue that the representation is not complete and should contain far more information. However, the Data Structures given by the Domain Experts will represent exactly the level required for the Domain Experts to take ownership of the usage of the IT Applications, which is one of the goals.
Business Processes are assigned to individual Domains as it very likely that they need to work slightly differently for different Domains. Once the Business Processes gets specified, a map of Business Organizational Business Activities will appear across all Business Domains.
IT managed Physical Data and Applications
The IT managed Data and Applications are managed by the “Traditional” Data- and Software Development Teams following their best practices. Their required input from Business goes through the LDSL from where the IT Teams get information about the logical Data Structure as required from the Business, Data Descriptions (from Subject Models) as well as other Application requirements. It is important to emphasize that there is not a one-to-one match between the Business Processes specified by the Domain Experts and the Applications developed and maintained by IT, simply because a lot of the complexity is hidden from the Business when it has no interest to them. When Data- and Software Development Teams are using the Business specifications as basis for development of Data deliverables or IT Applications, they are bound to follow what is specified in the LDSL but can work freely on the solution where nothing is specified. Domain Experts can take ownership of the parts of the solution specified in the LDSL whereas the IT Teams will need to take ownership of all parts not specified in the LDSL.
The strength of the LDSL is that it clearly states which parts of the Applications and Data deliverables that the Business wants to be in control over and take ownership of, as it will be covered in the LDSL.
Benefits
Through the Logical Data Structure Layer (LDSL), the below benefits are immediately achieved.