Thursday, 21 March 2013

TOGAF Good or Bad? - Definitely Ugly!


I'm struggling with the value of TOGAF on my current assignment.

Background:


·        We have a need to develop architectural thinking up the 'food-chain' to the C-level to help inform business strategy.


·        The IT Leadership want to focus on: agility & resilience (fast response and ability to thrive under constant change), security, value-for-money and continuously improving User Experience.

·        Unusually for a private company, we are not currently focused on competition (we are a monopoly) nor inefficiency (labour cost - we rarely 'let people go').


·        We have established business-engaged governance mechanisms around Cyber Threat, however, there's cultural resistance to Western-style Governance practices and methods in other areas.


·        The IT department is mostly seen as a Cost Centre, although we are making some progress here.


·        English is the second language for the vast majority of our employees.


·        Experienced Enterprise Architects are rarer than hen's teeth in Hong Kong.


·        A few on my team have been trained and 'Certified' in TOGAF (mostly before I joined) but they have not actually practiced EA (for a wide variety of reasons) since attending the course.


Observations:


·        TOGAF is hard to comprehend for those whose 1st language is English, so it's an even greater challenge for my team.


·        TOGAF just tries too hard and ends up failing on a few counts; it's too comprehensive to be a usable framework and not specific enough to be a methodology. It's almost a philosophy, but a very incomplete and, at times, dangerously misleading one. This is very hard for my team to make sense of and I find myself having very long conversations with them where we end up agreeing that we reduce or focus on one or two of the TOGAF concepts (usually around a deliverable).

·        TOGAF doesn't seem to help very much when it comes to the challenges we face around Consumer-led IT.



·        TOGAF does encourage SOA, that would help our agility & resilience goal eventually, but we're quite a way from developing a genuine component-based, shared-services architecture due to the business organisation, culture and funding mechanisms. And we can't wait for those to change to be able meet our agility & resilience needs.


·        It’s fair to say, TOGAF training does help introduce newbies to some important EA perspectives and does help with common terms and concepts, but it requires a lot of additional buddy-work with an experienced architect to become useful and, what's worse, it conveys the wrong message; 'Enterprise Architecture is complicated and requires a high intellectual capacity to understand'. The latter being the absolute opposite of what I need to convey across IT and the business; 'Enterprise Architecture is about joining-the-dots and making things simpler to understand'.


I do continue to put my team through TOGAF Certification. Why? It's the only credible option here getting newbies up-to-speed on the basics of EA/SA and it helps my staff build their CVs (which is important). I just wish there was a better option that was both less and more:



and


  • more - on the basic mentality required of of an EA (e.g ability to abstract) and why all organizations take a different approach to architecture based on culture, maturity and business priorities.


I sometimes wonder if the authors of TOGAF are motivated to make it more understandable, or, as seems to be the case, keep it obscure and arcane. It certainly felt that way when I was exposed to IAF (Capgemini's Framework) and its zealots for the first time.

An aside here: in a recent chat with the Chief Architect in a well-known travel company, I said I needed the 80 page version of TOGAF - he laughed and responded that he'd implemented an 8 page version! BTW: all his architects are native-English speakers hired in from abroad.

5 comments:

  1. In response to Tom Graves' tweet: "@tetradian @taotwit Hi Nigel - re your TOGAF post, what do you see as needing to be written? (I edited + wrote much of the PEAF book)".

    Here's a few thoughts:
    - Accepts the predominance of TOGAF but deconstructs and explains in scenario-based narrative how it applies - starting with simple scenarios and building to more advanced
    - Focused on how to make TOGAF work rather than suggesting alternatives (although a later chapter might suggest useful extensions 
    - Practitioner interview-based (from real end user business) - capture the collective wisdom of those who have applied in anger (not a consultants PoV please!).
    - Starts with the basics - business analysis, absrtaction, component etc. etc.
    - Calls out the dangers of EA religions and emphasises what really happens with EA intiatives - what some major risks are.
    - Suggest next practice for Consumer-IT world etc. - Complex Adaptive approaches etc.
    - Uses @simplicableanna (Anna Marr - simplicable.com) as a benchmark for style and simplicity of communication.

    ReplyDelete
    Replies
    1. Following our various conversations, I'd strongly recommend the style and approach taken by Kim Parker on his 'The Knowledge Economy' blog: http://theknowledgeeconomy.wordpress.com/ .

      I think you've been in touch with him already, but if not, do. He has a lot of practical hands-on experience of real-world EA - I worked with him at AusPost - and really does know what he's talking about; yet he does also hold to the needed simplicity of 'beginner's mind'.

      The only addition there would be to link his material more strongly to the existing structure and content of TOGAF. If he's willing to do that - and I do know he wants to work on a more 'newbie-friendly' EA book - then that might give you what you need.

      Do talk with him, anyway.

      Delete
    2. Thx for the pointer Tom, will take a further look @ Kim Parker's material. Cheers N.

      Delete
  2. If you are struggling with the value of TOGAF to your current employer, I can strongly recommend a methodology called VPEC-T.

    * Value of TOGAF to various stakeholders

    * Policies embedded in TOGAF processes and deliverables

    * Events (scenario-based narrative) (business agenda and drivers)

    * Requisite variety of TOGAF to deal with content of enterprise

    * Trust - how far can you trust TOGAF to guide inexperienced staff?

    ReplyDelete