Discovering Business Capabilities in Healthcare with Pure Domain Stories
Working on legacy systems comes often with a challenge of trying to figure out the underlying reasoning behind a piece of observable behavior. Perhaps coded years ago, those legacy system features are not easily linked with business needs that were present at a time. For the development teams that go serious about understanding the domain and providing value-added features, it may not be trivial to see what are the real business needs that drive the new requirements. Instead the requirements are often expressed as workarounds based on layers of existing functionality.
On the other hand the development team will often strive for software modularization and contextualization. Even though the improvements are gradual, it is important to choose the architectural direction in which the system will move. Investing in strategic Domain-Driven Design helps and a notable advice is provided in Udi Dahan’s Advanced Distributed System Design course, arguing for splitting the system along the lines of business capabilities. More support for approaching the problem domain in terms of business capabilities can be found in the contributions (video and blog post) from Trond Hjorteland.
Taking the challenges of legacy systems into account how do we proceed with finding the business capabilities?
Yet again help will come from strategic Domain-Driven Design and one of its collaborative modelling techniques, Domain Storytelling.
It turns out that the Domain Storytelling clearly highlights the very challenge of finding the business capabilities in legacy systems.
My previous experiences with the technique were in the domain of healthcare, most recently on a project for developing a system for use of group therapy in hospitals. A group therapy is a form of treatment where one or more therapists are working with several patients at the same time. In our case a legacy system for group therapy has been in place for many years, supporting two main use cases: documenting which patients have checked in for a group session (Group Check-in) and setting up a group schedule in advance (Group Planning).
We did our homework and arranged a workshop with domain experts from different departments. Using Domain Storytelling we focused on letting each domain expert tell her story for the main use-cases. Having the same use-case as an overarching criteria proved to be vital along with asking the domain experts to focus their stories on the way they did their job, not on how they used the legacy software system. The latter one in particular helped discover the differences in working methods that each domain expert employed. As a result, it became obvious that the way group therapy was practiced in mental health care institutions was rather different than comparing to somatic departments. Moreover, there were further deviations between the business needs of pediatric and adult group therapy fields.
The workshop revealed however, that the legacy system in production was little aligned to the boundaries defined by business capabilities, and accordingly the output of the workshop were the requirements expressed in terms of functionality supported by the legacy system. Following this approach, traditional “functionality-driven” boundaries are as follows:
Instead it was apparent that the application would align much better to the business needs if the boundaries followed the lines of business capabilities:
Even though the legacy systems obscured the original business capabilities beneath the layers of functionality built through the years, Domain Storytelling showed that it was possible to distill the intended business goals and impacts our customers had wanted to achieve and give us a momentum to align the system boundaries accordingly.
Some time later it turned out that this method of piercing through the clouds of legacy functionality was named Pure Domain Stories in the Domain Storytelling the book.
Takeaways
Investing in architectural improvements in the legacy system over time is the right thing to do, regardless of how overwhelming it seems to undertake the task at hand. Focusing on business capabilities leads to stable boundaries in the application thus aligning the architecture with the business goals and impacts.
Finding the business capabilities in the legacy system can be challenging since it is difficult to uncover the original intent behind almost any piece of functionality. A promising approach to deal with this challenge comes from Domain Storytelling collaborative modelling method. In a close collaboration with domain experts and by using Pure Domain Stories, the development team gets closer to discovering the business capabilities giving the team a clear direction in which to steer their efforts on improving the legacy system.
P.S. At KanDDDinsky 2023 conference I presented a talk about “Multiple Models with Multiple Perspectives in a Cross-Functional Team” where many of the ideas from this article where included. You may want to check the slides from the talk.
