Build Or Buy?
In identifying the tools we'd use to implement the system, an important element of the build-versus-buy decision is knowing the critical differentiation of the project -- that's what should receive the heaviest investment. For WorldDoc, the design and implementation of the medical rule DSL and execution speed were the critical factors.
The rule authoring was important, but it was really a means to an end, not the core differentiation. Knowing that, and that we didn't want to overinvest in the portal, simplified how we created the Web-based Rules Authoring Portal. We needed a portal that could deliver a solid Web experience with workflow capability that integrates into existing databases as well as the new rules engine API. We selected the OutSystems Agile Platform, which simplified this process by building most of the user experience through its visual DSL that generates a .NET implementation. The OutSystems platform is a visual tool for creating and implementing not just the user interface but the entire code logic. More important for this project, it includes a customizable domain-specific language for developing and changing Web business applications. That allowed most of our resources to focus on delivering the core rules engine. But authoring a DSL language, building parsers and lexers, and integrating to external data is a big task. This demanded automation.
To help automate the DSL authoring, we turned to Antlr (short for "Another Tool for Language Recognition"). Antlr is a language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions containing actions in a variety of target languages. While the toolkit includes visual modeling and some interpreting capability, its most important feature for us is that it generates C# code to do the language parsing, lexing, and code generation.
With the decision to include Antlr in the mix, our implementation strategy became clear: Let clinicians author medical rules in our simplified DSL, then generate C# code for these rules, and finally compile these rules into native .NET code for high-performance execution.
Rapid Proof Of Concepts
At this point, we had a good hypothesis on how we were going to solve this business problem. The proof, however, is in the implementation.
We executed a two-month proof of concept in which we delivered a slice of functionality through each technology component, verifying that each would operate and integrate as advertised. This phase also included a clinician usability review to ensure that our new DSL was actually well designed for healthcare users. During this process, we proved the concepts and gathered many lessons learned for targeting the final product -- both in DSL changes and technology refactoring.
Deliver Using Agile Principles
Our project plan consisted of 16 sprints, with two dedicated to refactoring and performance tuning. About 25 percent of each sprint was planned for adjustments and refactoring. Each had a demonstrable deliverable with a focus on the current release. To manage scope, we ruthlessly avoided any feature description that started with the word "Someday …" And like all complex projects, we encountered our share of issues, feature triage, and spikes in team effort. Still, overall the process was smooth.
The WorldDoc project was an interesting technology challenge. We authored a DSL for clinicians with an easy-to-use Web-based user experience, by leveraging two approaches:
- A visual modeling DSL (OutSystems Agile Platform) to build the user experience in .NET; and
- A text-based DSL to author the WorldDoc healthcare intervention language and generate the C# code for the execution engine.
We managed risk by proving all the technology and integration points early in the process and kept the project on schedule by limiting scope, delivering early and often, and planning for our learning curve and refactoring needs.
This project couldn't have been delivered in this time frame and resources without the use of these DSL toolsets. The cost and complexity involved in evaluating and learning a DSL toolset can be a deterrent, but once you've delivered a complex project using the proper DSL for your problem domain, you'll never want to do it the old way again. As the popularity of DSL toolkits expands, we look forward to further toolkit improvements, which will continue to reduce developer ramp-up time.