Channels ▼


Industry-Focused Development

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.

Several implementation challenges led to technology changes during the process. The WorldDoc system is a Web application and therefore the rule editor had to be Web based. The team considered JavaScript, applets, and Flash, and initially developed a fully functional editor utilizing JavaScript. It worked, but the response time and maintainability wasn't good enough. The response time affected the user experience, which is critical when creating numerous rules based on hundreds of healthcare-related definitions. Many rules editors have "rich functionality" that must be customized for different browsers, which then must be tested and updated for every new version of the browser. The team decided to convert the WorldDoc editor to Flash, to avoid costly maintenance and support. But it did several JavaScript iterations before making the call to convert the editor to Flash. Our team had never implemented several of the technologies and integration methods we used, and many of them had never been implemented within the healthcare industry -- Antlr, OutSystems, Editor Code Complete, and Syntax Highlight to name a few. We needed proof-of-concept projects to know whether the technologies would work together well, and we had to do so prior to estimating project tasks.

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.