Link: http://weblog.tetradian.com/2015/06/27/professionalism-waivers-and-the-hard-questions/
“Never expect someone to get it if their income, job or status depend on not getting it” – that’s a challenge that enterprise-architects and others face every single day…
Within the enterprise, we’re tasked with finding ways to implement and support the core theme of all architecture – that things work together when they work together, on purpose. Yet what can we do when we find some aspect within the enterprise where not only is there something that is blocking that ‘works-together’, but people seem incapable of understanding what it is, or what’s needed to resolve it?
Or, worse, that they already know that it doesn’t work, but are either studiously ignoring it in the hope that it’ll magically solve itself, or are even intentionally maintaining that flaw for personal profit or gain?
Tricky…
To give a concrete example, we now know, without any possible doubt, that Taylorism doesn’t work – or rather, that it only works well within a very small subset of business-contexts, within very specific and well-identified constraints. Yet business-schools still churn out would-be ‘managers’ with shiny new MBAs – the all-too-literal Master of Business Administration, implying an overblown clerk with overly grandiose ideas about their own importance in the broader scheme of things. And even now, despite all of the evidence against it, the core of almost all current MBAs is Taylorism:
In other words, arbitrary numeric targets and “our strategy is last year plus 10%”, input-based metrics, money-centric definitions of ‘value’, rigid separation of analysis and action, top-down control, fragmentation via silo-based hierarchies, parasitic ‘owner’-relationships and all of those other errors that we know do not work, and that lead to a ‘management’-centric concept of the organisation that looks like this:
– which is literally upside-down and back-to-front relative to what does work, which is a fractal service-oriented structure in which management is ‘just another service’, and that looks more like this:
The problem in that case is that, in order to get the enterprise to work, we need to get them to understand that pretty much everything that they learned at their very expensive business-school is exactly what not to do in a real enterprise, and that they need to scrap the whole lot and start again from scratch. There’s more than enough evidence by now to confirm that this is indeed true: but needless to say, this is not exactly a popular statement to make to that audience of ‘decision-makers’…
Which means that the decisions they’ll make will almost certainly continue to be the dysfunctional ones that they do now. And, courtesy of the sad circular-reasoning of ‘policy-based evidence‘, they’ll be able to convince themselves that those were the right decisions, too – regardless of how much damage they actually cause.
So what can we do about this? As architects, it is explicitly our professional and ethical duty to warn about the dangers of this: yet often it’s clear that no-one is listening – sometimes very pointedly ‘not-listening’, too… And yet if we do continue to push on this, the only likely outcome will be a ‘shoot-the-messenger’ exercise in which we get fired – or worse, in some cases – because we’ve tried to do our job properly. Too often it seems that whatever we do, we’d lose: looks like we’re caught between a rock and a hard place here…
Fortunately, there is a sort-of way out of this mess. It’s called a waiver.
(Section 50 ‘Architecture Governance‘ in the TOGAF 9 specification describes this as a ‘dispensation‘: in essence it’s much the same thing. I know I criticise TOGAF rather a lot, but this is one section of the standard with which – other than for its usual incipient IT-centrism – I would strongly agree.)
Our role as enterprise-architects is mainly one of decision-support, not decision-making – we can, do and should give advice on architectural concerns, developed to the best of our ability, but unless we are explicitly asked to make decisions, the final decisions are not ours to make. And that distinction is crucial (not least for our continued employment…).
If we’ve done our job well, we should have a pretty clear idea of what would work in the enterprise, and what won’t – what will support ‘things-working-together’, and what won’t – and our advice should indicate and describe that overall understanding, in terms appropriate for the respective audience. In short, our advice should mean something – the kind of advice which is unwise to ignore, especially at the typical scope and scale of an enterprise-architecture. So if our advice is then dismissed or ignored, we do need to make it clear to all involved that there are likely to be consequences for the organisation and its business – consequences that could well cause serious damage. It’s that that we need to document in a waiver.
In effect, rejection of enterprise-architecture advice would usually represent a conscious and intentional decision on someone’s part to create a non-conformance to the architecture – which, by definition, represents a verifiable architectural risk. Sometimes such risks are necessary and unavoidable: for example, in classic IT-oriented architecture, that some system or functionality that we need is simply not available at the current time. But whenever such risks are created, we must review them at some future date, and take action to mitigate them as soon as practicable.
A waiver should include at least the following items:
- the context of the architectural-advice (such as the initial business-question, and the respective scope within the overall enterprise-architecture)
- the advice that was given (the architectural response to the business-question)
- the expected consequences of compliance and of non-compliance to that advice (opportunities and benefits, and risks – both direct and indirect)
- the basis for that advice (frameworks, assumptions and so – in part to mitigate our own tendencies towards ‘policy-based evidence’)
- supporting-materials for the advice (presentation-slidedecks, architectural-models, assessment-materials etc)
- identifier(s) for the presenter of each part of that advice (indicating that the advice was given)
- identifier(s) for the decision-maker for each part of that advice (indicating accountability for the decision)
- the decision taken by the decision-maker(s) (indicating the risks and consequences for which each decision-maker has now accepted personal responsibility and accountability, against the architects’ advice)
The last item is crucially important for us as architects, because it may well provide necessary evidence for defence for the architect if (or, more likely, when) everything goes pear-shaped as a result of the decision-makers’ choice to reject architects’ advice.
One more essential item for a waiver:
- the review-date and/or event-triggers at which the waiver must be reassessed and reviewed
This too is crucially-important, because if we don’t include triggers for an explicit review-process, the waiver will simply become quietly forgotten as permanent-shelfware – and then, in all probability, conveniently ‘lost’ when things do later go pear-shaped. CEOs and other executives move on; even the most useless of managers eventually move on (even if only ‘promoted’, in the manner of the Peter Principle); hype-bandwaggons eventually fade; and whenever that happens, opportunities may arise to review past errors, and repair the damage that may or will have been done by daft architectural-misdecisions. That’s when waivers really prove their value.
(Again, do also take a look at TOGAF 9′s description of ‘dispensations’, particularly in subsection 50.2 ‘Architecture Governance Framework’ for their view of how such review-processes should work: it’s useful guidance even for beyond IT-oriented architectures.)
One aspect of architecture where we’re likely to need to create and monitor a lot of waivers is around service-oriented architectures at whole-enterprise scale – services in the most general sense, that is, not just IT-services. The reason for this is that alongside the known services are likely to be some very serious service design-flaws, or what I describe as disservices – and, rather like that Taylorism example above, many of those arise from causes that many people would very much prefer not to be noticed or known, regardless of how much damage the resultant disservices do to the enterprise. As architects, we need waivers and the like, and systematic processes to support them, as a means to give us at least some relative safety as we work with those issues. More on that in the upcoming series of posts on services and disservices, anyway.
Hope this is useful – over to you for comment, perhaps?
