Enterprise Architects - With apologies to Buffy Sainte-Marie

In her great song - Universal Soldier (sung here by Donovan), Buffy Sainte-Marie describes an impossible ideal for a soldier. Sometimes I think we enterprise architects have to have a similar set of impossible and conflicting attributes. We have to be (as discussed in other posts) archivists and activists), but then we also have to be good listeners (not a common trait among activists), understand the business in totality and yet have a reasonable (whatever that is) understanding of the technology that powers it. We have to be agents of change, and stewards of stability. We have to understand the patterns of interactions and their implications. We have to understand systems concepts (systems of record/systems of reference) and we have to understand the financials. We have to understand some of the legal implications of our decisions and we have to understand risk. We have to understand how to negotiate and when to strongarm.

All in all quite a difficult and conflicting set of characteristics

Irregular is the new regular

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!