IT Modernization < V. Hanniet

software model driven approaches

Agile & Modeling new way of life!

Nice title, isn’t it? I’d like to share the idea that we can associate agile project management and software development  practices (two different things!) to build sustainable software. In doing this, the sustainable artifacts would be source code AND analysis and design models (and maybe code generation rules if used for this purpose).

The idea came out along a discussion with Meinte Boersma on his blog. Here is an abstract:

I don’t like any title with a capital letter in front, would it be Architect or Programmer or Analyst. But when developing software there is actually a need to analyze, design and program (in this order even if it should always be an iterative process). And at the end, we should’nt write a single line of code without being sure that it increases business value and/or optimize maintenance costs. And so each line of code (or component) should be challenged through business needs and/or architecture/programming rules. Note that the business value goal involves that the code must work, be reliable, meet expected response time etc.

Extreme Programming (1996) was the first Agile trend success. I tried it then on some projects, with the help of Laurent Bossavit now became a French Agile guru, but couldn’t succeed to sell the idea to customers at this time. XP was focused on user stories and direct implementation, with as many refactoring as developers thought to be good (and team meeting and unit tests and continuous integration and so on…).
Nowadays people begin to understand that an agile way to conduct a project, say with Scrum, is one thing. And that it may be applied to any kind of project, not only in IT field. Building a sustainable software is another kind of thing. Merging the two things is a good way to succeed in application development.
BUT, taking into account just business needs (without analysis) and programming level needs (without architecture) is just a no way road. IHMO. At least or projects which will have to survive to their developers availability.
Modeling is a mean to do analysis and architecture design.

I am for the, not yet existing, Agile & Modeling new way of life! ;)

Featured image taken from
I like very much the idea of a “whirlpool”: a very fine description of what actually happens on every IT project!

14 comments on “Agile & Modeling new way of life!

  1. meinte37

    It’s “Boersma”, not “Borsa”! 🙂

    • vhanniet

      Fixed! As in a pure agile team way: directly from requirement to dev 😉

  2. softmodeling

    You may want to take a look at my presentation “Agile and Modeling/MDE: friends or foes”

    • vhanniet

      Nice prez Jordi! But…
      I think we can’t demonstrate what sounds trivial for us to people who don’t perceive what they are actually doing. As you say in your prez, a lot of people using UML on their project think that UML is a process. And I say that a lot of people using agile processes think that an agile process is a method to build software. They are both wrong from a scientific analysis, but until some extend they aren’t in the real IT world because there are practices associated to UML and agile processes which make the thing running for developping software.
      We can for sure develop good software without using modeling langages nor agile project practices. Is it worse? Is it better? In which case? The answer is not that simple 😉

  3. Johan den Haan

    Agile and modeling can be a good marriage. However, I prefer to focus on the full application lifecycle, not just analysis and development. In the end, the most important thing is a working app for the business, that’s where the value is. To improve the delivery of apps we need to abstract away from technical details in each lifecycle phase, as we do with MDD in the development phase. See for a more detailed description of this idea.

    • vhanniet

      I read your post on the idea of “Agile ALM”. You’re right on fact that to be able to get at the end a software that fit business needs we first must be able to build a sustainable software in an agile manner.
      I like the AppFactory idea (more than just an idea here), kind of AppStore for building SW. I like the emphasis on the Deploy phase, and the idea of modeling the deploy phase to cut down complexity and save costs (even if cloud brings nothing new here by itself). I like that, in this post at least, you tell that MDD with sufficiently high level models brings a lot of value to agile ALM – which is what I believe.

      But… Even if we could fully automate components integration, functional and non functional testing, deployment and run supervision – which is simpler to tell than to do except on trivial cases where the degrees of freedom are limited by a kind of closed AppFactory – the simple idea to enable (with highly efficient tooling) everybody to work together toward a shared goal does not ensure that the goal will be reached. Nor it can ensure that, should we know a succesful result, we could reach it twice.

      So. Ok, using agile and modeling during the whole life-cycle sounds good. But, if we have to choose, I guess that having a good analysis and a good software design has a better end value for business. How to get them? I don’t know 😉 But modeling is here a key weapon.

  4. modelpractice

    yes, perhaps the new way of life requires a new way to think of modelling, away from big concepts like UML, Model Driven, …?

    Perhaps we talk too much about languages, processes and tools? Modelling to me is a style of (computational) thinking, in the first place, that comes ‘naturally’, in a way.


  5. vhanniet

    That’s it! Modelling is (also) a style of thinking. That’s mine too (I guess ;)). And we should probably develop the practise of modelling (SW) without thinking of plumbing (even if, as Johan points out, modeling the plumbing has also some utility).

  6. meinte37

    I’m really really opposed to the notion that software development can be divided into separate disciplines: analysis, design and implementation. I haven’t met a developer who was worth his/her cup of tea who couldn’t do all three equally well. Also, if implementation didn’t have anything to do with analysis and design, it would be more of a sort of typist’s work than anything else – which begs the question: why wasn’t the post-analysis design not already rendered as a comprehensive model (and use a code generator instead of a “can of Indians” as a former manager of mine once said)?

    Having said that, I’m all for agile modeling 🙂

    • vhanniet

      Well 😉
      I didn’t think that the “three disciplines” are unconnected, nor that we need 3 people each time we work on SW development. But I’m pretty sure that there are specific concerns for each of the three and that, at some extent, some expertise in the concerned discipline is required: business/functional requirements, non functional requirements, clean and clear implementation.
      If analysis and design are modeled, why should we still need people for implementation? Some think we could avoid coping with developers, eg. Executable UML or more generally Businness oriented app generators (lot of examples). I don’t: 1) the cost of having fully implementable models is too high, IMHO 2) agility requires to use craftmanship power (at some time we need to actually DO quiclky something unexpected but smart ;)). By the way, I consider analyst, architect and developer as roles, not as “one slot” people.
      The “proof” for modeling power in these fields could come from reverse-modeling and automated modernization: I will develop this idea soon (original intent for my blog but there are some much funny topics in MDE field !).
      And, if smart people can for sure embrace all SW development disciplines, don’t forget that “Only 4% of IT projects benefit from a double dream team effect!” (

      • meinte37

        I never said that developers should done away with: it’s rather the reverse in that developers should not do mere implementation, but should rather facilitate the overall process by becoming “meta-developers” and building the languages, tools and code generators/model interpreters which allow non-devs to become much more productive than they can be now. In fact, devs who are not able or willing to change their role accordingly are definitely not part of that illusive dev dream team of yours. Plus: adopting this strategy increases the chance of finding the business half of the dream team because a greater part of the bell curve’s “good” edge will become adequate.

        @1: That cost is coming down considerably and has been coming down the last few years. E.g., with Xtext, it usually takes me only a couple of days to come up with a modeling language and code generator which is already quite sufficient to drive a project with. With something like Mendix you don’t even have these costs (as long as the modeling language fits your needs).

        Btw: I don’t believe in Executable UML as I don’t believe in UML (too big, too ambiguous, too little built-in semantics).

  7. vhanniet

    An interesting insight on the future of developer as a job: Could coding be the next mass profession?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


This entry was posted on 04/01/2012 by in Modeling and tagged , .

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 187 other followers

Creative Commons License
IT Modernization < V. Hanniet by Vincent Hanniet is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.