Saturday, August 30, 2008

Easy design decisions

Of course you know why and how to prevent "meat-ball" designs characterized by no adequate modularity (spaghetti) and no functional separation (e.g. multiple message types combined to one). You don't need an architecture or any standards for that. As a professional designer you just know; it's you craftsmanship.

But are you designing an IT-system and do you have to cope with equally valid alternatives that are not addressed in the overall architecture? And there are no standards defined? Or there is no architecture at all because of the low maturity of your IT-organization? Then these criteria may be of any help to you:

Maximum flexibility (future changes)

Choose the alternative that needs the least effort when requirements change. E.g. if you must decide whether to implement JMS-topics or to implement JMS-queues, prefer topics over queues. Queues can only deliver to one consumer whereas topics can deliver to mutiple consumers. So if - in this example - a second unforeseen consumer pops up, no changes are needed to the system.

Robustness (self healing)

Choose the alternative that doesn't break the system when failures occur. E.g. if you must decide whether to implement durable subscription or non-durable subscription, prefer durable over non-durable. In this example there will be no loss if a consumer goes down for a while; the system recovers automatically when the consumer is up again.

Open standards (lower costs)

Choose the alternative that is based on open standards. E.g. if you must decide whether to use a JMS-API or an MQ-API, prefer JMS over (proprietary) MQ. This makes you less dependent from specific products and suppliers, which improves flexibility and lowers costs. In this example you don't need to change your programs if they must run on another messaging infrastructure.

Of course these design decisions must be challenged against aspects like performance and scalability. E.g. durable subscription may lead to huge databases for the required persistency. But let these aspects be an afterthought and not be leading for the design. First create a design based on the criteria mentioned above and then - afterwards - start tuning the design based on pragmatic aspects; and document why and how you tuned the design. As to-day's limitations need (will) not necessarily last forever, you will be happy to be able to easily upgrade the design when the limitations no longer exist.


Rick Mans said...

Isn't it rahter time consuming first designing a sunny day solution and than adjust to the harsh reality? To me it seems more efficient to hold in mind all requirements and future developments concerning of the required solution and to make a design matching these requirements.

What is the idea about first creating the by far most ideal situation on paper each time you design a solution?

Jack van Hoof said...

Hi Rick,

As systems evolve over time, you need an "ideal" picture as a compass for all future changes. Also for the changes (requirements and future developments) that you can't possibly think of at present time. Mind that I am talking about the non-functionals in this posting.

Designs holding implicit trade offs (=doing things differently from what is ideally preferred) to cope with current implementation limitations are not a good compass the navigate to the future.

You must make your current non-functionals trade offs explicit and visible to be able to rechallenge the trade offs for every new release of the system.


Harsh S said...

I agree, good designers instinctively create solution where these three dimensions are given top most priority and then step back and account for the practical aspects.