In Douglas Adams book The Hitchhiker's Guide to the Galaxy, he tells how a supercomputer named Deep Thought worked to calculate the answer to Life, the Universe, and Everything. After 7½ million years, the supercomputer came up with the answer: 42. Unfortunately, no one could understand the answer because they didn't know the question.
Some might argue that "Oslo" is Microsoft's answer to "life, the universe, and everything" IT-related, but now that it has been revealed, many developers are confused and left wondering what is the question that it solves.
One of the posts on the "Oslo" forums queries "Why do we need Oslo?"
Doug Purdy gave his answer on his blog this week: Oslo v1 is about developer productivity. If you watch his PDC talk, A Lap around "Oslo", he explains that Oslo is about capturing the essence of the code without the ceremony.
The bold purpose of "Oslo" is to enable capturing the intent of the business in terms that are equally clear to humans and to computers.
How does the "Oslo" modeling platform attempt to meet this objective?
In a nutshell, "Oslo" attempts to provide developers and analysts with the tools to abstract their intent as data and stores this data so that it can be executed later.
A simple Example
While at my previous employer I was responsible for an application framework for a line of business application. One of the features that we supported was the ability to create forms to display entity fields to the user.
To do this, we separated the implementation of rendering the forms and controls from the business entities. We had an XML file to store which fields should be displayed for each form. It looked vaguely like this:
<field name="Defect Number"/>
<field name="Found By" />
<field name="Title" />
<field name="Description" />
<field name="Repro Scenario" />
We then had a forms engine that could use this XML file to render a web form to the user using the appropriate web controls based upon the data type of each field, similar to the Dynamic Data Controls in ASP.NET 3.5 SP1.
This XML file was effectively a custom Domain Specific Language, and each XML document was our form model. Each of these form models were stored either on the file system or in the database as our repository. The application framework served as the execution engine for our form models. We even had a form designer for laying out the various components of the form visually.
So what did this give us?
- Developers could rapidly implement a new form-based UI more quickly than wiring up the ASP.NET controls manually.
- Customers and Business Analysts could design their own custom forms and add them to the system.
- We were looking at the possibility of transitioning to use Silverlight or a 3rd party web control library for a richer user experience. If we did, we would only need to update the application framework and the form models could remain untouched.
This approach allowed us to have a better separation of concerns. The form rendering logic was baked into our application framework, while the business logic about which fields should be displayed were separated and could evolve separately.
If you have already been separating your "what" from your "how", as we did in our forms engine, what benefit do you get from "Oslo"?
- Better tools to do what you're already doing
- Less isolation and fewer silos of information
- Better transparency into your models
Our XML model was fairly simple, yet with a large form, it still became cumbersome because of all of the XML noise. Using "M" we could have written a terser DSL that captures the essence of our intent, without all the ceremony of the XML angle brackets.
For example, here's a model more friendly to developers:
Or, if you want a more human readable grammar for your customers and business analysts:
Defect has a form with the following fields: Defect Number, Found By, Title, Description, and Repro Scenario.
If this were stored in the "Oslo" Repository, we might have been able to have designer that was richer and easier to implement with Quadrant, and we would be able to integrate with our entity designer, too, to see which fields were available for each entity type.
Finally, if the model were stored in the Repository, other tools might be able to better discover information about these forms.
For example, if we rename "Repro Scenario" to just "Scenario", or remove "Found By" from our entity model, we could immediately detect which forms use these fields and update our form model appropriately.
But, if you're already doing declarative, model-driven design like this, you probably can already imagine many more useful scenarios that "Oslo" enables.
What if you have never looked at your code this way before?
Well, this might seem like a lot of unnecessary overhead. Is it really that hard to write good ASPX code, and how often do you really need to swap out your rendering engine?
Shawn Wildermouth gave his answer to the broader question, "Why do we need DSL's?", and I think his post explains why there is value in taking this approach.
Today, customers talk to business analysts, who might capture what they think that they heard in some UML model somewhere, maybe in Visio. They might do mockups of screen shots with Photoshop of how the user experience should work. They then pass this onto the architect or developer to implement, who implement what they understand the customer's intent to be.
This is like an elaborate game of telephone, though, and there is bound to be misunderstanding somewhere along the way.
If you have a good team, your developer will get this right most of the time. If you are using Agile, you will probably get it right more often because your developers will be talking to your customers directly, and you'll get feedback quicker when it is wrong, but you will still have waste.
Model driven development offers the opportunity to allow the customer to express their intent directly and see the impact of their decisions immediately without being translated through many different layers.
If "Oslo" can succeed in their goals, there can be much more rapid development with much less waste, which should matter to anyone who cares about business value.
Should I start building my code with "Oslo" today?
That depends on you and your needs.
The "Oslo" Team has a large vision, which cannot be fully accomplished in v1. They will have plenty of work to do in future releases. Even this is still early and "nascent" according to Don Box and Ray Ozzie. "Oslo" is still raw and will probably change before v1. If you need your tools to be fully baked, then it is too early for you to build on "Oslo".
If you are just now trying to understand how model driven development and DSL's can help you with your development, maybe it would be useful for you to download the tools and play with it so that you can begin to grasp how this is different or similar to how you do things today. Try thinking about the problems that your current project has that might benefit from this mind set.
If you have already been using this approach, try out using the tools from Microsoft to see if they will help you do what you already do more easily. Discover the gaps, if any, that would prevent you from using "Oslo".
When you are done give your feedback to Microsoft on the "Oslo" forum so that they can make the necessary changes so that v1 supports as many scenarios as possible and it lays a solid foundation for future releases.