![](bg2.png)
cumented to facilitate both development and
testing.
Build. Develop a minimum viable product (MVP)
(Moogk, 2012). The minimum viable product is
the bare basics of what you are building that is still
enough to test with customers. Why ”minimum”?
One principle of lean is that the speed of develop-
ment is crucial. This is not meant in a naive sense
of the word. What is fast will differ between dif-
ferent products. Speed is related to the idea of
getting feedback from users as early in the deve-
lopment process as possible. And while it is possi-
ble to involve users in the specifications stage with
focus groups and forums, it is always more com-
pelling to have users able to test out the product
and come to a fuller understanding of how their
expectations and your concepts, as embodied by
the product, differ. This is a central tenet of agile
software development and it is adopted by lean.
The demands of producing working software (or
ontology) force the development team to face is-
sues that might not be fully explored in the spe-
cifications stage and thus will identify issues and
force decisions that are best known soon than la-
ter. Thus, the true function of an MVP is to deliver
your concept or ideas to get feedback from users
as quickly as possible. It allows the development
team to collect the maximum amount of validated
learning about customers and their expectations of
the product with the least effort.
Measure. Start measuring. Your MVP (or it subse-
quent variants) will allow users to work with the
product. Both the development team and the users
will be able to perform traditional testing, realtime
monitoring, formal analysis and case studies. All
of these activities will provide data and feedback
to the development team in a way that is not bi-
ased by the viewpoint of the development team
only. Multiple viewpoints will be brought to bear
on the utility and capabilities of the product at this
stage.
Learn. Employ investigative methods to incorporate
the feedback into the product. At this stage there
can be several paths available: the concepts in the
current MVP can be modified to better suit the
user expectations; the next version of the MVP
can be developed by adding more capabilities to
the product; or it can be decided that there is a
need to pivot. As the MVP is tested and mea-
sured, it might be revealed that a hypothesis or
concept about the product is wrong. If this is the
case then a decision must be made to either ”per-
severe” or ”pivot” (Sekiguchi, 2018) (Eisenmann
et al., 2012). This decision is critical and is often
hard to accept. A pivot can be a total reimagining
of the product or it could be a refocusing of the de-
velopment on only a specific part of the product.
In all cases, this is a difficult decision but since
it will be supported by the facts in the Measure
stage it is hard to ignore.
Lean is a principled approach to new product de-
velopment. And it does not only provide a methodo-
logy to follow for the development of a product, it also
encourages the development team to ask the following
questions: ”Should this product be built?”, and ”Can
a sustainable business be built around this set of pro-
ducts and services?”. It is fairly obvious that the first
question can be easily repurposed to the development
of ontologies. The development of an ontology is a
long, hard process and thus should not be embarked
on lightly. But the second question, although it looks
like it is too ”business-y” to apply to ontology deve-
lopment is actually even more important for the de-
velopment of a lean ontology development methodo-
logy. It is a sad fact that although reuse is a major te-
net of ontologies, many ontologies have a very short
lifespan. Many are produced but few are reused. Even
upper level ontologies which should be sustainable
(constant evaluation, active users, new versions when
needed, etc.) are often active for only a few years
and then abandoned. So it is not outside the discus-
sion of development methodologies to borrow from
the world of commercial (and open source) software
development and to treat ontologies like substantial
software systems and apply a creation to deployment
to retirement (cradle to grave) view to ontology deve-
lopment.
2 LOD PRINCIPLES
This section will briefly outline the principles of Lean
Ontology Development (LOD) and will be used to
develop guidelines for methodologies to instantiate
these principles in practice.
One of the main tenets of LOD is that ontology de-
velopment should become much more like software
development. This does not imply that ontologies
need to be developed by computer scientists or soft-
ware engineers; the principle is that many of the esta-
blished techniques used in software development are
not yet fully embraced within ontology development
techniques explicitly and that this can be a disadvan-
tage.
The major design principles are:
Continuous Development. Since the LOD view of
ontologies is that they will undergo continuous
KEOD 2018 - 10th International Conference on Knowledge Engineering and Ontology Development
368