Evolution via model-driven development

By: Rich P., Sr Systems Analyst

To be a truly great technology leader you have to be a visionary. You must continue to tackle day to day tasks while also developing strategies and roadmaps that will launch you into the future. Risks can bring both consequences and rewards.

Can software development be guided towards an architectural vision? I have wanted to discuss this question for some time, but I had to find the right opportunity to meet with Doug M., Chief Architect at Cengage.

Doug’s career spans several industries, including healthcare, manufacturing, and education. He is a leader in the technology space with a focus on model-driven architecture, microservices, and cloud adoption. Doug guides digital and enterprise solutions with the aim of addressing present-day challenges within the context of future opportunities.

Think Darwin

“Why the large conference room?” Doug asked.
“The whiteboard,” I replied.

I wasn’t sure how the meeting would begin and thought that even an hour of his time might not be enough to absorb whatever he wanted to say, but knew we would have to start somewhere.

“Evolution,” Doug began. “Evolving systems are those in which new traits can be added as extensions, and if the traits are successful, the extensions can later become part of the core code and models. Jason Swafford, [Vice President of Software Development here at Cengage], and I came up with the evolution analogy a few weeks ago as a way to discuss our soon to be released Cengage Technology Strategy.”

Evolution made me think of DITA (Darwin Information Typing Architecture), particularly the Darwin part. Within the framework, DITA allows for inheritance and specialization so that developers can extend core topic types and its elements.

Core DNA + Extensions

Doug headed to the whiteboard and before our session ended, an entire wall was filled with diagrams and annotations.

In initial diagrams, he represented a kind of core DNA along with extensions that engineering teams could use for faster development,  without having to modify the core code. Over time, the core code would evolve to include the more prevalent extensions.

Survival of the fittest, I thought. Preservation of new code that provides some advantage, an adaptation to changing conditions.

Model-driven development

The focus of the discussion pertained to model-driven development — specifically Meta Model, a framework we define in XML that describes a data structure consisting of a package with objects, each holding fields and attributes. Interestingly, attributes are not part of the model; instead, they provide additional information in almost the same way that annotations are used in Java. Attributes drive particular behaviors (or business logic) around the data as applications operate against the model.

You can think of attributes as behavioral elements.

For example, Meta Model can use attributes to customize transformations from XML to an object to JSON without any loss of data, and back in the other direction. Customizing the default behavior of generating code (XSD) and documentation (published to a website) represent other examples in which attributes might be used.

In subsequent diagrams, Doug outlined Service Oriented Architecture (SOA). Within our SOA implementation, Meta Model uses transformations for an aggregation service that serves up JSON to consuming platforms.

Evolutionary Aspects of Modeling

Aspects of the Meta Model framework that would allow systems to evolve include inheritance (from common base objects and fields), extensions (platform or product specific data), and overlays (additions or exclusions of data). Neither extensions nor overlays would be defined in the source or base model objects. Their data would simply be pulled through the core systems (injected and passed through to allow for different behaviors, for example, to display a unique field for a particular business need).

Developers would use these aspects to rapidly develop capabilities (i.e., back-end, validation, front-end) without having to touch the core code; then over time, move a subset of those capabilities into the core code in a controlled and managed way, a kind of evolution that could respond to changing business needs.

Pizza Toppings

Here is another way to look at this.

Think of pizza toppings as extensions and red pepper flakes and other condiments as overlays. Then consider how they are added or not to the core ingredients (crust, tomato sauce, etc.) of the modern pizza. I say modern because even pizza evolved to include tomatoes as a basic ingredient in 16th century Naples, Italy. Before then, ancient and less ancient recipes of flat/round baked bread with toppings did not include tomatoes.

All food for thought.