Time to slow down the Oslo hype

This quote about Oslo & SOA is over the top:

Because the software infrastructure that supports your business
model is not based on some gobbledygook that only the guy with the pocket
protector and horn rimmed glasses understands. The software that supports your
business model is based on models and these models are aligned with business
capabilities that bring value to the organization and these models are also
aligned with standards based, interoperable and reusable webservices that
represent your software infrastructure.

Puh-leeze.  Only uber-“pocket
protector and horn rimmed glasses
” guy is going to be capable of utilizing Oslo effectively to create that clean business facing language in the first place.  And again, only the geeky programmer is going to have the slightest clue about how that spiffy new DSL is actually translated into real functionality.  Having a “Model” that’s just a lump of data isn’t all that useful.  Something has to actually make the “Model” be executable, and I nominate the guy with the pocket protector.

Oslo potentially == a new way to integrate external DSL’s into the .Net ecosystem != non-programmers “writing” software.  Let’s set our sights just a little bit lower.  Just being able to write code that closely reflects the business domain is a huge win.  Getting business experts able to write the actual code, even in a DSL, isn’t going to happen.

C’mon here.  I’m very interested in Oslo too, but I can’t see any way in which Oslo is a game changer. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • JuanSuero

    In “Oslo” now Azure.. the model IS executable.
    and it IS understandable and it IS searchable and it IS deployable.

    So if i had 500 cloud apps or whatever 500 on-premise apps. and they all had some slightly different configuration for high evailability etc… and i hired a new systems administrator… and we sat down and had a conversation about our architecture. Me being the business owner or some manager with little I.T. experience. do you think anyof them would have a clue about the shape of the architecture or be able to effectively navigate across and in and out of its boundaries aligning them with business goals? Do you think you would be able to also tell how much this is costing you vs. how much it’s bringing in?
    No i dont think so. But if you look closely at the combination of new stuff coming out you can imagine that conversation happening in some future time over a deployable and executable set of models that map to business goals. Which will let that conversation with the business leader or manager and the I.T. be more powerful and fruitful and lead to immediate if not quick and agile changes or decisions in direction to be made. so Pul Lease stop being so negative and look with a visionary eye at things. This is the perspective Microsoft has to take because they are not create a software package for you to start getting things out of it day 1. They are creating a platform to enable you, them or someone else with vision to figure out the rest and build ontop of it.

  • JuanSuero

    I would chill with the automatic negativity thats always displayed towards things that are new. The goal (i think) is to create an integrated stack where the model IS executable and IS at the top of the stack and is also stored and relates to other models in meaningful ways. In this way organizations can manage and manipulate thier I.T. assets in more integrated and agile ways. You think we are going to get to computer nirvana tomorrow?! This has been building since the web first took hold… successive attempts some successes some failures. If we listen to the naysayers in 2000 you wouldnt be getting paid lots of money to code in C# or ASP.NET now would you. Microsoft takes thier money and invests it in trying to figure out what is the next platform people are going to need. Thats a hard job. I dont know how many times you have set out to create “a framework” at work… but the stats show you probably failed more than you succeeded. … In terms of the article.. at the time Oslo meant the whole shibang not just the modeling.

  • Long time programmer

    To be honest I think this is all crap. Microsoft habit is to rename old stuff and rebrand it. Now they even took someone else’s name. Why “OSLO” ? RDBMS and XML-like technologies. Yawn…

  • http://neilmosafi.blogspot.com Neil Mosafi

    @BuggyFunBunny – I don’t see how RDBMS puts coders out of work, I think most of them have been using them for years. So if all you want is a CRUD app, why not just create a few tables, provide your users with SQL Server Management studio and be done with it?

  • http://chadmyers.lostechies.com Chad Myers


    “there will be no need for convoluted OO code” — Oh yeah, I’ve never heard THAT one before! Personally, I’d love it if someone figured out a way I don’t need to deal with the complexity of software and I could just stamp out solutions, but after 30+ years of trying, no one’s figured it out yet. This, despite repeated claims of having finally discovered El Dorado.

    At least in my experience, there is no such thing as “just a CRUD app.” As time and use progresses, complexity rises such that merely a schema/catalog is not sufficient to describe that complexity.

    It’s funny you bring up solid state drives, because the way I see it, these will make RDBMS’ obsolete as one of the primary reasons for an RDBMS is to facilitate the quick storage and retrieval of data from a very slow medium (i.e. disk platters). If everything is essentially “in memory”, then this problem goes away. Now you merely need the consistency aspects of the RDBMS. It turns out that these are better accomplished with things like DbC rather than having some sort of silly relational model mapping (which was previously necessary due to storage speed/capacity constraints).

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller


    I’m not sure if I’m going to take your comments seriously with that name, but all the same…

    Building CRUD apps isn’t particularly a challenging problem right now, and there are dozens of existing “build database and push a button for a CRUD app” tools. I can’t speak for you, but my apps actually do something besides capture data in the database.

  • BuggyFunBunny

    What may be interesting, if it happens, is if Oslo folk return to first principles, and realize that the DATA *is the model*. Until java came along, the industry was coming to realize that what Dr. Codd had wrought was a purely declarative business rule engine. The database vendors were just getting to the point where they could implement 3NF databases nearly as fast as file systems. With such databases, and enforced DRI, CRUD applications could be generated from the catalog.

    Some are now doing just that. Solid state disk machines will make this trivial. There will be no need for convoluted OO code (or any other kind).

    Some folks are beginning to realize (again), that a RDBMS based system is *just CRUD*. Puts fancy coders out of work, but who cares?

    And, no, it won’t be users (business analysts, or such) who specify the schema (using Oslo or similar).

    It may be that using SQL Server is just a red herring, and not a return to first principles. We’ll have to wait and see.

  • http://neilmosafi.blogspot.com Neil Mosafi

    When someone says the word “model”, I immediately think about objects. Objects allow you to couple your data and behaviour in the same place, which generally simplifies your code.

    Oslo seems to do the opposite of this. I may have misinterpreted but it implies anemic (code-generated) models with behaviour sitting outside in other classes (dsls, workflow, etc) and I don’t know how I feel about that!

  • http://colinjack.lostechies.com Colin Jack

    Are you allowing comments at your blog?

  • http://www.tinyfinger.com/ Pinky

    I’m an Oslo-nian who reflects a bit about this post:


  • http://colinjack.lostechies.com Colin Jack

    @Jeff Olson
    “Wait a second… didn’t I already talk about that?”

    If you rewrote this and dropped the attitude it might be easier to follow but I’ll try to respond anyway.

    Some of your points I agree with but I’d be interested in hearing more about specifics of yourve experience writing business focussed DSLs. I’ve heard the same sorts of arguments against many things, from TDD to DDD and acceptance testing, so I’m going to stay open-minded on business focussed DSLs for the moment (even staying open-minded on Oslo).

    Whether the business see it, yes in some cases I think they could. Doesn’t mean they write it, or test it, or maintain it but yes there are cases where I think them seeing it has value. Also once the DSL is in place I’d have no problem with a domain expert or BA using it, in fact that as with authoring acceptance tests thats a desierable solution.

    On acceptance tests I agree, but remember acceptance tests are *normally* about capturing representative examples not covering every case. They usually don’t say that in a production system “when dealing with network X in situation Y we will use fees based on Z”.

    Regardless I think that *configuring* complex models through a DSL could have value and is something I do plan to explore more. In particular whilst you sometimes go through a GUI in these config heavy situations you can end up using ETL/spreadsheets. In these latter cases a DSL would be a big improvement. Effort/maintenance wise, yeah I get that its worse.

  • someone who doesnt blog :-O

    as much as i love reading this and many other similar blogs, i just wonder why the f** its always got to be bad news or negative, and for the record, i totally agree with what ur saying, but its stilll funny how its always the same b*llox… imagine how wierd it would be if oslo or shmoslo or whatever actually did what it said on the tin!!!..

  • http://www.chrisholmesonline.com Chris

    I say we just go ahead with an open source project and give business users the best possible DSL/programming language we can and let them spend the next decade writing, testing and maintaining their creation.

    Hell, it would probably only take a month and they’d be begging programmers to come kill their Frankenstein.

    (I think brain surgery is pretty neat, but I don’t see much point in trying to make it easier for the nurse to do the operation…)

  • Andrew Tobin

    Man, that really frustrates me – I’ve been to a few presentations where it’s like:
    “Oh this is Blend, it will mean that the developers wont have to design the look and behaviour of the program!”

    Or, “Windows Workflow means that people in the business can define how their systems work, and you wont need a developer”

    And every time the audience is developers, and I wonder why they’re trying to tell us we’ll be out of a job.

    And I always wonder why on earth they think that accountants or managers will want to spend the time using any tool to make developing a program better – generally they have other jobs to do that have nothing to do with developing programs, and that’s what they hire me for.

    I love tools that make my job easier, I’m just a little frustrated as them being marketted as being a tool that would replace me, my years of experience developing, and the false expectation that someone might get that they could just do these things, and maybe just have me maintain the remaining 90% that they don’t get.

  • http://olsonjeffery.blogspot.com Jeff Olson


    You really need to ask yourself what you’re gonna get out of the DSL vs. doing whatever-it-is-you’d-do-with-a-DSL-in-code.

    Consider the following:
    – Will it be more concise than the way you’re doing it right now?
    – Do you want it to be something you can show to the business?

    Regarding question 1: If the answer is yes, then maybe you should consider reworking your approach to the problem in terms of implementation.

    A DSL itself is a kind of framework of patterns to solve a specific issue. Maybe you need a similar approach for your code, itself? This is where tooling comes into play, though.. as the refactoring/maint story for Oslo-based DSLs is not-yet-at-all clear (and it may be quite nice, by v3 or so). C#, on the other hand, has pretty kickass tooling right now.

    Regarding question 2: If the answer is yes, then maybe you need to consider rethinking your approach to testing and verifiability of what you say your code can/does do for the business.

    You’re gonna need some real deal, no BS acceptance criteria from the domain experts, anyway, in order to make a valuable/meaningful DSL. You can leverage that work to instead hammer out a useful set of test criteria in order to make your code pass muster.

    Then you can show your executable specs/acceptance criteria/etc to the domain expert. And if he wants to see the code that makes that stuff work? See question 1 (rethink your implementation to make it more intention-revealing when looking at the specs).

    Also, this brings up the point of what value you get from showing a business DSL to the user when they aren’t the ones who use it. Sure they can suss out what it does.. but how do they know it really works? To satisfy that need, you’d have to: A) show them the framework that the DSL sits on top of.. which means you’d be showing them the underlying code that you wanted to hide, anyways or B) provide them with meaningful executable spec reports based on acceptance criteria they provided.

    Wait a second… didn’t I already talk about that?

    Really.. I’m not trying to hammer on anyone about it, but I feel like a business DSL is seriously a nuclear option when it comes to solving problems. Very powerful, but it comes at a high price (a customer’s willingness to own and be heavily integrated into all aspects of the design, implementation, maint, etc of the DSL). I think, maybe, in situations of where a user possesses very important and very esoteric knowledge and already possesses a reasonable degree of technical competence.. it might be something to consider. But be aware of the price and only use it as a last resort.

    My greatest fear (hopefully unjustified), with Oslo, is that we’ll find ourselves in another XML/SOA-style nightmare scenario where every bit of technology friction within the business looks like a nail to be hammered by the DSL hammer.

    Q: And who will be put under this spell by Microsoft’s marketing department?

    A: Your IT Manager.

    Q: And who will feel the pain?

    A: You and the business.

    Q: And why did we go down this road in the first place?

    A: Because DSLs sound cool (YAGNI warning sign numero uno).

  • http://colinjack.blogspot.com Colin Jack

    From what I’ve seen everything about Oslo is overblown, so few facts available. Could be great though so I do plan to set it up but yeah I agree internal DSLs might be as useful in practice.

    “Agreed, but the effort to reward ratio of an external DSL has to be favorable”

    I think there could be a lot of value in business focussed DSLs too though, not necessarily to be used (and definitely not authored) by the business but they should allow us to capture complex logic in a business focussed way.

    I’m thinking of a recent example we had, a complex fee system with a seriously elegant and flexible domain model. However as good as the model was you still configured it at the database level, where as I’d say configuring the fees using a DSL would have been a superb solution that would have resulted in code that the domain expert could have read and understood.

    Creating the DSL would have been costly but in my view might have been worth it in this situation.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller


    Thanks for the comment.

    “Technical DSLs, things that result in a net reduction in keystrokes for you as a developer are where the value in DSLs lies.”

    Agreed, but the effort to reward ratio of an external DSL has to be favorable. I know it’s early, and I haven’t even seen the visual tooling for Oslo yet, but so far it looks to me like internal DSL’s in IronRuby or even (gasp) C# 3+ may provide more bang for the buck than external DSL’s with Oslo.

  • http://orand.blogspot.com Oran

    I think the seriously overloaded word “model” is obscuring the huge potential of Oslo. It’s a non-trivial mental shift to stop thinking of models as just fuzzy boxes and lines or just data and see that in Olso, the model _is_ the application. The best example of this right now is Quadrant, the designer tool. I had no idea an app could feel so imperative yet be so deeply declarative under the hood. I too have a hard time visualizing the possibilities, but I think it’s safe to say “don’t underestimate Oslo.” The Oslo team’s sights are set as high as the hype, if not higher, and I think they might just be able to pull it off.

  • http://olsonjeffery.blogspot.com Jeff Olson

    When someone actually puts forward the premise that creating tools for the business to use to implement business logic is a good idea, asking your the following questions:

    – Who will design it?
    – Who will implement it?
    – Who will *maintain* it?
    – Who will get the blame when rules validly defined rules in a business DSL cause havoc because of erroneous implementation?
    – Who will get the blame when invalid rules are implemented in the business DSL, causing havoc?

    By default, the answers to all of those questions are: “You, gentle developer.”

    These are the kinds of questions that need to be answered (bringing up issues of collective design, ownership, oversight, test burden, code review at the framework and script level, etc, etc ad nauseum) and no amount of cool tooling will answer them for you. These are the real problems. Maybe Microsoft can give us some help with these problems, as well.

    Designing fun tools to “throw over the wall” to the business so they can start doing “whatever” is a bad idea unless you’re prepared to deal with the above questions. And, in my modest experience, providing the “right” answers to those questions makes the whole premise of a business DSL seem less and less appealing. And we’re not even talking about reasonable expectations for business buy-in and commitment, here.

    Bottom line: When you think of some idea sounds cool and fun to implement (like, say “Let’s give Portfolio Managers a tool so they can design strategies to algorithmically rebalance complex portfolios of multiple assets types), you need to hope and pray that the YAGNI alarm is going off in the back of your head.

    Technical DSLs, things that result in a net reduction in keystrokes for you as a developer are where the value in DSLs lies.

    Everything else is gonna be pain, 9 times out of 10. The business needs to be good at the business. If they wanted to be code monkeys, they would be.

    DSLs are cool because it’s a fun, challenging field. But be very weary of what does and does not add value, with regard to them.

  • http://weblogs.asp.net/kdente Kevin Dente

    My impression is that there are still big parts of the Oslo vision that haven’t been revealed yet. The modeling language is a core component, but what gets built on top of the modeling language is also key. For example, I think WF is a part of the “executable” piece of the story, but how that interacts with the modeling language isn’t at all clear to me.

    I’m not saying they will or won’t be able to pull it off…I just don’t think I’ve seen enough of the whole pie to know. Apparently that isn’t slowing down the hype machine though. 😉

  • http://devlicio.us/blogs/sergio_pereira/default.aspx sergiopereira

    History shows this is indeed hard to happen. But I think there’s hope. There are success stories that contribute to the quest for such thing: http://www.infoq.com/presentations/fields-business-natural-languages-ruby (reading material here http://blog.jayfields.com/2006/07/bnl-01-introduction.html )

  • Steve

    Well said Jeremy. I’ve lost track of how many times (over the past 23 years) I’ve heard prophecies about business people writing their own software and prophecies about the death of the programmer. And, every time, the prophecies have been so far off the mark. Getting one step closer to the dream is great. Facilitating more alignment to the business domain is terrific. But let’s keep Olso in perspective.

  • http://michaelstechnical.blogspot.com Michael Hedgpeth

    I agree too. Where’s the behavior? The most interesting aspect of software is NOT ITS DATA!!!! It’s the behavior. I’d like them to go in more of a DDD direction on this.

  • http://www.cornetdesign.com Cory Foy

    Agreed. I pulled it down before I left Austin and played with it on the plane after reading Fowler’s article on it. I was rather disappointed to find out that it is so tightly obsessed with tracking things to the database. I was hoping it would be a good language workbench which had additional capabilities if you wanted them.

  • LukeB

    I LOL’d. PHBs eat that stuff up!