At Unicom-EA 2013

Another week, another conference? Yes, I know it does sometimes seem a bit like that, but that’s part of what I do – getting the word out about enterprise-architecture, particularly at the larger whole-enterprise scope.

This time it was in London, for Unicom EA 2013 – one of the smaller conferences, but always worthwhile, with a nice mix of big-picture and down-to-the-roots technical.

First up was Richard Veryard, who also acted as chair for the conference. His brief presentation ‘Enterprise Architecture On Trial‘ provided a quick overview of the themes for the conference, and an introduction to some of the challenges we face in EA today. I particularly liked the medical analogy or example that he used as real-world ground for an Aristotelian ‘Four Causes’ that we can apply in assessments for our architectures:

  • Final Cause: the ‘why’, the “what’s it for?”
  • Efficient Cause: the ‘who’ and ‘how’ of process
  • Material Cause: the ‘what’, the structure
  • Formal Cause: the theory we use (of which, in many cases, there is way too much already…)

Then Harmen van den Berg, from Dutch tool-vendor Bizzdesign, who are probably the most active and respected promoters of the Archimate notation. I have a lot of respect for them too, yet I’ll have to admit that for me this was a bit of a disappointment. Partly this was because it was strictly IT-centric, without any real acknowledgement of any world beyond IT – though no surprises there, of course, given the nature of Archimate. But the real problem was that the presentation-structure was so slow: we went through the ‘this is who I am’ slide, the ‘this is my company’ slide, the ‘this is what this is about’ slide, and all of those other tedious PR-department-mandated cliches – almost a dozen of them – before getting to anything concrete at all. Sigh… Yet there was real meat there, eventually: an overview of the new Open Infrastructure Architecture repository, a free, open-source collection of design-patterns for IT-infrastructure, together with a quick tutorial on how to use these patterns in architecture-modelling. Not much use to me, unfortunately, because I just don’t do that kind of work these days; but for anyone focussing on the IT-aspects of enterprise-architectures, it looks like a very useful resource indeed.

Next up was Markus Schneider of Swiss consultancy BOC Group, who also do a toolset called ADOit. The presentation here centred around work they’d done with PostFinance, the banking arm of the Swiss Post Office. Again, this was mostly about the IT, and although well-described, for me that part of it wasn’t that much of direct interest there. What did interest me, a lot, was the focus on trust – the challenges of building and maintaining trust across all of the stakeholders. For example, there’s a strong focus on maintaining data-quality so as to maintain trust in the value of EA. One questioner from the audience asked “How did you get the people [the architecture-team] to go out into the business to keep the information up to date?” The short answer was that they didn’t: “the content-owners update it themselves through a web-client”. And, importantly, “it’s in the job-description of ‘content-owner'” – and mandated as such by senior-management. To me that’s yet another example of how crucial it is to obtain and maintain executive-level support for any enterprise-architecture initiative.

After this, the bow-tie adorned John Schlesinger, from banking-software provider Temenos. This was again an IT-architecture presentation – and almost all of it detail-layer IT-architecture at that – but one that I really enjoyed: very well done indeed. The challenge they’d faced, as he said, was to take a 30-year-old application – originally written in Pick, for those whose memories go back that far! – and bring it up to date for use with modern systems and modern interfaces. I found myself writing page after page of notes on this – far too much to describe here, unfortunately. One example was that smaller banks will ask about the functional, the features and capabilities within the software; whereas larger banks are much more concerned about the non-functional, concerns such as scaling, speed and reliability. He talked about design for differing rates of change in different parts of the software and overall system – or ‘pace-layering‘, as some people term it. He talked about design-internals: collaboration-type request/reply (two-way, and not scalable) versus fire-and-forget (one-way, and is scalable); constructing an event-store as a row-store for in-memory access, versus content-store as a column-store on (relatively slow) disk; and the need for a context-management system rather than a content-management system. One last detail was about a drag-and-drop user-interface for a banking-system in New Zealand, where bills are paid by dragging the icon for the respective bill onto the icon for an appropriate bank-account: all of the underlying transaction-details are hidden from the user. Overall, very nicely done…

And then, before lunch, the first of the two panel-sessions – which are a real feature of this conference:

— David Rose of Boardroom Associates commented on a question about the benefits of EA: it always depends on what each person sees as ‘benefit’, he said; a key metric of success is where someone else promotes and understands the same idea as their own. Also architecture is always only a means to an end: “there is no such thing as an ‘architecture project'” – only business-projects which may or may not include an architecture focus.

— Someone (I’m not sure who) commented that “retail banks are becoming online-only retailers”. If so, I think it’d be an unwise move, as many of the online-retailers are currently starting to move the other way, into having their own bricks-and-mortar stores to showcase their wares and provide a literally-tangible space for prospective buyers to explore them – somewhat on the lines of the wildly-successful Apple Stores. Too many people seem to think of this as an ‘either/or’, whereas in practice it’s more a ‘both/and’ – and each business needs to find their own balance between virtual and ‘real’, expressed as their own business-architecture.

— Richard Veryard, David Rose and Philip Hellyer of Carphone Warehouse all commented on the role of modelling in EA. David Rose said that “the acid-test for any model is, did the actual person ‘get it’ – what we were trying to communicate”, and, regarding levels of detail, that each model “should describe just enough to get the job done” – a theme I describe as ‘Just Enough Detail‘. Philip Hellyer noted that probably the key challenge there is around updating of models: we should only keep them up to date if there is a business reason to do so, otherwise mark them as ‘valid at the time but not necessarily up to date’. (See my post on ‘Models as decision-records‘ for more on that.) And Richard Veryard remarked wryly that “people are very good at creating models, but very bad at maintaining them…”.

After lunch, it was my turn. I’d been asked to do the conference at quite short notice, and had had no time to develop a new slidedeck, so I presented a slightly-simplified version of the presentation on ‘The enterprise is a story‘, that I’d originally done for Integrated-EA 2012. (The main difference was that I linked this one more strongly back to the way we use EA-toolsets, and the need for better support of story in those toolsets.) I think it went down fairly well, though I suspect a few people were somewhat unhappy that it didn’t give technical details about what to do next? Anyway, some good conversations around that during the later break, and at least one person who told me a few days later that he’d found one theme there – the importance of feelings as a core-component of strategy – to be of real and immediate value in his own EA work. I’d class that as a success, I think? 🙂

Then another real stand-out presentation, by Kai Schlüter of Danish industrial-equipment manufacturer Danfoss. This was a happily contrarian view on just about everything EA: for example, on toolsets, he insisted that the only computer-based EA-toolsets they use are Sharepoint and Excel. “We didn’t use pen and paper”, he said, “because I think it’s weak: we used a whiteboard!” – the point there being that pen-and-paper is mostly personal, whereas a whiteboard is collaborative.  For the organisation, there’s a strong emphasis on holding to the enterprise-vision, the story of the shared-enterprise: “if it’s not good for the island [where Danfoss is based], don’t do it”, used to be an explicit policy, and still strongly suffuses everything the organisation does – an insistence on integration to protect the story. On models, Kai commented that “we build it and then throw it away: we do 5% models and 95% communication, most EAs seem to do 95% models and 5% avoid communication…”. Their whole change-architecture is built around an Agile-style approach, and the productivity is startling: the SAP development-team expect a maximum turnround of no more than two hours for business-level changes, from request to fully-tested deployment. [Update: a slight unintentional-exaggeration: that two-hour turnround is for ‘only’ 85% of ‘severity one’ changes, not all business-changes – see Kai’s comment below.] In effect, the Agile-backlog is the EA-repository; “there’s no cultural resistance to Agile”, said Kai, “because I don’t tell people we’re doing it – we just do it”. Overall, a really inspiring talk.

The final main presentation was by Kevin Smith of Pragmatic EA. This was on his new framework PETF (Pragmatic Enterprise Transformation Framework), linking across the whole of the enterprise space, and providing a framework for the transformation of transformation itself within the enterprise. I’d been really looking forward to this, but unfortunately Kevin fell into the presenter’s cardinal sin of trying to pack far too much into too small a time-slot, and, in trying to force everything to fit, fell into the even worse sin of reading the whole thing from a script – an absolute classic ‘no-no’ for any presenter. Just to make it even harder, much of it was necessarily very abstract – yet the compression of everything into such a tight space meant that there was no time to let the abstractions sink in before moving straight on to the next theme. The result was a presentation that could have been much enjoyed by everyone, but instead was more like painfully endured… Oh well. Which is a real pity, because to my mind what Kevin has done with PETF is really important, a real tour-de-force that will help a lot in making EA and business-change more understandable for everyone. There’s a video version of the presentation up on YouTube: it’s well worth viewing, though it may well take several passes through it to get a real sense of what Kevin is aiming at here.

The last part of the day was another panel-session, this time including Gabriel Maties of gaming-company Gala Coral Group and Steve Nimmons of Atos Consulting. To be honest, I don’t remember much of this session, because I was on the panel myself, and didn’t have much of a chance to take many notes. The only point I did note down was in a discussion on the classic development-sequence of unconscious-incompetence to conscious-incompetence to conscious-competence to unconscious-competence, how do we tell the different between the first and last levels, since both are unconscious? The answer is get them to tell stories: someone with high competence will be able to rattle off story after story from deep real-world experience – as we’d seen throughout the conference, in fact – whereas someone who doesn’t know what they’re doing might be able to quote chapter-and-verse of theory, but no real stories from real practice. A very useful difference.

Overall, a very worthwhile conference. Along with all their other training courses and conferences, Unicom run this conference twice a year, in March and September: if you’re likely to be in London around that time of year, keep it in mind for your diary?

5 Comments on “At Unicom-EA 2013

      • Almost. I was referring to Defects, so malicious code or “cruft”. There we are truly fast in fixing (because in most cases we exactly know what we do). Business Changes can take longer, even though I still believe we are very fast. (The business sometimes prefers to have faster delivery than only daily drops into production SAP and other systems. Usually we try to deliver to that wish).

  1. Tom,

    Really like the “Models as decision-records” post – it’s a nice counter-point to the attitude that design documentation is useless since it can diverge from that which it purports to describe.

    Avoiding WITHWITH (What In The Hell Was I Thinking Here) is a source of value in itself.

  2. Great write-up Tom

    Couple minor clarifications. For the material cause, I talk about “stuff” rather than “structure”, because a lot of the structural discussion belongs to the formal cause.

    My keynote presentation is here.

    Enterprise Architecture on trial

    Secondly, the word “maintain” is ambiguous. My complaint about modellers was that they are often unwilling to make any fundamental modifications to their models, and instead put all their energies into preserving their initial thoughts, even if this results in over-complicated and unwieldy models.

Leave a Reply

Your email address will not be published. Required fields are marked *