04/08/09 :: [MOP] Where is Oslo Going? (II) [permalink]
Doug Purdy responded to my post yesterday. So let's discuss the most important points.
Productivity
Doug, I urge you to contact a sample of your customers and look at the annual pipeline of projects that the business is asking IT to do. Compare the requests from the business, from what was approved and budgeted as well as with the actuals at the end of a particular year (say 2008). Then derive the average productivity gain that is need to allow most IT organization to deliver 100% of what the business needs in a given year. Don't forget that some projects don't even make it to the list so allow for another 20% of orphan projects. I think you would be very surprised how much 10X would buy you.
Now, in terms of productivity in the Cloud, as you may have noticed, the Cloud provides "turnkey" operations, so right there you have quite a productivity gain. I have several personal data points that show that Cloud based development environments already deliver about or slightly more than 10X improvements. However, their programming models is still too basic to tackle all IT challenges, but they will get there, make no mistake. If productivity cannot be improved in traditional IT on-premise architectures, make no mistake, these on-premise architectures will disappear entirely within 10 years, so frankly the clock is ticking. (no pressure).
DSL
The current DSL tools (the DSL Toolkit) are for visual DSLs, not for textual DSLs. We want an architecture that supports both both textual and visual DSLs operating over the same model.
Doug the part I like most about Oslo is that finally someone understands that anemic DSLs are pretty much useless. The fact that you understand that M is about programming models and not just DSL was very encouraging. The distinction between vDSL and tDSL is purely stylistic and frankly totally uninteresting. The fact that there is a continuum between programming models and DSLs, is IMHO far more important. Hence my disenchantment with your approach to constructing Oslo based on REST samples. If you think you need all this machinery to CRUD or to convert a 3-line code snippet into an HTTP request, that's quite overkill. BTW, I am sorry, but I don't see any hi-REST in the samples that you are providing. Hi-REST involves HATEOAS at a minimum and there is no evidence of HATEOAS in anything that I have seen.
If you really want to make an impact and be relevant you have to tackle real IT problems and URI templates are not real IT problems. You have to deal first and foremost with the heterogeneity of IT. I was quite encouraged to see at MIX that a new Microsoft is emerging: some product divisions, such as Azure or the one lead by Scott Guthrie, are not assuming Microsoft technologies all the way. Which product more than Oslo could afford not to deal with this heterogeneity. IT is in great need to decouple programming models (note the plural) from architectures (plural again). As the first non-anemic DSL framework, this is the mission of Oslo, whether you want it or not. CRUDing or lo-REST is a distraction, by far. There is so much else to do, I mean real-world and pragmatic, things to do.
Stitching
You are misunderstanding this sentence and it you are forgetting about an important aspect of this technology: managing the application. Applications are in silos today (how do you think about the apps on a box when you are managing them?), the applications themselves are composed of different silos (the presentation silo, the middle-tier silo, the data silo, etc.). Our hope is to make it easier to design, develop and manage the applications across all of these silos. In the limit, we will have a unified model for all aspects of the application. Pragmatically, there are going to be N models (legacy silos, silos that are “opaque”, etc.) and we want to have some level of support for all of these.
Well, I'll wait and see what you come up with in this area. First the problem is not just about layered architectures, it is also about connected systems and composite apps. Even if you consider SOA and Composite Apps as particular areas of applications, you cannot abstract composite programming concepts away from the core design of Oslo, otherwise it will not be capable of enabling people to define their particular composite programming model. In other words there are a set of M3 concepts that you need to take into account to let people design M2 programming models and with which they will implement M1 solutions. Ignoring, once more, a "connected system" programming concept would make Oslo just as successful as WCF.
Second I am still a bit turned off by your statement of "there are going to be N models". I am not convinced you need these models. Each architecture layer has a programming model today. If you provide a good transformation framework to go from the programming model to these concrete models maybe this approach could yield some benefits. I would like to suggest that it would be better to focus on a "DSL connector framework" that would allow you to deploy a programming model defined and managed by Oslo into a variety of architecture layers. I spoke with Nikhil yesterday who mentioned the "metadata pipeline" in .Net RIA services, I think that this is a very important concept and ultimately you could see some integration points between the pipeline and Oslo.
MOP
I like many aspects of your MOP formulation. I do not like the explicit transformation, but otherwise it seems reasonably sound at a high-level after skimming it.
Thanks, actually if you read my post, I explain that MOP may alleviate the need for creating the grand MDD machinery which is composed of problem and solution metamodels, models and transformations between them. I am not ruling it out, but MOP, via increased productivity, may simply not require too much improvement in the way we capture the problem since you could theoretically iterate fast enough to deliver the desired solution. The purpose of the figure was to show what people are trying to do in general and where MOP fits in relation to the general MDD approach.
So I am still for the most part unconvinced by your response, until I see I how Oslo can help me create programming models that will allow me to evolve my architecture while not having to rewrite my core business logic, I don't see any benefit for IT. I mean, for SOA sake, some people are still running some business logic that was written in the 70s. At some point you have to realize that the evolution cycles that all vendors (not just Microsoft) are pushing on IT are simply unsustainable. Which vendor can guarantee today that some code written in XXX will run in 2050? Shouldn't Oslo be the element that enables that? Don't you think that people would pay far more money for that than for optimizing the way they CRUD or simplify the inextricable problem of writing URI templates?