That's a bit of a mouthful - but it is the synthesis of a lot of material from the SITA technology conference held near Brussels in June this year.
So, I'll put in context and then see where it leads us. The context is that in the airline industry, cost cutting has become so critical (tiny profit margins flying planes) and the global situation has become so complex that we see more and more disruption. Then the clod-footed governments step in and put excessive fines onto the airlines for delays and the whole schedule becomes a crap shoot. Airlines have rarely actually operated the flifght schedule they publish - something always seems to go wrong, but with the ever decreasing tolerances, the ripple effects of tiny perturbations can be huge. Layer in larger events (weather, volcanoes, strikes, terrorism..) and we have an unholy mess.
Now in many systems development approaches and methods, we are encouraged to do the "happy path" stuff first. Work on the "normal" cases, deliver those and then do the abnormal things on subsequent iterations. That's great if the normal cases truly are normal. And by that I mean deliver most of the value, and absorb the least cost. But what if there is no "normal"? Then how do we prioritize?
Clearly the "customer" - the stakeholder paying for the solution or on whose behalf the system is being developed will have input to that. But therein lies the rub. There's all sorts of stuff that can go wrong that will potentially affect the architecture and design. And no this isn't enterprise architecture - this is much smaller than that. This is solution architecture - and a classic source of tension in development.
The solution architect has the responsibility for ensuring that the solution is fit for purpose - but the main purpose is in understanding the degree to which change will stress the system. If this weren't necessary then every solution would be a simple client/server solution (yeah, tongue firmly in cheek here).
So understanding what's normal/what isn't. What change stressors will be taken into consideration and still not get all crystal-bally is what makes solution architecture hard. It's also what makes it fun!
Don't be seduced by quick wins on the happy path when the need for the system to absorb change stress is paramount. Don't get all wrapped up in clever system integrity and cunning architecture when you are simply managing transactions - e.g. a recipe file!
So, I'll put in context and then see where it leads us. The context is that in the airline industry, cost cutting has become so critical (tiny profit margins flying planes) and the global situation has become so complex that we see more and more disruption. Then the clod-footed governments step in and put excessive fines onto the airlines for delays and the whole schedule becomes a crap shoot. Airlines have rarely actually operated the flifght schedule they publish - something always seems to go wrong, but with the ever decreasing tolerances, the ripple effects of tiny perturbations can be huge. Layer in larger events (weather, volcanoes, strikes, terrorism..) and we have an unholy mess.
Now in many systems development approaches and methods, we are encouraged to do the "happy path" stuff first. Work on the "normal" cases, deliver those and then do the abnormal things on subsequent iterations. That's great if the normal cases truly are normal. And by that I mean deliver most of the value, and absorb the least cost. But what if there is no "normal"? Then how do we prioritize?
Clearly the "customer" - the stakeholder paying for the solution or on whose behalf the system is being developed will have input to that. But therein lies the rub. There's all sorts of stuff that can go wrong that will potentially affect the architecture and design. And no this isn't enterprise architecture - this is much smaller than that. This is solution architecture - and a classic source of tension in development.
The solution architect has the responsibility for ensuring that the solution is fit for purpose - but the main purpose is in understanding the degree to which change will stress the system. If this weren't necessary then every solution would be a simple client/server solution (yeah, tongue firmly in cheek here).
So understanding what's normal/what isn't. What change stressors will be taken into consideration and still not get all crystal-bally is what makes solution architecture hard. It's also what makes it fun!
Don't be seduced by quick wins on the happy path when the need for the system to absorb change stress is paramount. Don't get all wrapped up in clever system integrity and cunning architecture when you are simply managing transactions - e.g. a recipe file!
Posts
0 comments:
Post a Comment