Historically, and probably still today in over 90% of the enterprises I ever worked with, the ABBs and their implementations presented in the Enterprise’s Architecture ABB Framework are created, published and championed by a small community of Enterprise Architects, who encourage, cajole, and maybe even pressurise their numerous Solution Designers to use them.
Right at the start of this blog I said “[over the years] I've learnt a lot about politics, people, power, persuasion, passion... and a little about computers”. And it’s these 5Ps that I think really make the difference to an architecture’s success.
The first sign of this in this blog was my reflection on language (shared language = one community, one community = co-operation and shared goals). Here’s another, equally critical factor.
Many years ago I was teaching a Solution Design class to a 20 senior Designers from a leading UK Pension company. I’d been discussing the power of “System Context Diagrams” (more on these later) and how they not only help designers understand what their users will be doing with (or for) the system; they are also a powerful means of understanding the capabilities and competencies of their systems’ users.
And one of the more vocal guys in the group said… “Hold on. I’m designing systems for the same users as Joe over there is. Surely it would be a good idea if we shared our understanding of our users’ capabilities, how they use computers, and so on?” And then the magic… “Why don’t Joe and I work together to define a proper set of user specifications, that we all (by whom he meant all 20 designers in the class) can use in our work? We can then give that list to you (me, the Architect) to look after for us, and to help ensure we conform to them in our designs!”
A really influential moment: which is the more likely to succeed? If “I” create something, and insist “you” use it, will you? Or is it more likely if “the plural you” create the ABBs then use them, giving them to me to look after on behalf of you all?
In other words, in my experience, the most successful Architectures are those created by those who are expected to use them – the Designers. Architects then have the equally vital role of curator: ensuring the ABBs remain valuable and used, ensuring conformance (or allowing exceptions).
(There is another angle to this that I’ll return to later – ensuring the wider context in which the ABBs are created is relevant to the enteprise as a whole, and not just a “codification of today’s stuff”. I distinguish this as using Architecture to “do the right things”, whereas the theme for a few posts now been using it to “do things right”.)
No comments:
Post a Comment