Eight to Late

Sensemaking and Analytics for Organizations

TOGAF or not TOGAF… but is that the question?

with 6 comments

The ‘Holy Grail’ of effective collaboration is creating shared understanding, which is a precursor to shared commitment.” – Jeff Conklin.

Without context, words and actions have no meaning at all.” – Gregory Bateson.

I spent much of last week attending a class on the TOGAF Enterprise Architecture (EA) framework.  Prior experience with  IT frameworks such as PMBOK and ITIL had taught me that much depends on the instructor – a good one can make the material come alive whereas a not-so-good one can make it an experience akin to watching grass grow. I needn’t have worried: the instructor was superb, and my classmates, all of whom are experienced IT professionals / architects, livened up the proceedings through comments and discussions both in class and outside it. All in all, it was a thoroughly enjoyable and educative experience, something I cannot say for many of the professional courses I have attended.

One of the things about that struck me about TOGAF is the way in which the components of the framework hang together to make a coherent whole (see the introductory chapter of the framework for an overview). To be sure, there is a lot of detail within those components, but there is a certain abstract elegance – dare I say, beauty – to the framework.

That said TOGAF is (almost) entirely silent on the following question which I addressed in a post late last year:

Why is Enterprise Architecture so hard to get right?

Many answers have been offered. Here are some, extracted from articles published by IT vendors and consultancies:

  • Lack of sponsorship
  • Not engaging the business
  • Inadequate communication
  • Insensitivity to culture / policing mentality
  • Clinging to a particular tool or framework
  • Building an ivory tower
  • Wrong choice of architect

(Note: the above points are taken from this article and this one)

It is interesting that the first four issues listed are related to the fact that different stakeholders in an organization have vastly different perspectives on what an enterprise architecture initiative should achieve.  This lack of shared understanding is what makes enterprise architecture a socially complex problem rather than a technically difficult one. As Jeff Conklin points out in this article, problems that are technically complex will usually have a solution that will be acceptable to all stakeholders, whereas socially complex problems will not.  Sending a spacecraft to Mars is an example of the former whereas an organization-wide ERP  (or EA!) project or (on a global scale) climate change are instances of the latter.

Interestingly, even the fifth and sixth points in the list above – framework dogma and retreating to an ivory tower – are usually consequences of the inability to manage social complexity. Indeed, that is precisely the point made in the final item in the list: enterprise architects are usually selected for their technical skills rather than their ability to deal with ambiguities that are characteristic of social complexity.

TOGAF offers enterprise architects a wealth of tools to manage technical complexity. These need to be complemented by a suite of techniques to reconcile worldviews of different stakeholder groups.  Some examples of such techniques are Soft Systems Methodology, Polarity Management, and Dialogue Mapping. I won’t go into details of these here, but if you’re interested, please have a look at my posts entitled, The Approach – a dialogue mapping story and The dilemmas of enterprise IT for brief introductions to the latter two techniques via IT-based examples.

<Advertisement > Better yet, you could check out Chapter 9 of my book for a crash course on Soft Systems Methodology and Polarity Management and Dialogue Mapping, and the chapters thereafter for a deep dive into Dialogue Mapping </Advertisement>.

Apart from social complexity, there is the problem of context – the circumstances that shape the unique culture and features of an organization.  As I mentioned in my introductory remarks, the framework is abstract – it applies to an ideal organization in which things can be done by the book. But such an organization does not exist!  Aside from unique people-related and political issues, all organisations have their own quirks and unique features that distinguish them from other organisations, even within the same domain. Despite superficial resemblances, no two pharmaceutical companies are alike. Indeed, the differences are the whole point because they are what make a particular organization what it is. To paraphrase the words of the anthropologist, Gregory Bateson, the differences are what make a difference.

Some may argue that the framework acknowledges this and encourages, even exhorts, people to tailor the framework to their needs. Sure, the word “tailor” and its variants appear almost 700 times in the version 9.1 of the standard but, once again, there is no advice offered on how this tailoring should be done.  And one can well understand why: it is impossible to offer any sensible advice if one doesn’t know the specifics of the organization, which includes its context.

On a related note, the TOGAF framework acknowledges that there is a hierarchy of architectures ranging from the general (foundation) to the specific (organization). However despite the acknowledgement of diversity,   in practice TOGAF tends to focus on similarities between organisations. Most of the prescribed building blocks and processes are based on assumed commonalities between the structures and processes in different organisations.   My point is that, although similarities are important, architects need to focus on differences. These could be differences between the organization they are working in and the TOGAF ideal, or even between their current organization and others that they have worked with in the past (and this is where experience comes in really handy). Cataloguing and understanding these unique features –  the differences that make a difference – draws attention to precisely those issues that can cause heartburn and sleepless nights later.

I have often heard arguments along the lines of “80% of what we do follows a standard process, so it should be easy for us to standardize on a framework.” These are famous last words, because some of the 20% that is different is what makes your organization unique, and is therefore worthy of attention. You might as well accept this upfront so that you get a realistic picture of the challenges early in the game.

To sum up, frameworks like TOGAF are abstractions based on an ideal organization; they gloss over social complexity and the unique context of individual organisations.  So, questions such as the one posed in the title of this post are akin to the pseudo-choice between Coke and Pepsi, for the real issue is something else altogether. As Tom Graves tells us in his wonderful blog and book, the enterprise is a story rather than a structure, and its architecture an ongoing sociotechnical drama.

Written by K

March 17, 2015 at 8:09 pm

6 Responses

Subscribe to comments with RSS.

  1. […] TOGAF or not TOGAF… but is that the question? […]

    Like

  2. I took the TOGAF course recently too. As well, I was fortunate to have a very good instructor and a well-composed group of classmates, as if by magic. In the end, our sharing of stories in the class will stay with me much longer than the framework. I would do a business solutions storytelling class (can’t think of a better name for it) in an instant. If you ever hear of one, or decide to teach one, please let me know, Kailash.

    Liked by 1 person

    Phil

    March 18, 2015 at 1:14 am

    • Hi Phil,

      Thanks for taking the time to read and comment. Business solutions storytelling – what a great idea! Something to think about…

      Regards,

      Kailash.

      Like

      K

      March 18, 2015 at 8:03 am

  3. Kailash

    Thank you for this succinct account of some principal mis-perceptions that now get in the way of the development of project management practice.
    Conducting the management of a project takes the form of an expedition to discover; enabled by a robust PM framework (methodology) and the work of a network of socially connected players who serve interests, engage, problem-solve and enable collaboration. It is they, individually and collectively, that make the choices that result in progress or otherwise. Prevailing perceptions of PM are usually flawed as they are derived and constrained from a ‘base’ that is a methodology or framework. This base is a discipline and never the starting point or the source of direction taken by a project management enterprise. That is essentially down to the choices made by the sponsors and players; expressed through their human and organisational behaviour.

    Human and organisational behaviour is too often Taken for Granted by practitioners. My own experience is that in the many sectors of PM where I have worked, the most pre-eminent players and organisations are diligent in this regard. They are vital aspects of their working practice: seen to be crucial to achieving successful outcomes and to obviating failure. Elsewhere they are however often disregarded, awkwardly exercised or otherwise ineffectual, resulting in missed opportunity, disruption, other difficulties and too often failure.

    Conversely, success always depends on human and organisational behaviours being skilfully deployed. In the management of projects today they need to be recognised as CSFs (e.g. Adaptation; Dialogue; Connection; Social Engagement; Collaboration; Leadership; Persistence; Agility; Ethos; Personal Ability; Resilience; Resolve; Impetus; Political skill; Pacing; etc.). The PM community should do more for itself to improve the conduct of practitioners and their organisation. Behaviours need to be valued, clarified, developed, refined and habituated; otherwise a project’s and performance and development will be confined. These behaviours occur as the origin of every project choice and activity. They determine the efficacy of every endeavour and are surely the principal source of success and failure.

    Like

    Martin Price

    March 20, 2015 at 6:25 am

  4. […] TOGAF or not TOGAF… but is that the question? […]

    Like

  5. […] of enterprise architecture – the first article is about EA in general and the other about the TOGAF framework. If you have a quick skim through, you’ll see that they have a fair bit in […]

    Like


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: