All We Like Sheep Have Gone Astray

PRINCE2

Unsettled, the haplessly-institutionalised incumbents huddled together for warmth, two to a cubicle, cruel flickering artificial light obliterating any capacity they once might have harbored for self-actualisation or for problem-solving, casting an especially-stark relief upon their miserable, wasteful, angsty souls.

They were unsettled by the juggernaut paperweight reputation of the new shepherd coming to guide them, probably to slaughter them, certainly to restructure them, and this new shepherd, this new shepherd was certified!  This new shepherd with a string of certifications long as a donkey’s tail: TOGAF, ITIL, PRINCE2, PMI, COBIT, MSCE, and a beginner’s first-aid certificate and some first-year classics and ancient history university study as a bonus.

Their fearfulness was palpable and paralysing and visceral, but, in the end, thoroughly unwarranted, for this new shepherd was just a person, just a person with the same pains, hopes, and fallibilities the rest of us have.

There continues to be much over-hype about certifications in IT, particularly about enterprise-architecture certifications, and particularly about TOGAF certification.  Demonstrating core knowledge in a domain or discipline through a standardised assessment process is a good thing, and establishing reliable credentials is a good thing for the profession of Enterprise Architecture.

Where the simple system of “credentialled = worthy” breaks apart is the point at which the credential itself becomes imbued with mystique and desirability and is viewed as an end in itself.  For enterprise architecture, where the professional practice must be adapted from one vertical to the next, from one organisation to the next, from one practitioner to the next, and from one type of engagement to another, having a detailed map to follow is neither possible nor sensible.  What’s needed is a compass, not a map1, and none of the major enterprise-architecture frameworks currently provide compasses or maps.

Gartner summarises the current state of affairs nicely in the 2014 edition of the Hype Cycle for Enterprise Architecture2, including observations that:

  • certification’s value is unclear to organisations
  • certification’s value is unclear to individuals
  • certification is a good thing to have on your resume
  • certification implies almost nothing about proficiency

The always-insightful, always-thought-provoking Tom Graves makes crucial observations about skills and (or versus) certifications in his Saving enterprise-architecture from itself post3:

  • certification has become a commonplace recruitment filter for enterprise architecture roles, and this approach weights certification (which is typically no more than a few-days-long short course) overwhelmingly and disproportionately more heavily than years of applied experience working as an enterprise architect
  • certification in enterprise architecture frameworks ignores the enormously-important complement of soft skills (the communication, leadership, collaboration, and adaptability) that are essential for success as an enterprise architect — they do this because the enterprise architecture frameworks themselves are barren of soft-skills content

Jason Bloomberg’s new Bloomberg Agile Architecture4 is a great new example of practical, adaptable, and flexible applied enterprise architecture.  This new technique differentiates itself from the traditional heavyweight do-everything subtractive frameworks (i.e., you discard pieces of the framework you think  you don’t need) by instead taking an additive approach that incorporates elements, artefacts, and capabilities as they are found to be required in order to deliver a particular business outcome.  There’s much to like about this approach.

The danger for enterprise architecture is that the academic energies wasted mewling sheeplike after the frameworks and the certifications are preventing us from forming constructive connections with our customers, partners, and stakeholders, and inject bedazzling interfering distractions that prevent fulfilling the mission and promise of business-outcome-focused enterprise architecture.  Curiously, the more of us that become certified in a common framework, the better the chances of those frameworks being improved, of architects developing common vocabulary and process, and the better the chances of certification’s value becoming clear and visible.

The frameworks have much to contribute to and provide anchor for the practice of enterprise architecture, and there is value to be found in them, but leading in a still-diverse and still-immature profession with overemphasised focus on the merits of certification as a rite of passage and entitlement to speak is leading all we, like sheep, astray.

 

 

 

 

  1. Principle 3 here is very nice: “compasses over maps” = MIT-Knight Civic Media Conference, 2014, Joi Ito’s 9 Principles of the Media Lab, http://vimeo.com/99160925
  2. Betsy Burton & Philip Allega, 2014, Hype Cycle for Enterprise Architecture, 2014, http://www.gartner.com/document/2804819
  3. Tom Graves, 2013, Saving enterprise-architecture from itself – 3: Skills and certification, http://weblog.tetradian.com/2013/11/11/saving-ea-from-itself-3-skills/
  4. Jason Bloomberg provides essential reading for enterprise architects in these two pieces:
    1. 2014, Is Enterprise Architecture Completely Broken?, http://www.forbes.com/sites/jasonbloomberg/2014/07/11/is-enterprise-architecture-completely-broken/
    2. 2014, Is the BAA Technique an Architecture Framework?, http://intellyx.com/introducing-the-bloomberg-agile-architecture-technique/is-the-baa-technique-an-architecture-framework/

Ideal Circumstances for EA Frameworks

Ideal Circumstances for EA Frameworks

Significant touchstones, at least for some people, some of the time, the series of hype cycle devices published annually by Gartner inform and guide industry behaviours, lead and shape the formulation of strategy.

Three features of the current enterprise architecture hype cycle1 are noteworthy, or thought-provoking, or self-evident:

  1. Whole-of-Government enterprise architecture has been cancelled due to lack of interest and because it is unlikely to deliver transformational benefit… except under ideal circumstances.
  2. Enterprise Architecture Frameworks are on notice, because they’re implemented as a whole insufficiently often to make solid ground, they’re probably a decade away from delivering benefit, and too many enterprise architecture practitioners are distracted by them.
  3. Enterprise Architecture as a discipline “…proactively and holistically leading enterprise responses to disruptive forces by identifying and analysing the execution of change toward desired business vision and outcomes” is moving into the plateau of productivity, and the discipline of enterprise architecture will deliver transformational benefit within the next few years.

Tying these features together and thinking about what they mean for my own enterprise architecture practice generates the following simple good-vs-less-good system:

  • Old School: heavy-framework approaches tend to be neverending documentation exercises capable of producing enormous amounts of exactingly-beautiful and perfectly-irrelevant families of well-organised zero-benefit enterprise architecture artefacts.
  • Change-Friendly: the ultimate outcome of enterprise architecture is change-friendly capability delivery3

…and some unanswered questions:

  • Ideal Conditions: what are the ideal conditions under which enterprise architecture (as a discipline) and enterprise architecture frameworks (as a belief system) and whole-of-entity enterprise architecture (where “entity” might be a division, an enterprise, a government, or a global corporation) may thrive and deliver the transformational benefit they promise?
  • Measuring Benefit: particularly vexed and repeated plaintiffly everywhere, the question of how we as a community of enterprise architecture professionals measure (and communicate well) the benefit delivered by the enterprise architecture discipline.

Whether emergent, pace-layered, pragmatic, lean, agile, or just-enough — by any name, involving enterprise architecture in change initiatives, in strategy formation, in policy review, in service design, in everything, usually leads to improved outcomes.  This happens through a focus on the discipline, values, and core principles of enterprise architecture, rather than through the naked and contextless application of the heavy frameworks.

With the enterprise architecture discipline thriving, and in some areas undergoing a resurgence, we might yet as a community of practice be able to create for ourselves those very ideal conditions under which the frameworks, too, might thrive… what are the ideal conditions for enterprise architecture to succeed?

  1. Burton, B. & Allega, P. (2012) Hype Cycle for Enterprise Architecture, 2012, Gartner Research, Article ID #G00234608
  2. Gall, N. (2012) Gartner’s 2011 Global Enterprise Architecture Survey: EA Frameworks Are Still Homemade and Hybrid, Gartner Research, Article ID #G00226400
  3. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links, http://www.elementallinks.com/2010/02/17/enterprise-architecture-in-140-characters/

Heal the Eternal Disconnect Between Project Managers and Enterprise Architects!

flexible fire loopTypical exchanges between project managers and enterprise architects have historically, anecdotally, and sterotypically been predictable, unconstructive, and unsatisfactory affairs that juggle and irritate tensions across dimensions such as:

  • enterprise context vs project scope
  • change-friendly capability delivery2 vs project delivery
  • methodological and framework differences
  • open/collaborative vs closed/secret

The nature of these exchanges has led to the creation of an eternal-looking disconnect between project managers and enterprise architects.  Flummoxed recently by a representative exchange that ran like this:

  • EA: “those requirements still need a lot of work, not least because they don’t provide the necessary coverage, and because there are mistakes throughout them”
  • PM: “no, we don’t have time to make them better, because we’ll then be behind schedule”
  • EA: “…but they’re wrong, inadequate, and embarrassing, and intended for publication externally to vendors!”
  • PM: “they were circulated to a reference group before you saw them, so, under the project charter, we’re not allowed to change them now anyway”
  • EA: “…but they’re wrong, inadequate, and embarrassing”
  • PM: “it is what it is, so just eat it! you enterprise architects are all the same, you’re all annoying, and not one of you understands what a successful project is, or how important following the correct methodology and controlling scope is to ensuring success”

…i have become certain the fundamental issue here is context.

In terms of the Zachman Framework3, the audience perspectives illustrate the context neatly, ranging from high-level whole-enterprise-and-beyond context:

  • executive = business context planners

…down to constrained appropriately-defined task-scoped context:

  • implementers = business component implementers

Traditional concerns of the project manager are all about landing something, landing anything approved by a steering group, landing an awkward three-legged contraption on the fluid trampoline of a go-live date. Traditional concerns of the enterprise architect are all about understanding how any change is incorporated into the functioning enterprise, and how to ensure that change is sustainable, able to be integrated within the business and technology bedrock of the enterprise, and consists of repeatable patterns and reusable artefacts for good, generating business value beyond the immediate at-hand implementation scenario.

The three legs of the awkward contraption are, essentially: effort, money, and time… but, just as Todd Biske outlined recently and eloquently1, the project-delivery obsession with being on-time and on-budget readily sacrifices scope, scope, the reason for and the justification of the project being commissioned in the first place.

The disconnect spans a greater distance than the relationship between project managers and enterprise architects.  The disconnect is cultural, and relies upon much better project execution, much better portfolio and programme management, and much better procurement processes.  It’s a core responsibility of the enterprise architecture profession to ensure these activities work together well, create business value, and facilitate change-friendly capability delivery.

Ultimately, the disconnect can be healed only by participants with broad-context viewpoints and strong commitment to ensure that change delivers sustainable business value. In this ecosystem, the only suitable relationship leader is enterprise architecture, enterprise architecture doing its job as advertised, and doing it well.

 

 

 

Notes:

  1. Think Enterprise First, Todd Biske: http://www.biske.com/blog/?p=878
  2. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links, http://www.elementallinks.com/2010/02/17/enterprise-architecture-in-140-characters/
  3. About The Zachman Framework at Zachman International: http://www.zachman.com/about-the-zachman-framework