Design for correctness

We started integrating WS-CDL into our design and runtime processes a while back. This work became one of the defining (and differentiating) factors behind our governance efforts (and therefore Overlord). Some people (users and analysts) just "get it" and understand the need behind CDL (let's drop the WS component to the name, because CDL is not limited to SOAP/HTTP by any means). However, others don't and still others ignore it entirely. Best case, this is a shame. Worst case, this is compromising integrity of the systems they develop.

Steve Ross-Talbot recently gave a presentation on CDL recently at the Cognizant Community Europe workshop, and used the analogy of a house architect to explain where CDL fits in. This is a good analogy, because CDL should be in any good Enterprise Architect's repertoire. Just as you don't throw together a straw-built house from a pencil drawing on the back of a napkin and expect it to withstand a hurricane, neither should you just cobble together components or services into a distributed system (irrespective of the scale) and expect it to be correct (and provably correct at that). In the housing example you would pull an architect into the solution and that architect would use best practices that have been developed over centuries of collective experience, to design a building that can withstand 100 mph winds. Software engineering should be no different. Some sectors of our industry have been able to get by with computing as an art rather than a science, and house designers did pretty much the same thing thousands of years ago. But we don't live in caves any more for good reasons (although there's still something to be said for using caves in a hurricane!)

Of course it means that there are more layers in between the act of deciding what needs to be done and actually realising that in an implementation, but those layers are pretty important. The days of just throwing something together and assuming it'll work as planned are well and truly over. Asynchronous systems, which really began life several decades ago but were muzzled by layers of synchronous abstractions, are back to stay. Yes, synchronous is easier to understand and reason about, but it's an unfortunate reality that if you want scale, real-time, loose coupling etc. we have to break through the synchronous barrier. That has a knock-on effect on how you design your systems and individual components (services) and ultimately how they are managed (by a person or by some autonomic mechanism). "Design for testability" was a buzz-phrase from many years ago. What we need now (and what CDL integration gives us) is "design for correctness".