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 better 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?
On the pervasive, seemingly eternal influence of Taylorism, I belatedly came across a 2009 book, The Management Myth, by Matthew Stewart. His narrative alternately traces his own early career as a philosophy student turned management consultant with a very critical history of management (pseudo) science from Taylor, Fayol, Gilbreth, Gantt and the 47 1/2 tons of pig iron, through Mayo, Ansoff, Drucker and McNamara, to Porter, Peters, Champy and Collins. It’s six years old, so this is probably old news, but I found it definitely worth a read.
Thanks for the tip on that book, Doug – will definitely chase it up.
Right now I’m about halfway through Kentaro Toyama’s book ‘Geek Heresy’ – very strong recommend on that too, a really clear and irrefutable inditement of the usual hype on “technology will solve everything all on its own!”. What it shows is all that technology really does is accentuate any existing differences – which means that rather than reducing inequalities, it actually makes them worse. The only way that does work is to focus on the people first. It’s a really important message that enterprise-architects really need to hear – but whether they’re willing to listen is quite another question, of course… :wry-grin:
I appreciate the pointer to the Geek Heresy. I have pulled it down for my Kindle app, and I’m charging through it as we speak (that is, as we write :-} ). I think this will be one I’ll refer to a lot. It makes me focus on the fact that we’ve now attained the level of 7.3 billion humans on the planet, and that each an every one of them are and will be involved in various ways in multiple enterprises now and throughout their lifetimes. This helps add some perspective to the reality that enterprise is by people and for people, and that architectural thinking about enterprise provides unfathomable challenge and opportunity. If we can just squeeze ourselves out of the constraints of our own making.
Thanks, Doug. I’d be interested in your comments on ‘Geek Heresy’ – I’m still only about halfway through the book, but even this far it’s still an eye-opener, very practical.
“This helps add some perspective to the reality that enterprise is by people and for people, and that architectural thinking about enterprise provides unfathomable challenge and opportunity” – very strong agree with you on that, though probably no surprises there? 🙂
I’ve been in the book on and off, and I think the main message will now be engrained for me: that packaged interventions are never enough to reach straightforward goals of social progress, but actually act as amplifiers of the cultural situation already in place. This is hugely variable, of course, since social situations are always complex, but it really helps bolster the importance of human factors in the architecture of every kind of enterprise, anywhere, anytime.
@Doug: “social situations are always complex, but it really helps bolster the importance of human factors in the architecture of every kind of enterprise, anywhere, anytime”
Very strong agree on all of that (though no surprise there, as you’d know… 🙂 )
The practical point that follows, of course, is “how do we get the IT-obsessed to understand this?” – that their IT-centric packaged-interventions are at present still mostly making things worse, not better? Right now I can’t see any feasible way other than by standing over them whilst they’re required to read the ‘Geek Heresy’ book cover-to-cover – and for most of them, I doubt the message would get through even then. Oh well…
A link to reference material on how you know that Taylorism doesn’t work would be appreciated in the article. That’s a strong claim to make without some reference to back it up.
My apologies, Pete – I thought it was well-known by now that Taylorism (and its latter-derivatives such as IT-centric ‘business-process reengineering) is and always has been deeply-flawed – particularly in its failure to grasp the human elements in a work-context. Just about anything by Deming, for example, would illustrate most of the dysfunctional behaviours and unintended-consequences from a management-model that rigidly separates thinking from doing – “check your brain in at the door” etc – and that treats all workers as fungible/interchangeable components in a machine.
A quick web-search for ‘taylorism critique’ should soon turn up plenty of other examples, such as http://www.managementstudyguide.com/criticism_scientificmanagement.htm .
I remember reading somewhere that Taylor essentially fudged all of his data in his original study at Bethlehem Steel – but I can’t find the reference, so I can’t quote you that source. It’s certainly a matter of historical record that Taylor challenged individual workers to do extreme feats over short-burst periods, and then claimed that this performance should be the norm for all workers over an entire work-day – i.e. mispresenting an edge-case as a median, in other words a form of statistical fraud.
It’s true that Taylorist-type techniques do work quite well in certain special cases where the work is essentially predictable, repeatable, low-skill and executable as ‘done by rote’, but still too complex for a machine as yet to be able to do – the McDonalds work-manuals are a well-known case in point. Yet for anything else that includes any significant degree of natural-variance or inherent-uncertainty, a statistics-based model that relies on external evaluation is too unreliable and too slow. (This is in contrast to Deming-type approaches, where statistical-evaluation is likewise used, but in a very different way, with decisions taken by staff at the front-line, not escalated to an external ‘expert’.) A common outcome is the ‘Taylorist trap’, where escalation to a ‘more senior’ person with the authority to take action is also not likely to have the front-line experience necessary to resolve the problem; the resultant escalation-delays cause further hold-ups and then pile-ups, often leading to abandonment of quality just to get the line moving again.
Taylorist theory mandates that managers alone should be in control of the speed of the assembly-line – but in practice that often resulted in an overfocus on quantity (the basis of managers’ bonuses), regardless of whether tasks could actually be done in the allotted time, given natural variance in materials and/or required skills. This was a direct cause of loss of quality in US car manufacture up to around the 1990s, in turn causing loss of reputation and market-share. Allowing the workers to control the assembly line – the exact antithesis of Taylorism – enabled a refocus on quality, and US vehicles produced far closer to defect-free. (See e.g. ‘Background’ section of Wikipedia-page on General Motors’ NUMMI plant, and HBR: ‘Decoding the DNA of the Toyota Production System‘ (October 1999).)
My opinion is that managers’ endemic attempts to use Taylorism in contexts for which it is fundamentally unsuited, would say less about the limitations of Taylorism itself, and more about managers’ need for delusions of certainty and ‘control’ where in reality such ‘control’ is inherently non-achievable (e.g. as in ‘wicked-problem‘ contexts). Business-school courses that still teach Taylorism have much to answer for… 🙁
Hi Tom — I’m not sure if this is the source of your “I remember reading somewhere that Taylor essentially fudged all of his data in his original study at Bethlehem Steel,” but one source of great detail on Taylor, and a whole string of management gurus from Gantt, to Mayo, to Porter, Drucker, and Peters, is the book The Management Myth by Matthew Stewart. Stewart goes into great detail about the pig iron work at Bethlehem, as well as the circumstances of “the Hawthorne Effect” (not Taylor), and lots of other interesting history of the professional consultant.
An interesting aspect of all this, to me, was Taylor’s original perspective. I was inspired at some point to get his original Principles of Scientific Management, where I find this passage: “Underworking, that is, deliberately working slowly so as to avoid doing a full day’s work, ‘soldiering,’ as it is called in this country, ‘hanging it out,’ as it is called in England, ‘ca canae,’ as it is called in Scotland, is almost universal in industrial establishments, and prevails also to a large extent in the building trades; and the writer asserts without fear of contradiction that this constitutes the greatest evil with which the working-people of both England and America are now afflicted.”
Little did I know what an heroic effort Mr. Taylor undertook – to rid the working-world of the evil affliction of ‘soldiering’! My head spins.