Nayya and Workday announce strategic partnership
Learn more
In our previous post, we ended with a problem that required different domains in our organization to be able to operate independently while also being able to rely on the conclusions being reached without direct visibility. Earlier in the article, we spent considerable time emphasizing a development sequence wherein architecture-inspired decisions propagate down to shape features at the application level. In this follow-on, we’ll explore how the requirements of our problem space intersect with our desired methodology.
Fundamentally, we’re developing our eligibility determination framework that must be both decentralized and consistent. As it turns out, these requirements map remarkably well to a formal design pattern known as policy.
In the policy pattern, procedures are encapsulated into algorithms which are decoupled from the applicator. The applicator defers the selection of a specific algorithm to individual clients who will tell the applicator which one to use at runtime. This formula allows for the deterministic evaluation of rules without beholding all clients to any one rule in particular. That is precisely what we want to achieve internally with our eligibility feature – provide a standardized way for each domain to apply eligibility rules that is also flexible enough to work across contexts.
It’s worth recognizing how our concrete implementation of this eligibility feature emerged from our architectural structure, not the other way around, and was ultimately constructed in such a way that a recognizable design pattern became glaringly obvious.
As far as specific mechanisms go, we wanted to use a tool that was feature-rich and well-documented; the eligibility rules we need to encapsulate in the benefits domain can be complex and dynamic so the mechanisms that prioritize simplicity didn’t support our use case very well. We recognized that using an advanced logic engine from the start meant there would be a learning curve for developers; even simple use cases would involve some cognitive overhead so thorough documentation and widespread usage were also critical resources for our team. Ultimately we chose the JSON Rules Engine as our eligibility evaluator.
Relying on the principle that each specific domain within our system will be the most informed entity to make decisions about its own purview, the JSON Rules Engine will enable each application to write and maintain its own specific library of rules and, in conjunction with a set of relevant facts, will allow for the independent determination of eligibility. Applications can share rules, facts, or both, and make robust assumptions that the same resolutions are being made across the entire distributed system. This separation of concerns also creates a great deal of flexibility – one client can ask another to determine an eligibility on their behalf, or they could ask for the data and facts to do it themselves. Morphologically, an eligibility rule can vary greatly from one context to the next even within the same domain; the concept of a distributed rules engine allows our system to evolve alongside the demands and use cases for rules-based decision making in the benefits technology space.
I don’t know whether the chicken or the egg came first. I’m equally uncertain as to whether all dogmas in the realm of software design hold equal truths. One such doctrine seems to be that software architecture and system design work best as antecedents to application development and not the other way around. As a matter of methodology, I don’t know whether that statement is true or whether our specific problem-space at Nayya only makes it seem that way. What I do know is that developing an integrated system sequentially from model to design to individual applications has led to thoughtful and intentional decisions around implementation; it’s possible that having a loose architectural backbone in place prior to application development gives you better direction. Or perhaps having a preconceived design arms you with something to defend and protect against regressions. Maybe the real treasure is the friends you make along the way. Nayya has some ambitious goals for our new decentralized system and so far, they are all coming to fruition.
