So, are Cloudfier applications models or programs?
Long story short: both. But read on for the scoop.
Programs vs. Models
We write programs to tell computers to do things, and we create models to communicate ideas to others. Cloudfier applications are executable models. Executable models are amazing because they allow us do to both things at the same time: they are complete and precise enough to be considered programs, yet they allow expressing intent and communicating ideas well. You can say that executable models are programs optimized for communicating intent. And this turns into a nice set of side-effect benefits.
One very interesting side effect of that is that when you limit yourself to communicating intent, you naturally end up leaning towards technology independence. So as a consequence of being designed for communicating intent, executable models are also programs that are technology independent, and hence they are future proof. When what is considered the best technology for building software keeps changing every six months or so, that is a big win.
Concerns become separated by nature
Executable models allow separating the solutions to business requirements (dealt with by the executable model) from the solutions to non-functional requirements (which are dealt with via code generation or model interpretation). This separation of concerns by nature has two nice consequences:
The problem domain gets the importance it deserves. Ever tried to understand the business requirements of an application by inspecting its code base? It is really hard – and the reason is that solutions for business requirements have to be encoded with the mechanisms provided by the implementation technologies. Not only they often favor the need to communicate with the computer (frameworks, APIs etc) over communicating to others, but tend to mix solutions to a plethora of non-functional requirements with the basic solution for the requirements from the problem domain, which ends up obfuscating the latter. And in case you are wondering, it is the solutions to the business requirements that really represent the value of a system.
The architecture can be evolved in a cost-effective way. At the same rate, ever tried to upgrade the architecture of an application of any decent size? Sometimes, even moving to the latest version of a framework is so hard (or at labor intensive) that it is usually not done, and the application goes slowly but surely down the slope of obsolescence. With executable models, since the technological choices are not encoded in the application “source code” but elsewhere (the code generator or the model interpreter), you can evolve the architecture of the application without having to revisit how you addressed the problem domain requirements. You can do small adjustments to the architecture as you go very easily, but you can even completely change the target programming language (or support an additional one).
Opportunities with Executable models
Developing using executable models in general (and hence in Cloudfier) opens up some very interesting opportunities:
- You can express the conceptual solution for the business requirements using constructs that provide the proper level of abstraction, such as relationships, constraints, state machines.
- You can let business stakeholders play with and validate the model not via diagrams, but by interacting with a fully functional application (running on a temporary tech stack).
- You can test your application at the model level.
- You can easily change the way you generate for a given target platform.
- You can generate the application into two or more target platforms.
- You can build your own generator, or buy/get it from a third party.
- You can sell or somehow let others use the generator you built.
I will cover these scenarios and how they are supported in Cloudfier in future posts. But if you have any questions about them now, just use the comment area below.