The Kernel Journals 2: An executable model of software development

The Kernel Journals 2: An executable model of software developmentI first learnt about the power of domain models more than 25 years ago when I first applied the Jackson System Development (JSD) process. This approach involves modeling the key conceptual entities in the problem domain and the business rules that define how value is delivered by advancing the value states of these key entities. Add a few key business attributes and you now have an executable model of your problem domain / business. You can then simulate the execution of your business merely by slapping some rough-and-ready user-interface screens onto these entities.
When object-orientation proper arrived I was fortunate that one of my first points of reference was Ivar Jacobson’s book on Object-Oriented Software Engineering. I was particularly struck by a statement on Page 340: “to start identifying the use cases it is often appropriate to have a first picture of the system in terms of some problem domain objects”.  And so it has proved to be on the numerous software development projects I have been involved with ever since.

So, why have we as software process engineers not got around to eating this most excellent and nutritious software process dog-food ourselves?

As part of Ivar Jacobson International I was lucky enough to be around when Ivar and his team first asked and answered this question some four years ago by developing just such an executable process model, which we call a process kernel. The beating heart of this process kernel is (… wait for it …) a domain model of the key entities that we need to progress (known as “Alphas”) and the states that we progress them through as we execute a software development project.

In the next few blogs I will share some of the experiences I have had over the past few years in applying this simple but powerful concept to solve a number of process problems for my customers, including:

  • How can we get rid of our process documentation overheads without losing process maturity?
  • How do project teams get the help they need, when they need it, without prescriptive process?
  • How can we enable teams to own and adapt their working practices efficiently and effectively?
  • How can we judge whether a team’s way of working is sufficient / fit for purpose?
  • How can we share successful team practices and the lessons learned in applying them?