An architectural fundamental is that things that are not related should not cause failure on each others' part. The printer breaking should not stop the processing of orders. It does stop the printing of orders (duh), but should not stop the processing.
Some of the systems I deal with put me in mind of a sewage system. Bear with me here...
So, imagine the following undesirable situation. You are standing at the sink after dinner washing the dishes/pots/pans etc. It had been raining very hard all day, so the drainage systems had been well overtaxed. You are startled to see stuff coming UP the drain (perhaps from your neighbors house - you can tell what they had for dinner too). This is clearly an undesirable effect.
On further analysis you realize that the drainage system couldn't take the runoff fast enough, so your house, being lower than your neighbours, became the lowest point their effluent could reach. Oh dear.
Of course restuarant codes (at least in the USA) have a cure. They make sure there is a buffer zone between the sewage system and any sink where food is prepared. It is an airgap and a sufficiently large gap that any attempt by effluent to rise up will be nullified. It will spread all over the floor instead. Not much better, but definitely not contaminating food in a sink.
So what's the lesson here? Denial of Service through increased load on a system is something to watch out for. make sure you understand the implications and design accordingly.
This is as important at a business level as it is at a technical level. Who hasn't experienced a lack of planning - perhaps an airline offering a fare sale and not scaling enough to have call center representatives. Or the fiasco in Texas where the "business" (the State) offered rebates for trading in old appliances. They underestimated demand horribly.
The enterprise really has to understand its business models and take care to scale appropriately - and communicate that through to all interested and relevant parties
Posts
Business Process Management: Easier said than done
14 years ago
3 comments:
Ah, but is the sink related to the drain or not?
The architect is faced with two opposing agendas. One is called integration and alignment, which connects and couples everything in the name of efficiency and straight-through processing. The other is called deconfliction, which separates things for the sake of flexibility and safety. I am amazed how many enterprise architects are strongly biased towards integration and are unfamiliar with the concept of deconfliction.
And as you point out, questions of scale are critical. An airport with one flight landing per hour has a lot fewer coordination issues than one with a flight landing every minute, but is a lot less efficient, because some of the key resources (runway, ATC, baggage handling) are idle much of the time.
Good to know there is a proper word for that separation. I like the word deconfliction.
Yes it is amazing how integration "efficiency" (straight through processing high speed integration, etc. hold sway over deconfliction - until things break. Then we have the rear view mirror approach "You should have planned for that."
Adding deconfliction later to systems that are coupled is a thankless - and well nigh impossible task. Unless the failure in the "efficient" model was so catastrophic that the enterprise is prepared to "waste" resources solving it.
The military have always understood deconfliction - fighting units either have to be tightly coordinated or far enough apart not to have too many "friendly fire" incidents. One of the reasons for armies investing in advanced communications systems is to reduce the need for deconfliction and allow forces to be coordinated more efficiently and effectively. The economic trade-offs here are very difficult to calculate, but at least the defence world is aware of the problem.
Post a Comment