Composable Digital Operations
Automated Ontology Based Digital Operations Maturity Analysis
Abstract — In this era of increasingly blurred line between physical and virtual environments, the concept of the “Digital Operations” is the most critical piece which ties everything together. The digital enterprise is here, and its prime characteristic is that is essentially assembles all the business components into virtual counterparts thus converging the Operational Technology (OT) and Information Technology (IT) to enable mass simulations and AI technologies to prescribe the best course of action in even the most turbulent of times.
The digital operations approach requires a reconsideration of traditional models of the entire IT organization data assets. These organization and their processes need to be broken up into components that follow certain key design principles such as The Minimal Functions with least Dependencies, Shared Knowledge, Predictable Contracts, Unambiguous context and Real time data.
The concept of better integration between Information Technology and Operations Technology is a valuable objective. The goal is to foster measurable incremental cultural and technological change to derive most overall value out of the union of people, process and technology. But the cultural issues, reward models, and risk allocation create obvious barriers in attaining those goals. The common industry belief is to use the digital operations framework to build a platform using the right tools and you will have attained IT/OT nirvana. Here we propose a composable Digital Operations solutions that are build across a platform linking customer Digital Ops Maturity to their journey… where am I vs. Where do I want to be.
I. Introduction
Disruptive market forces such as Globalization, Technology and AI, Digital Transformation, Workforce challenges and Supply chain disruption are driving seismic shift. This is the harbinger of connecting all sorts of data, analytics and users experiences to create a single view of what is important for the organization to optimize the decision making. This in essence creates the connecting Digital Thread. Digital Ops Delivery method defines the pathways to the creation of your Digital Twin. Digital Twin and Digital Thread are foundation of Digital Transformation. A Successful Digital Twin is not only about technology it is achieved by addressing technological capabilities, process improvements and people centred reinvention..
Digital Twin blurs the traditional boundaries between physical and virtual environment ideally bringing together Information Technology and Operations Technology to achieve a common goal. They both enable new ways to assess practices, processes, and product concepts in a virtual environment. Simply stated the digital twin is the current representation of a product or system, mimicking a company’s machines, controls, workflows, and systems. The digital thread meanwhile is a record of a product or systems lifetime, from its creation to its removal. Both can potentially have huge benefits for operating models, revenue stream and relationships in the future.
Goal of this article is to propose a meta-model driven solution framework where Digital Ops descriptive methodology expressed in deontic logic (permissions and obligations), help guide and incrementally refactor the existing Information technology and Operations Technology practices increasingly into cohesive, collaborative set of processes to climb the maturity ladder.
I. Digital Ops Deontic Logic
Deontic logic has been identified as a good specification language for information system in general. Deontic constraints are useful in defining soft integrity constraints dealing with violations of desirable process properties. In order to evaluate the maturity level, the Digital Ops solution component processes are evaluated against the desired constraints or requirements. Listed below are examples of deontic constraints with modalities categorized by Digital Ops solution components which constrain ontology based semantic analysis in order to evaluate the Digital Ops maturity level of the specific solution instance . These constraints are generalized in nature and must be modified according to the business domain and unique business and IT needs.
The Control Tower is an Operating model that addresses the most common challenges in organizations moving towards digitization and Digital Twin. Digital Operations potential reached by providing access to users to data from all levels. Data availability and capture is fundamental for the success of the Digital Operations. In our approach we identify, which data could be ready available, which data should only be connected in later stages, including insight and knowledge from operators and experts.
II. “ Composable Digital Operation” Solution Architecture
Figure 2 describes the high level Digital Operation solution framework that enables iterative collaborative up-skilling and collaboration value measurement. Major solution components are:
An execution container for Composable Digtal Ops uber processes which controls the behavior of Digital Ops method for various outcome delivery. The composable Digital Ops platform reads a Domain Specific Declarative configuration that captures the high level business requirements, Digital Ops method component (Design, Configure, Build, Quality Assurance, Deployment etc.) specific requirements in the form of declarative policy and data items. Hints about Solution Domain, Digital Ops maturity level, Digital Ops method runtime technology assist the Composable Digital Ops runtime to assemble the Digital Ops Digital Twin /Digital Thread instance that is fit for purpose and fit to use. Deontic policies for various components guides the Digital Ops maturity controls to check periodically through management workflows to ensure policy adherence as well as Digital Ops adoption progress and performance. Changes in organizational roles, hierarchy as well as culture affect the requirements thus also affecting the mapping of Digital Ops maturity controls and policy items. Therefore, policy will have a process for controlling its overall lifecycle.
I. Ontology based DigitalOps Maturity Evaluation automation
A meta model for Digital Ops Maturity evaluation i.e. DigitalOps-Maturity-Evaluation-Ontology is proposed, based on which, Digital Ops Business constraints can be modeled into Web Ontology Language (OWL) axioms and Semantic Web Rule Language (SWRL) rules.
An activity (Design-Configuration-Assessment-Activity) from the Digital Ops Maturity Evaluation Process Flow has been used to show how business and deontic constraints are applied to evaluate Digital Ops maturity. This meta model is influenced by “Ontology-based semantic modeling of regulation constraint for automated construction quality compliance checking” as described by B.T. Zhong, L.Y. Ding, et al.. Digital Ops Maturity Ontology serves as a meta model, defining the concepts and relations related to the Digital Ops Maturity evaluation. Validation-Task class is the central concept in this Ontology. A Validation-Task is set according to the specific deontic constraint. A Validation-Task can be related to the Validation-Object through the “hasValidationObject” property, which indicates that the Validation-Object will be inspected to make sure their compliance to the relevant deontic constraints through the execution of the Validation-Task. The Validation-Object refers to any concepts governed by business and indicates what is to be inspected, in the case of Digital Ops Maturity Evaluation domain the entities include identification, evaluation, remediation processes (activities and procedures), the Digital Ops methods and resources used in validation. An Validation-Object may include a set of process optimization validation items. These validation items can be identified from the business constraints. For example, some of the Digital Ops business constraints are:
The validation items include design configuration assessment activity, operations incident team access verification activity, and so on.
Furthermore, a Validation-Task needs a set of Validation-Item-Checking-Action to test and collect the policy adherence information/data for the validation items. Each Analysis-Item-Checking-Action has a Validation-Result, which represents the actual policy adherence modal response collected. Similarly, a Validation-Task needs a set of Evaluation-Task to evaluate the provenance of those Validation items in accordance with the Evaluation-Criteria. The Evaluation-Criteria is imposed by set by the domain experts according to the business criteria. Basing on the Checking-Result and the Evaluation-Criteria, the Evaluation-Task can be done to judge whether the validation items are compliant with the business constraints. Each Evaluation-Task has an Evaluation-Result, which all together are constituted the Validation-Report. The Validation-Report of a particular Validation-Task for the corresponding Validation-Object can be documented, based on the Evaluation-Result of all the validation items. In Digital Ops Maturity Ontology, the Deontic-Constraint constitutes the main Validation knowledge, since the focus is the deontic-constraints-based Digital Ops maturity analysis.
As shown in Figure 3, the Validation-Object can be the IT functional model, IT Security Model, IT Configuration model, Business processes, and Digital Ops method model or user activities and so on. Basing on the meta model, the specific domain model for the Digital Ops maturity checking can be obtained via specializing and instantiating the generic concepts and relations in the meta model. Since the meta model is not limited to any specific Digital Ops pattern or model, the meta model can be reused independently of any specific Digital Ops implementation. Basing on the meta model and the ontology, the constraints knowledge imposed by the enterprise can be clearly and unambiguously defined such that they may potentially be interpreted by a machine.
Based on Digital Ops Maturity Ontology and the business processes, each maturity validation task can be modeled as an ontology instance. Figure 4 shows the Digital Ops Maturity Ontology instance for Continuous Delivery maturity checking. In order to make the ontology knowledge understandable to both machines and human beings, the ontology knowledge is described in OWL. OWL is a W3C recommended language for ontology representation on the semantic web. It offers a relatively high level of expressivity while still being decidable. In addition, OWL, as a formal language with description logic based semantics, enables automatic reasoning about inconsistencies of concepts, and provides RDF/XML syntax to represent ontology.
A. Existential restriction
Existential restriction “One Validation-Task has at least one Validation-Item-Checking-Action” can be modeled in the following axioms
Axiom A1. “Validation-Task hasValidationItem
PolicyAdherenceCheckingAction only Validation-Item-Checking-Action”
Axiom A2. “Validation-Task hasValidationItem
PolicyAdherenceCheckingAction min 1” can be expressed in below OWL format
<owl:Class rdf:ID=”Validation_Task”>
<rdfs:subClassOf>
<owl:Restriction>
<owl:allValuesFrom>
<owl:Class rdf:ID=”Validation-Item-Checking-Action”/>
</owl:allValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:ID=” hasValidationItemPolicyAdherenceCheckingAction “/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality rdf:datatype=”http://www.w3.org/2001/XMLSchema#int">1</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about=” #hasValidationItemPolicyAdherenceCheckingAction “
/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</rdfs:subClassOf rdf:resource=”http://www.w3.org/2002/07/owl#Thing"/>
</owl:Class>
B. Constraints
Constraint, “Designer must have access to the operations / support team incident details” can be modeled in the following Axiom A:
<owl:Class rdf:ID=”Incident-Details-Access”>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource=“#access-control-list”/>
<owl:minCardinality rdf:datatype=”http://www.w3.org/2001/XMLSchema#int">1</owl:minCardinality>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:unionOf rdf:parseType=”Collection”>
<owl:Class rdf:about=”#UID5E3604” />
<owl:Class rdf:about=”# UID5E3605” />
<owl:Class rdf:about=”# UID5E3606” />
…………………. …………………………
</owl:unionOf>
</rdfs:subClassOf rdf:resource=”http://www.w3.org/2002/07/owl#Thing"/>
</owl:Class>
Axiom B.
<owl:Class rdf:ID=”incidence-management-system”>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource=”#hasType”/>
<owl:hasValue rdf:resource=”#ops-incident-management-system”/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Typical constraints in the business occur in the form of rules. SWRL is a good candidate to represent the constraints rules, since SWRL rule language is tightly integrated with OWL and the predicates in SWRL rules may be OWL-based classes or properties. The use of SWRL rules along with OWL axioms results in more powerful constraints and intuitive inferring capability, which could not be achieved through the use of axioms alone. Another benefit is that SWRL is a descriptive language that is independent of any rule language internal to rule engines, which decouples the rules from the technical implementation of the rules engine. For example, the constraint “There must be an agreement between business, design and ops on critical services that are necessary to meet pre-defined business goals”, can be modeled in Axiom C1 & C2 and SWRL Rule 1:
Rule 1. Digital-Ops-Business-Agreement-Exists-Verification-Activity (?CT_aa) ? Predefined-Business-Goals-Exists-Verification-Activity (?CT_bb) ? isDirectlyBefore(?CT_aa, ?CT_bb )
Axiom C1. Digital-Ops-Business-Agreement-Exists-Verification-Activity isDirectlyBefore only Predefined-Business-Goals-Exists-Verification-Activity
Axiom C2. Digital-Ops-Business-Agreement-Exists-Verification-Activity isDirectlyBefore exactly 1
Here, Rule 1 is written in terms/concepts from the Digital Ops Maturity Analysis process model. Rule 1 indicates that the existence of one instance of the Digital-Ops-Business-Agreement-Exists-Verification-Activity implies the existence of one corresponding instance of the Digital-Ops-Business-Agreement-Exists-Verification-Activity, and the constraints represented by object property isDirectlyBefore should be met.
The implementing soft environment is shown in Figure 5. Ontology editor enables the users to load and save OWL and RDF ontologies, edits and visualizes classes, properties, and SWRL rules, defines logical class characteristics as OWL expressions, executes reasoners such as description logic classifiers and edits OWL individuals. actual reasoning process is conducted through the rule engine. The rule engine converts a combination of OWL+SWRL into new facts. The inferences are carried out in Rule engine inference engine by matching facts in working memories in accordance with the rules in rule base. Also, if the inference engine infers knowledge using forward chaining, the new knowledge can be used for further inference or querying stored or inferred knowledge.
References
[1] Khan. Shakil M., McCarthy. A. Mathew, Heregr. M. Lorraine, Belgodere. M. Brian (2015), “Composable DevOps”, IEEE
