BCS SouthamptonStClockAs threatened, I attended the BCS Enterprise Architecture specialist group meeting in London near Covent Garden yesterday. There were two interesting presentations regarding EA case studies, both of which caused lots of debate and questions from the gathered audience.

Amit Apte from SITA presented an anonymised case study from the airline industry. As is always a good idea, he started off with a provocation – that “enterprise architecture is boring” – and I think he was a little disappointed with the lack of reaction he got to that statement. I tend to agree to the extent that if it’s all done well, then it should be largely mechanical in nature and so rather dull. However in general this is not the case – in fact it is far too exciting! But the key thing that attracts me to EA is the ability to influence with a more significant level of impact, e.g. stopping the wrong change projects and starting the right ones, rather than operating at a solution architecture level and only influencing with a smaller scope. Maybe it’s a power thing, anyway…

He got a fair amount of stick from the audience about whether this was really an overview of an EA initiative or a one-off enterprise-wide solution architecture that had used a modified version of TOGAF v8 as a method, and the discussion centred around whether a sustainable EA function had been created or not.

Andrew Jolly from Deloitte presented an anonymised case study from the TMT (technology, media, and telecom) sector – concerning the creation of an EA governance capability in an organisation of circa 29k staff/partner staff. Some interesting things came out…

  • Both presentations mentioned something like “the business don’t need to know about EA”, i.e. a rather depressing but not unusual admission that selling the concept of EA to the business community is in the too hard pile. Andrew added to this with the sage comment that brand awareness for your EA initiative with the wider stakeholder community is key though, even if it is a meaningful acronym. Call it A.A.R.D.V.A.R.K. (I’ll leave that as an exercise for the reader to come up with) or whatever, but call it something so they can hang a label on what you are doing for them.
  • The usual general advice applied – start small to demonstrate value, winning over hearts and minds by demonstration of real value rather than selling potential future value. The good old “virtuous circle” that Smart421 (and especially Richard Latham) have been banging the drum about. I was going to ask about metrics etc but someone else got in before me – and got the answer I expected which was they set up some KPIs at the start, but eventually the qualitative measures took over, i.e. did the projects the EA function had cherry-picked to engage with ‘feel’ that they were adding sufficient value.
  • One of your selection criteria for where to start is on a project where you have influence (probably by chance, e.g. you know the project manager personally etc).
  • As a mechanism of starting to embed the idea of architects contributing to projects/programmes, Andrew’s suggestion was that you could provide a ‘free’ architect as projects will never turn away free resource. You need to ensure they are a good resource and then some benefit will naturally emerge and the project will see it, and so be more likely to ask for (and then pay for) architecture input next time round. Obviously this requires some seed funding which is non-trivial to find.
  • Even in what may appear to be an organisation that appears architecturally doomed initially, there are generally people inside the organisation who are performing a psuedo-architecture role some of their time even if they haven’t got the title and wondrous benefits package that goes with it. Otherwise how has the enterprise made it this far? Get these guys involved in some kind of virtual team as they hold the keys to your initial EA artefacts.
  • Publish EA materials early – don’t wait for perfection as you’ll never get there. Even if they’re wrong an early viewing so that they get ripped to bits (hopefully not too badly) and then improved is a good thing. Obviously they’ve got to be of a certain quality though. This point really reminded me of the practice recommended I read in a book from Guy Kawasaki about releasing new products to market early, which is completely common practice in the software industry. His quote – “Revolutionary products don’t fail because they are shipped too early; they fail because they are not revised fast enough”. Hence never buy a vs.0…
  • What was the biggest risk to the EA function that had now been established? Andrew’s view was that it was “taking our eye off the ball” and losing sight of the fact that the roadmap for the EA function itself must be maintained and pursued – just like the other roadmaps that the EA function might generate for business architecture etc.

Andrew’s parting message was an interesting one – that putting in place an EA capability is a business change project in itself and so should be treated as such, i.e. get the organisation’s “change” people involved to execute the business change.

It was good to put some faces to the names of some more of the the movers and shakers in the UK EA world – I can now point Amit, Andrew, Tom Graves and Sally Bean out of a line-up if required…

Specialist group chairman Mike Buck mentioned that the next event is a presentation by the grand-daddy of EA, a certain Mr John Zachman on October the 6th, so I expect that event to be very well attended…