Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

Data Models are for Wimps!

In the building industry, before a building is ever erected you will have an architect’s plan defining in full each of its facets. You would then have wiring diagrams and plumbing diagrams. Last of all a decoration and furnishing plan. All of this before a brick is laid.

No builder would consider building a house without all of this information being provided – well no good builder.

Why then, in the computing world do the the “builders” get turned off by “architect’s” plans and think them quite unnecessary and restricting? In this world the “builders” want to be architects, engineers, designers and builders. No one can do it better! They don’t need all of these silly plans and designs they want to “just get on an build it”.

Data Models are for wimps!

Is this perhaps the reason why most computing projects fail to deliver the required results?

People moan and groan about a structured approach and call it “bureaucratic”. They want “rapid” methods. We used call them “back of an envelope” but they now have exotic names like “Agile”.

They also want “iterative” methods. This is a euphemism for building the wrong thing first time and then spending these rest of the time putting it right.

There some excellent developers out there. I have been privileged to work with some. They can actually get it right first time. But they are far too few in number.

I hate bureaucracy but I also hate the appalling slap dash methods taken by far too many in this industry. It is possible to build quality systems and get them right first time – Every time.

It’s called Quality!

Tags:

5 Responses to “Data Models are for Wimps!”

  1. George Fairbanks March 8, 2009 12:09 pm #

    Hi John,

    I stopped by your site after you posted a comment on my blog which you titled “Without Data Models There Can be No Architecture” (http://rhinoresearch.com/node/17#comment-14). Here, your blog post is “Data models are for wimps”, which I’m guessing is a caricature of what Agile folks think.

    Overall, I’m sympathetic to the Agile idea that the desired end product often changes over the life of the system, either because the market changes or the customer changes his mind. On the other hand, I think that software architecture can help projects, especially larger ones, avoid risks of failure — in that respect I’m sure we agree.

    It seems like you have a firm goal of absolute quality, whether the product is a doghouse or a skyscraper. In what ways to you tailor your process to adjust the needed quality of the outcome?

    Regards,

    -George

    • John Owens March 8, 2009 12:55 pm #

      A good question, George.

      One useful definition of quality that I use to guide me is “fitness for purpose”. So the requirements for a doghouse and a skyscraper would differ – even a skyscraper for dogs!
      Likewise in software. If I am putting together something “quick and dirty” to test a scenario or prove a concept, then “fitness for purpose” would be a data model in pencil on a sheet of A4, a rough mock up of the screen and iterations would be short and acceptable.

      If I am going to deliver something to the business that is going to be a serious operational system (even a small one) that will be part of their overall information architecture then the “fitness for purpose” of the models I build prior to construction will need to be much more rigorous. I have to make sure that the system will be compatible with the existing information architecture and will be scalable, etc.

      My definition of good analysis and modeling is minimum of effort for maximum productivity and quality and no surprises!! This is one of the reasons I put together the Integrated Modeling Method – to make life easy and development of quality systems fast and certain.

  2. John Owens March 8, 2009 11:35 am #

    Having spent many year in the world of Total Quality Management, where it is all about “Getting it right first time, every time”, and having achieved this in my software projects, I have difficulty in accepting that we now have to deliver the wrong thing first time and then try to make it right.

    In Agile approach it says that one needs to deliver something of value to the customer every iteration and we led to believe that this is a sensible approach.

    But is we extend this thinking to building a new building for the company would the builder do it over several iterations and also need to produce something of value to the business every two weeks? Deliver one room at a time?

    You see, I do believe its possible, I have done it and have seen others do it, to deliver quality software in short time intervals and get it right.

  3. Larry Maccherone March 7, 2009 8:58 am #

    This is too funny.

    On the one hand, we have George Fairbanks (who comes from the architecture world) arguing that data models are too low level to be considered architecture (http://rhinoresearch.com/node/17). On the other we have you, John Owens (a leader in business process modeling), arguing for them in the context of your integrated modeling method.

    My point (http://maccherone.com/larry/2009/03/05/we-have-to-get-people-to-build-this-stuff/) is that it doesn’t matter whether you consider them part of the architecture or not. It doesn’t matter whether they are in YOUR definition of a good process. The rise of “Agile” is a response to the insistence upon adopting someone else’s approach. This resulted in misapplication and the developers became cynical.

    If you don’t want to be dismissed by the Agile world, you have to start selling in smaller chunks and let the developers decide which chunks to use. For me (a process, quality, and security guy), the easy sell is some form of peer review and the effective use of passively gathered data. For you, John, it might very well be data modeling. It’s a bridge between the business and development domains. I’ve read the excerpt of your ebook on this subject, and it is one of the clearest explanations of the topic I’ve ever read. I’m not sure what chunk is the easiest sell for George but his ability to extract abstractions (even from domains other than software) has impressed me greatly over the years. I just don’t know how he can best share that.

    What I do know is that we should stop pushing integrated anything (fortunately, I can buy just the IMM ebooks that I currently need). We should stop defending our definitions/domains. Rather, we need to target our efforts at the primary form of the Agile feedback loop (Visibility -> Retrospection -> Adaptation) and make our case in the retrospection phase after they’ve experienced trouble by not doing enough design, requirements, or quality activities. Don’t worry about the second form of the Agile feedback loop (Plan -> Build -> Refactor). It is more of a guideline than a rule and is more easily expanded as we’ve seen with the introduction of Iteration/Sprint Zero proposals (http://forums.construx.com/blogs/earl/archive/2009/03/03/watching-agile-grow-up.aspx).

  4. Karen Lopez March 7, 2009 2:21 am #

    In my experience, those who want a highly iterative process want it for themselves but not for others on their team. They want set in stone, “no more changes” inputs. Their outputs can be ripped apart, changed, modified, enhanced, tweaked, hacked and generally chaotic…but everyone else needs to stop making changes.

    I’m all for iterative development – no hard and fast waterfalls. But collaboration still has to happen on projects to make a team an actual team working towards the same goal.

Leave a Reply