ByronCookThe other night I attended the BCS Roger Needham lecture held at the Royal Society in London – this is an annual event that recognises outstanding research work in the IT world and provides a platform for the author to present. This year it was the turn of Dr Byron Cook from Microsoft Research, speaking on the subject of “Proving the programs eventually do something good”. Byron reminded me of a cross between Jarvis Cocker from Pulp and Smart421’s WebSphere practice manager, and there is a bit of the IT research pop star about him (if such a thing exists!).

My attendance was part of my strategy to follow Guy Kawasaki advice – “eat like a bird, poop like an elephant”, although I must admit that beforehand I was pretty sceptical of how useful I would find the event.

So I have to say straight off – the presentation was utterly, utterly fascinating. He was a great speaker – interesting, amusing, great anecdotes and just eccentric enough to be a convincing academic. To be honest, he is actually quite a practical academic – having produced real code solutions that solve real problems and are in use today. I found myself fished in and attracted to the idea of the purity of academic research – at least until he got started on the maths and the set theory :) . The basic message of the research papers he and his colleagues have worked on is that static analysis of code can prove that programs will eventually terminate (i.e. not hang), and that some other programs will hang under certain conditions, but that this cannot be proven for all programs. The nature of some programs means that it just cannot be proven either way. Ever. Turing worked that out years ago. But his vision is that it will be possible to increase the proportion of programs in the “we definitely know if we have a problem or not” category to a useful level, giving you a kind of automatable 100% test coverage for some programs.

So in the future, as well as just using the static code analysis tools like CheckStyle, lint, FxCop etc that we use today, we could also perform static analysis that will prove (I say again – for some programs) that they will not hang. Impressively he has already demonstrated this by finding some bugs in Windows device driver code (the size of which was up to 30k lines) which had previously gone undiscovered despite being in use in the field. Of course there are many barriers to this becoming mainstream – two of which were that it sounded like you needed pretty huge processing power (so could only be done overnight typically and maybe using a high degree of parallel computing capacity, although fortunately the algorithm does fit parallelism quite nicely) and also that the range of ‘checkable’ programs and data structures is currently quite limited, e.g. today we can handle linked lists but not tree structures.

But Byron gave me hope that static code analysis is not a ‘dead’ area and that advances are being made that can lead us to produce better software in the future. If you want to read more, have a look on the Microsoft research site.

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…

mbcs-logo

I’ll be attending the BCS EA specialist group meeting tomorrow (10th Sept 2009) at 18:00, 5 Southampton Street, London – at this meeting there will be a presentation of case studies from specialist group members focusing on the following areas:

  • Business value delivered by EA
  • Professional development for enterprise architects
  • Governance of enterprise architecture

I’m looking forward to meeting my EA peers, and I’m keen to hear different perspectives on questions such as these…

  • If the EA effort has been going for a while, are they entering the “trough of disillusionment” and how have they addressed this?
  • What was the trigger event that meant they got funding/energy for an EA initiative? New CEO? A big disaster that they were rebounding from?
  • Are they well engaged with project/programme teams?
  • Architecture and/or project governance in place? Working well?
  • Centralised or decentralised model?
  • What lessons have they learned?
  • Views on TOGAF and other frameworks?
  • Any relationship to business process improvement teams, six sigma initiatives etc?
  • Budget, team size etc
  • EA cycle times
  • Communication approach?
  • Metrics in place?

MetHotel

Last evening another colleague from Smart421 (Nathan Pinkney) and I attended this inaugural meeting of the British Computer Society Enterprise Architecture specialist group in Leeds at the Met Hotel. The evening consisted of the procedural activities required to set up a new specialist group as part of the BCS, followed by a presentation.

The procedural aspects were interesting in themselves, as I learned about the scrutiny applied to organisations who have charitable status such as the BCS, and therefore the degree of rigour required in the constitution of the group, financial controls etc. Thanks are definitely due to Mike Buck and the other committee members for getting the group to the birthing pool…

But the most interesting parts of the evening were when debates and discussions kicked off concerning various aspects of the purpose of the group, and therefore enterprise architecture in general. The diversity of the audience surprised me – the turnout was good at about 30+ people of the 280 or so BCS members who have signed up to be part of the group. The level of debate showed that there was some great minds out there, which encouraged me as I wasn’t sure what the mix of skills/experience levels was going to be like. There’s something you get from chatting to your peers across other industry sectors that you just cannot get from any other source…I talked to people with an EA interest from a military perspective, banking (they got a “boo hiss”!), trading etc. It was great!

The key discussions that came out were:

  • The dreaded definition of EA vs IT architecture – eventually we managed to move on from this once will all agreed that it wasn’t massively productive. As it is necessarily mentioned in the group’s constitution – this was bound to come up.
  • Selling the benefits of EA – there was lots of healthy debate about whether it was arrogant of people from an IT background to claim a stake in the business architecture world, and whether this was credible. For me, this debate really brought out the different perspectives of the audience, e.g. when examples were used to amplify a point, they were almost exclusively IT examples, even though most of the group were saying that IT architecture was just a subset of enterprise architecture.
  • The group was not about creating yet another EA framework, i.e. a BCSEAF – thank God for that. There’s enough of them out there – it’s the application of them and the benefits that flow from them that is key IMHO.
  • The fact that the British Computer Society was the vehicle being used to progress EA in the UK was interesting – and in general we agreed that whilst this rather laid bare the IT heritage that the EA discipline has, it was the best and most obvious vehicle we had. An interesting analogy put forward by one attendee was the journey that project management has made – i.e. from being managing IT projects, to now a broad acceptance that we manage ‘change’, and IT change is just part of a project.

The presentation at the end was by Judith Jones of Architecting the Enterprise, a TOGAF training organisation that happens to be Smart421’s preferred training provider for TOGAF. As you’d expect, the presentation was very TOGAF-centric and 50%+ a sales pitch, and didn’t really address it’s key question (“EA in the credit crunch”) – but it still provided me with a few thought provoking moments where things that I’d realised but not really crystalised in my head became clear. I’ll write about these some other time…

I’m delighted that two of my colleagues from Smart421 (Nathan Pinkney and John Rutter) have been voted in as part of the committee so that we can give this fledgling group our support. I admire their energy :) . Let’s see where we can take it.

Together with another EA colleague from Smart421, I’ll be attending the inaugural meeting of the BCS Enterprise Architecture Specialist Group this week on Wednesday in Leeds. We’ve also lined up another one of our EAs to present at a future event. I’m looking forward to meeting al the UK EA “movers and shakers” and seeing where this group goes…and it’s nice to be in at the start and see where we can all take it.

Thanks are due to Mike Buck for pulling this group together. More details are available at www.ea.bcs.org.uk.