2015 IEEE International Conference on Services Computing
Composable DevOps
Automated Ontology Based DevOps Maturity Analysis
Matthew A. McCarthy Lorraine M. Herger
IBM Corporation, IBM Corporation,
Office of the CIO IBM Research
Raleigh, NC Yorktown Heights, NY
USA USA
matthew.mccarthy@us.ibm.com herger@us.ibm.com
Abstract— In this era of the emerging digitized, mobilized, and
cloudified enterprises, the concept of the “composable
business” is the most critical piece which ties everything
together. The digital enterprise is here, and its prime
characteristic is that is essentially detaches and segregates
existing businesses and reassembles them according to market
demands. Every industry, from transportation to eyewear is up
for disruption, and developers are in the forefront of this
movement. In turn, these developers are under intense
pressure to accelerate time to market.
The composable enterprise approach requires a
reconsideration of traditional models of the entire IT
organization. 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, portability, Shared Knowledge, Predictable
Contracts and Maximized Human Value. The last three bullet
points encapsulate the very definition of DevOps [3].
The concept of better integration between Development and
Operations is a valuable objective. The goal is to foster
measurable incremental cultural 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 composable enterprise framework
to build a platform using the right tools and you will have
attained DevOps nirvana. In this paper we will explore
valuable lessons learned from our mistakes in tool centric
adoption of IT Infrastructure Library (ITIL) [8] . We will also
show how we applied those lessons to develop a lightweight
composable/contextual DevOps framework that learns and
measure itself to avoid those cultural pitfalls.
Keywords-devops;itil;maturity;ontology;deontic;semantic
I. INTRODUCTION
Cloud, Analytics, Mobility, Social, and Security are
making huge waves in the way traditional IT thinks and
reacts. These forces of change have made the end user the
king who is placing all kinds of demands on IT. Business
leaders are concerned about engaging these savvy customers,
and won't wait for IT to provide the technologies they need.
Business and developers are not constrained by what their IT
organization provides anymore. There is a proliferation of
“Shadow IT” or “Stealth IT”, IT solutions built and used
978-1-4673-7281-7/15 $31.00 © 2015 European Union
DOI 10.1109/SCC.2015.87
Authorized licensed use limited to: National University Fast. Downloaded on September 24,2020 at 10:09:33 UTC from IEEE Xplore. Restrictions apply.
Shakil M. Khan Brian M. Belgodere
IBM Corporation, IBM Corporation,
IBM Research IBM Research
Yorktown Heights NY, Yorktown Heights, NY
USA USA
smkhan@us.ibm.com bmbelgod@us.ibm.com
inside business organizations without explicit IT
organizational knowledge or approval, in order to meet the
new time to market requirements being placed on Business
lines and quickly provide the services consumers are
seeking. These factors are exerting enormous pressure on IT
to adapt to the evolving enterprise needs of the business lines
in order to stay relevant, while still meeting their metrics
they have traditionally been judged on of Reliability and Up-
time.
In most enterprises, developers who need to move fast
and implement changes quickly in response to changing
business demands run into very legitimate barriers and
concerns from their IT and “governance” teams when they
bring their ideas to the table. The groups responsible for
creating and supporting applications and solutions are
chartered with ensuring that data and intellectual property are
secure, privacy laws and other regulations are complied with,
and that the solutions are “future proof” and smart
investments. The stewardship of one group to protect the
company and the other to accelerate the response to change
creates tension, frustration, and conflict.
This is the harbinger of DevOps adoptions. DevOps blurs
the traditional boundaries between developers and IT by
ideally bringing together development and operations to
achieve a common goal. “Writing the code” and “making
them work on a platform” are the kind of works done by
different types of people who traditionally worked separately
and implemented entirely different methodologies and
workflows. For example, ITIL for IT operations and Agile
for Development. A clear disconnect exists there as the two
teams speak two different languages and have traditionally
been judged by different reward structures. There is also fear
that this collaboration along with “up-skilling” Application
developers with the awareness of the operations as well as
codification of the operation domain knowledge will end up
in loss of controls, diminished responsibility, and possible
job redundancy.
Successful DevOps requires a change in mindset – all
parties involved need to share responsibility for the success
or the failure of the product. Enterprises cannot buy DevOps
off the shelf as many vendors would like you to believe.
Nobody can implement DevOps for an enterprise. Enterprise
needs to create fertile ground inside the organization to foster
the DevOps mentality. Each and every component of
DevOps has its own timeframe and path to maturity which
600
cannot be forced without disastrous effects. Not every
traditional metric is applicable at every maturity level.
Allowing clearly defined roles to work within their comfort
zone, with tools they are comfortable with is the first big step
in adopting DevOps culture within the enterprise. Goal of
this paper is to propose a meta-model driven solution
framework where DevOps descriptive methodology
expressed in deontic logic (permissions and obligations),
help guide and incrementally refactor the existing
Development and Operations practices increasingly into
cohesive, collaborative set of processes to climb the maturity
ladder.
Figure 1. DevOps Maturity and Composable DevOps.
II. IT INFRASTRUCTURE LIBRARY(ITIL) ADOPTION
NIGHTMARE- LESSONS LEARNED
The Information Technology Infrastructure Library
(ITIL) is a framework of best practice approaches intended
to facilitate the delivery of high quality information services.
In order to facilitate the integration and automation of ITIL
best practices, ITIL specifies the use of a Configuration
Management Database (CMDB) [12] to leverage a single
source of information for all configuration items (CI) such as
computer system, operating systems, and software
installation. The configuration management process includes
performing tasks such as identifying configuration items and
their relationships, and adding them to the CMDB. The
contextual mapping of CIs stored into CMDB provides the
basis for converting the information into a knowledge graph
(RDF) [2] based Semantic model. This allows us to traverse
the relationship to form pattern-based queries and deduce
other implicit relationships, which may not be stored. This
permits meshing an external information graph with the
CMDB knowledge graph through entailment. In the presence
of partial information (an essential feature of low quality
data) the output is still a consistent Resource Description
601
Authorized licensed use limited to: National University Fast. Downloaded on September 24,2020 at 10:09:33 UTC from IEEE Xplore. Restrictions apply.
Framework (RDF) model, which can be successfully
processed but with weak or ambiguous inference.
Like DevOps, ITIL is not something one implements, it
is not a standard. It is a set of best practices that one can
integrate into the unique properties of one’s IT organization.
There are two key components of any organizational
improvement, and that is process improvement and the
ability of people to change or adapt to change. This is highly
dependent on clean, contextual data regarding people,
process, infrastructure etc. Most of the vendors for CMDB
interpreted the ITIL prescribed CMDB functions as dogma
and came up with proprietary implementations that are
inflexible and understands their prescribed data format. For
example IBM CMDB only support IDML format in order to
import external data. For automated CI and their relationship
discovery and reconciliation, IT operations usually uses
assortment of centralized discovery agents that significantly
reduced the agent deployment and management costs across
thousands of servers. They expect a solution that consumes
discovery data with varying format with minimal data format
manipulation, requires low CMDB API learning curve, and
provides fast query response and CI reconciliation.
Unfortunately cleansing, contextualizing and reconciling
various discovered data into CMDB format takes so long that
it sort of becomes prohibiting in the way of realizing quick
value of ITIL. Another prohibiting factor is the Service
Management application’s inability to work straight off the
CMDB configuration data. For example IBM SmartCloud
Control Desk requires CMDB configuration data to be
imported and persisted into native format.
Hence key to successful ITIL or DevOps adoption is not
making teams listen to what a best-of-the-breed tool asks
them to do. It’s rather understanding the unique properties of
the enterprise, existing processes, existing team specific
skillsets and applying those to show quick ROI.
III. DEVOPS DEONTIC LOGIC
Deontic logic[16] 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
DevOps pipeline component processes are evaluated against
the desired constraints or requirements. Listed below are
examples of deontic constraints with modalities [14,16]
categorized by DevOps pipeline components which constrain
ontology based semantic analysis in order to evaluate the
DevOps maturity level of the specific pipeline instance .
These constraints are generalized in nature and must be
modified according to the business domain and unique
business and IT needs.
TABLE I. DEONTIC CONSTRAINTS
Constraints Features
Phases
Description Modality
Developers obligated to create a
development sandbox that closely
Dev/Test
matches production - even when physical Obligation
resources are constrained for all
 Constraints Features ITIL Agile
Phases
Description Modality …...
DevOps Team
dependent systems

Dev/Test Developers must have access to the Obligation

operations / support team incident details
and conduct formal/informal meetings to Dashboard
Recommendation
And Refactoring Monitoring
improve application supportability Engine Pipeline Process
Runtime
Dev/Test Testing teams must share their validation Obligation DevOps DSL Deployed Application
mechanisms and strategies with Generator
Development and Operations DevOps Analytics
Dynamic
Dev/Test There must be an agreement between Obligation DevOps Pipeline
Maturity Tracker
Datasources
Process
business, dev and ops on critical services Composer Process Optimization
DevOps Change Management
Pipeline
(transaction counts, performance, uptime Automation Instance Configuration
Metrics Generator Optimization
etc.) that are necessary to meet pre- Collaboration
Provision
Engine
Management

Knowledge Havestor Compliance as a

defined business goals Self learning and
Optimization
Service

Dev/Test Developers must have a centralized Obligation auto optimization

portal in order to access, develop and test COMPOSABLE DEVOPS RUNTIME

API's as they code their applications
Dev/Test Development teams must use automated Obligation
testing across the software development Private Docker
Registry for
Pipeline Process
Automation
lifecycle DevOps Pipeline
artifacts
tools
Team must provide overall visibility into Obligation Cloud
Release/
your application release activities and Deontic
Deploy Policy RDF
timing to all major stakeholders repository
Cloud
Application release deployments must be Obligation Composable DevOps
Release/ fully automated end-to-end across Configuration
Deploy development, test and production store

environments
Teams must be able to provide self-
Release/ service, on-demand provisioning and
Deploy management of cloud environments and
infrastructure resources
Team must be able to speed lead times
Release/ and make more frequent application
Deploy deployments at the pace demanded by
the business
Number of tools required to monitor
Operate network, systems, databases etc. must be
/Assure consolidated to reduce complexity and
speed time to problem resolution
Teams must have the visibility and
insight you need to ensure reliable
Operate business service delivery for the
/Assure applications and business services that
have moved to third-party cloud
providers
Teams must have visibility into capacity
in order to understand the impact on
Operate
infrastructure when there are increases in
/Assure
workload, transactions, application
upgrades, and hardware refreshes
Teams must have access to feedback
Operate
information on mobile app behavior and
/Assure
usage analytics to drive improvements
Teams must automate the feedback of
Operate
critical performance information across
stages of the application lifecycle so as to
/Assure
further optimize applications and
services
IV. “COMPOSABLE DEVOPS” SOLUTION ARCHITECTURE
Figure 2 describes the high level Composable DevOps
solution framework that enables iterative collaborative up-
skilling and collaboration value measurement. Major
solution components are:
Obligation
Figure 2. Composable DevOps solution architecture.
Obligation A. Composable DevOps Runtime
An execution container for Composable DevOps uber
processes which controls the behavior of DevOps pipeline
Obligation instances for various product and feature delivery. The
composable DevOps platform reads a Domain Specific
Declarative configuration that captures the high level
business requirements, DevOps pipeline component
Obligation
(Configure, Build, Quality Assurance, Deployment etc.)
specific requirements in the form of declarative policy and
data items. Hints about Solution Domain, DevOps maturity
level, DevOps pipeline component runtime technology assist
the Composable DevOps runtime to assemble the DevOps
Obligation pipeline instance that is fit for purpose and fit to use. Deontic
policies for various components guides the DevOps maturity
controls to check periodically through management
workflows to ensure policy adherence as well as DevOps
Obligation
adoption progress and performance. Changes in
organizational roles, hierarchy as well as culture affect the
Obligation requirements thus also affecting the mapping of DevOps
maturity controls and policy items. Therefore, policy will
have a process for controlling its overall lifecycle.
B. Composable DevOps Controller
This is the centralized management system for DevOps
pipeline provisioning. The controller co-ordinates with
various distributed policy-aware components to foster
collaboration in a fully automated fashion. The controller
continuously polls filtered monitoring data as well as other
complementary information through an event collection
framework. It indexes and aggregates the machine produced

602

Authorized licensed use limited to: National University Fast. Downloaded on September 24,2020 at 10:09:33 UTC from IEEE Xplore. Restrictions apply.
data, applies DevOps maturity control contexts and persists
in the repository. It then invokes Composable DevOps
analytics and native algorithms to compute process and
collaboration drifts that impacts the plan, process and actions
of getting closer to the target maturity level. If components
are determined to be out of policy adherence, the controller
invokes the Composable DevOps management plan
(Remediation and Refactoring Engine) to remediate the non-
adherence. All the maturity level computations are also
validated by a metadata driven controller function called the
“Process Maturity provenance function”. Finally, the
controller provides functions to formalize knowledge derived
from trend analysis and applies the knowledge to predict
corrections in process, collaboration and methodology
adoptions.
C. Deontic Constraints and Semantic Analyzer
Semantic Analyzer uses Ontology[17] and Semantic
Web Technologies[19] to model building of Business goals
as well as DevOps people, process, monitoring etc. related
knowledge and implement maturity criteria validation
techniques using deontic constraints.
D. Monitoring Framework
The Event collection Framework enables modularized
solutions to collect events and alerts from key domains in a
common format. This Framework also allows defining
domain specific event filters created through the DevOps
Dashboard.
E. DevOps Portal
DevOps teams uses the portal to compose the DevOps
pipeline provision configuration in a collaborative fashion. It
allows team to register various pipeline component artifacts
to an application lifecycle management project. The portal
also allows creating plug-in for external services (Change
Management, Configuration Management, Identity as a
Service, Compliance as a Service etc.) as well as various
monitoring services. The portal also provide dashboard to
show metrics and Key Performance Indicator ( KPI)
pertaining to DevOps maturity level.
F. DevOps DSL Generator
DevOps Domain Specific Configuration is the key set of
information that the Composable DevOps controller uses to
provision a specific instance of DevOps pipeline for a
specific maturity level. Defining DSL is a collaborative
effort between Dev and Ops team. Private Docker [15]
registry contains multiple tools’ images for each pipeline
component. Each tool is indexed with DevOps maturity
level. Tool selection for each Composable DevOps pipeline
component depends on maturity level. This could be
overwritten by DSL author.
G. DevOps Pipeline Instance Provisioning Engine
The provision engine uses DevOps DSL configuration to
pick up appropriate components for the pipeline instance. It
also plug-in appropriate tools to each components. The
Docker private registry contains images of tools baked with
603
Authorized licensed use limited to: National University Fast. Downloaded on September 24,2020 at 10:09:33 UTC from IEEE Xplore. Restrictions apply.
Composable DevOps monitoring plug-in and communication
hook back to Composable DevOps Management processes.
Based on the various criteria, for example, parallel/sequential
build or test, the provision engine may deploy component
processes in single private or hybrid cloud.
Figure 3. DevOps pipeline instance provision examples.
V. ONTOLOGY BASED DEVOPS MATURITY EVALUATION
AUTOMATION
A meta model for DevOps Maturity evaluation i.e.
DevOps-Maturity-Evaluation-Ontology is proposed, based
on which, DevOps Business constraints can be modeled into
Web Ontology Language (OWL)[17] axioms and Semantic
Web Rule Language (SWRL)[18] rules.
An activity (Development-Configuration-Assessment-
Activity) from the DevOps Maturity Evaluation Process
Flow has been used to show how business and deontic
constraints are applied to evaluate DevOps 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. [1] . DevOps Maturity Ontology serves as a
meta model, defining the concepts and relations related to the
DevOps 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 DevOps Maturity
Evaluation domain the entities include identification,
evaluation, remediation processes (activities and
procedures), the DevOps products 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, model or user activities and so on. Basing on the meta
some of the DevOps business constraints are: model, the specific domain model for the DevOps maturity
checking can be obtained via specializing and instantiating
TABLE II. DEVOPS BUSINESS CONSTRAINTS the generic concepts and relations in the meta model. Since
Feature the meta model is not limited to any specific DevOps pattern
Description Goal
or model, the meta model can be reused independently of
Code Shipping : 30x faster any specific DevOps implementation. Basing on the meta
Deployment Frequency model and the ontology, the constraints knowledge imposed
Deployment : 8000x faster
Deployment Speed An hour or less by the enterprise can be clearly and unambiguously defined
such that they may potentially be interpreted by a machine.
Failure Rate 50% less
Time to Recovery 12x faster ( less than an hour)

The validation items include development 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 Figure 5. DevOps Pipeline Instance maturity ontology.
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 DevOps
Maturity Ontology, the Deontic-Constraint constitutes the
main Validation knowledge, since the focus is the deontic-
constraints-based DevOps maturity analysis.

Figure 6. Maturity Ontology and evaluation process instance.

Based on DevOps Maturity Ontology and the business

Figure 4. DevOps Pipeline Instance maturity evaluation.
As shown in Figure 5, the Validation-Object can be the
IT functional model, IT Security Model, IT Configuration
model, Business processes, and DevOps pipeline process
processes, each maturity validation task can be modeled as
an ontology instance. Figure 6 shows the DevOps 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

604

Authorized licensed use limited to: National University Fast. Downloaded on September 24,2020 at 10:09:33 UTC from IEEE Xplore. Restrictions apply.
semantic web. It offers a relatively high level of expressivity </owl:onProperty>
while still being decidable. In addition, OWL, as a formal </owl:Restriction>
language with description logic based semantics, enables </rdfs:subClassOf>
automatic reasoning about inconsistencies of concepts, and <owl:unionOf rdf:parseType=”Collection”>
provides RDF/XML syntax to represent ontology. <owl:Class rdf:about=”#UID5E3604” />
<owl:Class rdf:about=”# UID5E3605” />
A. Existential restriction <owl:Class rdf:about=”# UID5E3606” />
Existential restriction “One Validation-Task has at least …………………. …………………………
one Validation-Item-Checking-Action” can be modeled in </owl:unionOf>
the following axioms </rdfs:subClassOf
Axiom A1. “Validation-Task hasValidationItem rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
PolicyAdherenceCheckingAction only Validation-Item- </owl:Class>
Checking-Action” Axiom B.
Axiom A2. “Validation-Task hasValidationItem <owl:Class rdf:ID=”incidence-management-system”>
PolicyAdherenceCheckingAction min 1” can be <rdfs:subClassOf>
expressed in below OWL format <owl:Restriction>
<owl:onProperty
<owl:Class rdf:ID=”Validation_Task”> rdf:resource=”#hasType”/>
<rdfs:subClassOf> <owl:hasValue rdf:resource=”#ops-
<owl:Restriction> incident-management-system”/>
<owl:allValuesFrom> </owl:Restriction>
<owl:Class rdf:ID="Validation-Item- </rdfs:subClassOf>
Checking-Action"/> </owl:Class>
</owl:allValuesFrom> Typical constraints in the business occur in the form of
<owl:onProperty> rules. SWRL is a good candidate to represent the constraints
<owl:ObjectProperty rdf:ID=" rules, since SWRL rule language is tightly integrated with
hasValidationItemPolicyAdherenceCheckingAction "/> OWL and the predicates in SWRL rules may be OWL-based
</owl:onProperty> classes or properties. The use of SWRL rules along with
</owl:Restriction> OWL axioms results in more powerful constraints and
</rdfs:subClassOf> intuitive inferring capability, which could not be achieved
<rdfs:subClassOf> through the use of axioms alone. Another benefit is that
<owl:Restriction> SWRL is a descriptive language that is independent of any
<owl:minCardinality rule language internal to rule engines, which decouples the
rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1 rules from the technical implementation of the rules engine.
</owl:minCardinality> For example, the constraint “There must be an agreement
<owl:onProperty> between business, dev and ops on critical services that are
<owl:ObjectProperty rdf:about=" necessary to meet pre-defined business goals”, can be
#hasValidationItemPolicyAdherenceCheckingAction " modeled in Axiom C1 & C2 and SWRL Rule 1:
/> Rule 1. Dev-Ops-Business-Agreement-Exists-
</owl:onProperty> Verification-Activity (?CT_aa) ? Predefined-Business-
</owl:Restriction> Goals-Exists-Verification-Activity (?CT_bb) ?
</rdfs:subClassOf> isDirectlyBefore(?CT_aa, ?CT_bb )
</rdfs:subClassOf Axiom C1. Dev-Ops-Business-Agreement-Exists-
rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> Verification-Activity isDirectlyBefore only Predefined-
</owl:Class> Business-Goals-Exists-Verification-Activity
Axiom C2. Dev-Ops-Business-Agreement-Exists-
B. Constraints
Verification-Activity isDirectlyBefore exactly 1
Constraint, “Developers must have access to the Here, Rule 1 is written in terms/concepts from the
operations / support team incident details” can be modeled in DevOps Maturity Analysis process model. Rule 1 indicates
the following Axiom A: that the existence of one instance of the Dev-Ops-Business-
Agreement-Exists-Verification-Activity implies the
<owl:Class rdf:ID=”Incident-Details-Access”> existence of one corresponding instance of the Dev-Ops-
<rdfs:subClassOf> Business-Agreement-Exists-Verification-Activity, and the
<owl:Restriction> constraints represented by object property isDirectlyBefore
<owl:onProperty rdf:resource=“#access- should be met.
control-list"/> The implementing soft environment is shown in Figure 8.
<owl:minCardinality Ontology editor enables the users to load and save OWL and
rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1 RDF ontologies, edits and visualizes classes, properties, and
</owl:minCardinality> SWRL rules, defines logical class characteristics as OWL

605

Authorized licensed use limited to: National University Fast. Downloaded on September 24,2020 at 10:09:33 UTC from IEEE Xplore. Restrictions apply.
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.
Figure 7. Soft Environment for Semantic Analysis.
VI. DEVOPS ANALYTICS AND MACHINE LEARNING
The heart of the Composable DevOps solution is the
ability to process massive amount of structured and
unstructured data using the Big Data analytics approach.
Composable DevOps analytics has the ability to analyze both
explicit and implicit knowledge and tie them together to
discover new contexts and new facts. This is essential for
DevOps maturity evaluation, process enhancement
recommendations and maturity control mapping.
VII. METADATA PROVENANCE FRAMEWORK TO ASSURE
AUTOMATED DEVOPS MATURITY PATH DECISIONS
DevOps automation is composed of complex interactions
between actionable policies and processes. Policy must be
decomposable to discrete action plans. Those, in turn, should
be mapped to domain-specific roles, permissions and
obligations. Processes responsible for interrogating DevOps
maturity controls for current state of the operation, validating
conformance, performing actions to bring components out of
non-adherence should be generating process execution
metadata to trace the execution path. These metadata could
be analyzed to understand the process integrity and behavior
and the accuracy of the decisions. Again, learning from these
analyses could be formalized and fed back to the
Composable DevOps controller. The Composable DevOps
controller may modify or control the process behavior
through domain-specific, dynamic policies or process
modification. Figure 3 shows high-level components of
metadata driven provenance framework.
606
Authorized licensed use limited to: National University Fast. Downloaded on September 24,2020 at 10:09:33 UTC from IEEE Xplore. Restrictions apply.
Figure 8. Meta data driven provenance.
VIII. CONCLUSIONS FROM THE LESSONS LEARNED
We understand that most important factor for the
successful adoption of DevOps in an organization is the
ability to resolve 99 percent of the daily issues without the
help of any external party. There is no feasible way to
achieve this when different parts of the delivery pipeline
required for normal work are owned by different teams.
Cross-functional DevOps teams and programmable build,
test, and infrastructure are essential for the constant flow of
changes through the pipeline to the customers. Given the
cross-functional team is made of people from dissimilar
background, skillsets, mentality and priorities, it is
incumbent that the sooner they start speaking and
understanding the same language the brighter the future
looks for a successful DevOps adoption.
The goal of this project was to come up with solution
that will provide low friction upskilling of skillsets around
DevOps for developers as well as Operations and guide them
along low collision path. This required a domain solution
that will easily assimilate development and operations
domain knowledge and is adjustable with varying business
needs and focus. We found Semantic web technology to be
very valuable to address the need. Semantic web provided a
great way to decouple knowledge model from constraints.
Initially, our knowledge model was constrained only with
deontic constraints specifically defined for each DevOps
pipeline phase to produce modal responses “Yes’ and “No”.
The responses were collected for each validation activity and
later used in the computation of DevOps maturity. Later we
added “Partially” as modal response to support wider
maturity spectrum. So far, DevOps maturity level provided
good measure as to how collaboration was working. But
there was no indicator as to how optimized the DevOps
pipeline processes were. We decided to add DevOps metrics
defined as business constraints to address that shortcoming.
IBM Research has collaborative research projects with
clients, ranging from internal business units to external
clients - such as government and almost all vertical market
segments. Researchers need to run their experiments with
innovative architectures and algorithms in a datacenter
environment modeled around the ‘living lab’ concept in
order to pilot solutions for highly dynamic and volatile
markets in a timely fashion. This introduces tremendous
challenges in supporting heterogeneity in workloads. To the http://www.interoute.com/what-paas
researchers , the best IT tools and practices are simple and [11] OASIS extensible Access Control Markup Language (XACML)
lightweight. Their value is non-binary. They don’t make a https://www.oasis-
difference between right and wrong, or good and bad. open.org/committees/tc_home.php?wg_abbrev=xacml
Instead, the very fact of using them makes things better. [12] DMTF – Common Information Model
They need support for all kinds of tools. Also they require http://dmtf.org/standards/cim
high velocity feature deployment. [13] OASIS Topology and Orchestration Specification for Cloud
In contrast IBM CIO develops, deploys and manages Applications (TOSCA)
applications for external client with varying business https://www.oasis-
criticality. They want to hasten pervasive cultural changes open.org/committees/tc_home.php?wg_abbrev=tosca
holistically and through out the lifecycle. They like to [14] Assessing DevOps maturity
identify the “best” through try and learn. http://blogs.ca.com/2015/02/04/assessing-devops-maturity/
Both business units stand to gain a lot from the [15] Docker
configuration driven composable DevOps pipeline feature of https://www.docker.com/
our solution. They gained the flexibility to try out various [16] Deontic Logic
combinations of DevOps pipeline phase specific criteria and http://en.wikipedia.org/wiki/Deontic_logic
tools to find the best process that meet their requirements. [17] Web Ontology Language
http://www.w3.org/TR/owl-features/
IX. FUTURE WORKS [18] Semantic Web Rule Language
Boundariless Joint Development and Research is in the http://www.w3.org/Submission/SWRL/
heart of every agile enterprise.External clients are eager to [19] Semantic Web
collaborate with focused groups inside solution providing http://www.w3.org/standards/semanticweb/
enterprises to develop mixed solution assets in an agile
fashion. They also want the means to guide those solution
assets climb the maturity ladder and eventually convert those
into SaaS offering with scale.
This complex many-to-many collaboration requires
supporting unlimited programming models, operations
models to ensure low friction innovation path. This truly
calls for a “Composable Devops” solution proposed by us.
In fact, we launched a project named “IBM.Next” to
realize this vision.

REFERENCES
[1] Zhong , B.T., Ding , L.Y., Luo, H.B. , Zhou, Y., Hu, Y.Z., Hu, H.M
(2012) , “Ontology-based semantic modeling of regulation constraint
for automated construction quality compliance checking”,
ELSEVIER
[2] Edit. O. Lassila, R. Swick,”Resource Description Framework (RDF)
model and syntax specification”, Working Draft, W3C,1998
Electronic source for references without author nor publication time :
[3] DevOps- http://en.wikipedia.org/wiki/DevOps
[4] Software Defined Data Center SDDC
http://www.webopedia.com/TERM/S/software_defined_data_center_
SDDC.html
[5] Openstack – Open Source Cloud Computing Software
https://www.openstack.org/
[6] Infrastructure as a Service (IaaS)-
http://www.interoute.com/what-iaas
[7] SoftLayer- www.softlayer.com
[8] ITILV3-Service Asset and Configuration Management
http://www.itil.org/en/vomkennen/itil/servicetransition/servicetransiti
onprozesse/serviceassetconfigurationmgmt.php
[9] Security Information and event management (SIEM)
http://en.wikipedia.org/wiki/Security_information_and_event_manag
ementDevOps- http://en.wikipedia.org/wiki/DevOps
[10] Platform as a Service (PaaS)

607

Authorized licensed use limited to: National University Fast. Downloaded on September 24,2020 at 10:09:33 UTC from IEEE Xplore. Restrictions apply.