Indranil Bhattacharya is a specialist in large-scale systems design using participatory methods and knowledge engineering. Indranil is responsible for the strategy practice in Product Foundry, an Amsterdam based organization that specializes in building high-volume and cross-domain software solutions.
Information Technology is a new discipline and Domain Modeling is a new-born babe: where should we look for our natural roots? The presentation suggests two sources of inspiration. First, we look to ontology for the principles of organizing knowledge. Ontology is a discipline with 2000 years of experience on how to best model a domain and pose questions such as: What is it that makes a domain a domain? Are there universal characteristics true for all domains?
Second, we look to ethnography. Domain models are shaped by choices. Do these choices emerge purely through dialogue between technical and domain experts? Whose perspectives get incorporated into a domain and whose don't? Are some structures so universal they don't require consensus? Should models be strongly-typed so as to serve narrow constraints or weakly-typed to serve a broad spectrum of situations?
A trio of presenters will share their experience of a decade as ontology professionals. Indranil Bhattacharya will speak of several experiences: how to unify product knowledge in a large telco, what makes Human Resources different in different countries, and what makes logistics different around the globe. André Kampert will speak to bridging domain knowledge to code, and Jenny Quillien to the organization of this difficult discipline for adaptation in businesses which often don't know what they know and don't know and what knowing might be worth. A two-day pre- conference workshop is also offered as hands-on practice.
From domainlanguage.com:
Domain-Driven Design is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.
The premise is simple, but pulling it off in the messy real world is hard. It calls for new skills and discipline, and a systematic approach.
When technical and business experts get together to agree upon a domain model, what emerges is a consensus/compromise model reconciling the two perspectives. Most teams are agile, so being absolutely accurate about the domain isn’t deemed necessary. New perspectives and insights can be merged into later sprints, right?
However, sprints tend to build on previous sprints. Early messy assumptions about the domain fuel later messy assumptions about the domain. Developers start tackling uncertainty by making the domain more configurable, which adds to complexity. Or, the domain is made very weakly-typed so that any specialized and deep domain-specific logic requires new effort. The result is either a very loose domain model where introducing anything specific feels like programming it from scratch. Or it is a very configurable domain rife with complexity.
Then, things get worse when trying to integrate with other software. Work descends into reconciling one set of perspectives with another set. These isolated islands of domain models require complicated bridging and the integration effort to make two systems inter-operable is equivalent to making a third system.
It just doesn’t need to be this hard.
A little background. Information Science is a 2000-year old discipline and our legitimate source of inspiration. Information Technology, a new-born babe birthed just 70 years ago, was parented by the Mathematics, Philosophy, and Electrical Engineering Departments in universities. This was no accident. In the early days of computing (think of Alan Turing), an elite few schooled in these disciplines were given access to scarce computers. With the IT revolution of the 1980s, the proliferation of Internet access, and mushrooming of device diversity, this lineage gradually got lost. With the skyrocketing demand for IT professionals, schools watered down their programs. A revival of this lineage and its re-contextualization into modern concerns is required to strike a balance between business needs and engineering rigor.
The strength of this 'revival' approach is that it can accommodate both knowledge that can be explicitly represented and knowledge that can only be experienced. Consider the bicycle. The size, shape, and dimensions of a bicycle can explicitly be represented in a domain. Explicit procedural instructions of step-by-step guides on how to ride a bike can be established using text, images, and video. What can only be experienced, however, is the actual sensation of riding a bike. By using the grammar of ontologies, it is possible to represent explicit knowledge. And by using narratives of real life experience (another vocabulary and grammar coming from ethnographic field work), we can come close to describing the sensation of riding a bike. In this way, real-life situations can inhabit domain models in terms of both explicit and experiential knowledge.
This workshop instructs domain practitioners in how to build domain models that accommodate a variety of life situations. The two grammars help construct complete ontologies that consist of (a) entities that can exist by themselves (independents), (b) entities that exist as a consequence of relationships (relationals), and (c) entities that exist due to constraints applied on relationships (mediations). By systematically structuring domain models through these principles, models emerge that are greater than the sum of initial perspectives.
Is this a widespread approach? No. The workshop organizers have been developing and practicing this method for the past ten years by focusing on enabling knowledge-intensive domains like logistics, retail, telecommunications, and human resources to function in spite of poor IT. This knowledge isn’t about fulfilling computational transactions alone, but about the total knowledge needed to build complete systems.
Skill-Based and Hands-On. The two days move constantly between concept to application and back to concept for a deeper grasp.
Much of the first day is taken up with becoming literate in explicit and experiential grammar through explanations, examples, and short exercises. Then the participants are presented with some pre-researched domains and, in small groups of three, develop domain ontologies and identify ontological trade-offs (autonomy versus control for an obvious example). Participants can then think about how to apply this approach to domains they currently work with.
The workshop is for Developers, Analysts, Product Owners, Architects, ... who have already realized that making decent software requires in-depth domain knowledge and architectural trade-offs and who also realize that source code is a form of knowledge representation.
A sense of humor and an engineering attitude without any dogma.
Missed #DDDEU?
Get tickets for the next edition
