Lehman’s law of software entropy

It was in 1974 when Professor “Manny” Lehman started to publish his “Metrics and Laws of Software Evolution”. What every software engineer calls “Lehman’s Law” since then can be simplified by stating that

 

increasing growth in complexity makes a software less satisfactory.

 

What was true in 1974 is still true today. For developers as well as for users. And it is true not only for enormous enterprise software architectures, but for smaller business applications as well.

 

At Sclable we found that smaller businesses tend to opt for a single solution containing all of their business processes yielding often an enormous complexity. Whereas big corporations use their resources to maintain a large amount of isolated applications and systems each with a limited set of features, therefore maintainable and in the worst case replaceable.

Dead locked by the separation of concerns

As a result to Lehman’s research, the theory of Normalized Systems has been established. Its first theorem is called the “Separation of Concerns” which, for business applications, lead to the golden rule that a software engineer should always

 

separate business logic from business data.

 

As a result, people responsible for the business logic and database architects are often hindering each other. That’s why the saying “Never touch a running system” has become so popular. At Sclable we aim to disapprove the theorem far enough to neutralize all the excuses IT people have for this saying.

A new concept: the domain model

Martin Fowler, one of the most influential thinkers in all things software development published his famous book “Patterns of Enterprise Architecture” in 2002, introducing the concept of the Domain Model as

 

an object model of the [business] domain that incorporates both behavior and data

 

What? How can we have both, the Separation of Concerns and a Domain Model? As discussions [1][2][3] show the topic is still controversial. The Sclable approach is to break with the rule of the separation of concerns. At least as far as the storage logic is concerned.

From the domain model to domain driven design

Eric Evans started a new era in 2003 with his remarkable book “Domain Driven Design” introducing a language for software design patterns around the domain model. Like every software engineer, Evans has a simple claim:

 

Tackling Complexity in the Heart of Software

 

as the subtitle of his book states. Since then the DDD-Community has grown yet waiting for a clear and profound direction how to implement DDD patterns properly.

Talking DDD, doing DDD

About at the same time Sclable had the first successes with domain model based application generation in 2011, Dan Haywood published Domain-Driven Design Using Naked Objects. His challenge was:

 

how do you bring the domain model to life so that it can be checked, verified, and refined?

 

After all those concepts and discussions, his practical point of view was relieving. For the first time doing DDD seemed to be a reasonable thing to do on every software project. On the other hand it blurred the difference between Object-Orientation and Domain Driven Design [4], something that the industry has still a hard time to recognize.

“All the calculations show it can’t work. There’s only one thing to do: make it work.”

In early 2013 Vaughn Vernon published “Implementing Domain Driven Design” starting off the book’s preface with this quote from Pierre-Georges Latécoère, an early French aviation entrepreneur. Being very practice-oriented, he teaches us not to focus all too much on architecture, since architectural influences come and go. From him we learn to

 

place more emphasis on the domain model, which has greater business value and will be more enduring.

 

Vernon very profoundly explains the groundwork to be done when you want business application development that just flies. It is exactly the business value of the domain model we are focusing on. That’s why Sclable is a product, not a philosophy.

Radical approach

By merging business logic with data storage logic, we broke some golden rules for enterprise software development. And it didn’t hurt. To the contrary: doing so set us free to implement a contemporary version of Fowler’s Domain Model. We simply call it “Sclable Business Domain”. In fact our core engine does that groundwork Vernon speaks of for you and lets you focus on the descriptive part of the domain model.

Supercharged Domain Model Development

Today we are not only able to automate a great amount of design patterns introduced by the pioneers of the domain model but can as well provide a Framework around that automatisation engine.

What comes next?

Now that Sclable Business Domains merge data and logic our most burning questions are: Can we enhance domain models to contain all transformations that the business domain has been undergoing since its existence? And if so, will a Sclable Business Domain be able to transform back to a previous state? Or a projected future one?

Commencing countdown, engines on

We decided to start a research and development project that is just about that. Imagine seamless, automated data migration upon complex domain model changes! Imagine test-driving an altered business process within the production environment! And probably revert to a previous state after data has been managed through the altered process for a while…

First concepts have been proofed and are very promising. And learnings have been made. A lot. Stay tuned and you’ll see.