Lazy modeling #2: laziness attitude

Say that lazy means not going till something’s end. Lazy modeling means doing models that don’t hold all the material they could carry. Say we talk about MDD(a) (What else? ;D), so we talk about a PIM(b) which describes business/functional/architectural requirements.

This PIM holds decisions about a solution to an initial business need that has be solved with (part of) an application:

1. Some details about business objects(c) (ex: business objects properties)
2. An arrangement of functional requirements in a way that is independent from a platform implementation… But not independent from the fact that these requirements have to be implemented in an application (ex: relations between business objects)
3. Eventually explicit or implicit applicative architecture hints/directives

For sure, such information is highly valuable as directives to the material solution builders – I mean developers. Usually developers are human, but in MDD part of their job may be delegated to code generators (or something equivalent like a model interpreter).

Wait a minute. How do developers work when they don’t have a PIM in input? Here I talk about 90% (at least) of application development projects, even if we are mainly interested with the others 10%. They indeed have the same kind of input, roughly:

1. High level specifications
2. Low level specifications
3. Programming rules (in best cases !)

However these specifications are given in a usually less formal, more opened, more inconsistent, but maybe easy for anyone to read, so in a more lazy way.

This is a first laziness footprint: we are all used to deal with laziness as the way we build applications is based on lazy fully adopted practices.

The main impact? Final decision is delegated to developers. And unless eventually using high level TDD(d), final implementation is always the result from a negotiation between stakeholders and developers… And all the Agile project team around them ;D !

For some other reasons, among them the impossibility to fully model the real world (ask physicians, or better: meteorologists!), we can’t have complete models of fully expressed needs:

1. Business level – We have to deal with legacy systems: >90% business objects (here I mean by example virtual classes reversed on top of DB content) yet exist… And they are usually not 100% consistent (a pity they didn’t use models 30 years ago!). Furthermore, stakeholders often have partly concurrent goals or don’t tell all the truth at the beginning of the project
2. Functional level – Functional designers have ideas, and models may captures these ideas in a very productive way. But nothing tell that these ideas are consistent and stable. In fact, untill seeing the final application running functional designers rarely put their head on the billot…
3. Applicative architecture level – Yes! Applicative architecture may be fully defined. It easy, it’s just a matter of choices in discrete lists of possibilities. Advice to keep it at an easy level: put only one architect on this subject ;D

So what?
Don’t try to put all the stuff in models. Except if you want to work without any human developer, try to put sure things in models and let a part of the work to developers. They are used to it… And they do love that!

Be lazy: keep models simple. It’s always better than no model at all. And if developers can easily understand models and their requirements embedded semantic in regard with what they have to code… They even should forgive you to use some code generation ;D

(a) MDD = Model Driven Development, which stands here for any forward-MDE approach including MDA
(b) PIM = Platform Independent Model, which stands for any DSL, based on UML or not
(c) here business objects stand for business classes…
(d) TDD : Test Driven Development

Featured image taken from http://users.abo.fi/mcollan/lazyusertheory.html