Today’s Enterprise Architecture Tip – Focus on a consistent level of detail

Enterprise Architecture (EA) teams are usually partially populated with staff that have originally come from a technical IT background, and we all know what they are like don’t we? Because I am one…we love to meddle in the techy details – everything from what static code analysis tool the dev team are using and how, to version control, detailed design artifacts etc. But the key question to remind yourself of is – where should my EA team be adding the value?

It’s back to the good old ‘big rocks’ story (thanks to Mr Fernau for telling me this one several years ago).

So what is the most important thing your EA team can achieve today? For example, is it:

a) Cost avoidance – preventing a programme of work from building the wrong thing and so damaging future agility and increasing long term operational and change costs – by finding a superior alternative approach, i.e. not just saying “no”, but “that’s a really great idea, but what about this”…

b) Resolving the really frustratingly poor use of code header blocks in your offshore team’s work

A classic EA team behaviour anti-pattern is to try and work at both levels of detail – which is very frustrating for all parties involved as neither are the key EA decisions all adequately addressed (in fact they probably never can be – as that’s a “pick the right battles” issue, but that’s one for another blog post) and nor are the more detailed issues, as the EA team doesn’t have the time, control or buy-in to meddle at that level anyway.

You decide…in fact, once you’ve got all the type (a) issues under control, feel free to use the rest of your spare time of issues of type (b)

 

Notes on John Zachman’s Enterprise Architecture presentation at BCS EA specialist group meeting

As advertised in my notes from the last BCS EA specialist group event, myself and my Smart421 colleague (David Taylor, head of our internal WebSphere practice) attended this evening’s John Zachman presentation at Sun’s offices in London. I felt it was too good a chance to miss as I’ve not seen John present before – regardless of whether you agree with him or not, every self-respecting EA needs to have seen him at least once I think, and usually you have to shell out some hard-won training/conference budget to do so. I must admit I was expecting quite a hard sales pitch from him, having seen collateral for all the Zachman Framework materials and courses etc, and because he’s American …but this was not the case, and so I humbly apologise for my stereotypical assumptions.

He is a bit of a handful though – Mike Buck did his best to ‘manage’ John at the end – whilst the sandwiches outside started to curl up at the edges. As I expected he is a very engaging speaker, with some great anecdotes from his career and he spoke passionately about enterprise architecture. He kept speaking at a quite frightening rate and intensity for about 100 minutes, going 100mph and hammering home his messages using those good old speaking techniques of repetition, comedy and metaphor. I was glad I wasn’t at the front of the audience as I suspect that was a bit full-on – it’s a bit like when you go an see a stand-up comic – always best to sit a few rows back…

So what about the content? Well, he basically covered the need to enterprise architecture as a discipline and then spent the majority of the time explaining the Zachman Framework and the justification for it. So for most people in the room, I suspect they didn’t really hear anything new. It was really quite odd to hear him refer to that thing that we’ve all grown up with, the Zachman Framework, as “my framework”. There was no content about how to execute an enterprise architecture process and his viewpoint seems quite academic in nature. In his motivating way, for a moment you are led to feel that you could “model the world” – until your real world experiences kick in and you realise that this is nonsense in almost all current business environments. I must admit I feel bad criticising John Zachman in any way – it feels like complaining about your (very sharp, clever, transatlantic) grandad. To be fair to him, he didn’t try and cover the ‘delivery’ topic at all and could not of done so in the time he had. He’d be a great guy to wheel out in front of your CEO to ’sell’ the idea of enterprise architecture to them, but you also get the impression that you don’t want to be the guy following up on the expectations he might have created. He neatly side-stepped a few audience questions, but you got the impression he had the answers if not the time to give them, e.g. the classic cross-cutting concerns challenge such as ‘how is security architecture represented in the framework?’. I was quite impressed that he openly volunteered that the framework was an ontology but not a method – whilst this is obvious, I thought he might spin this towards a method of his choosing but he didn’t try that at all.

In some ways the asides, anecdotes and little historical lessons were the most riveting part of the presentation – he talked about the process by which he originally “discovered” the framework, the reasons he changed some things in version 2 of it such as renaming some of the terms to make them more business-relevant and less IT-centric, and the history of System R, DB2, IMS, business process modelling and so on. Overall I am very glad I went…I’m richer for the experience although my ears do feel like they’ve been assaulted. Another excellent and very well attended BCS EA SG event – well done committee.

 

Enterprise Architecture case studies – Notes from BCS EA specialist group meeting

As 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…

 

“Sustainable Architecture” presentation at Open Group London conference next week

As previously announced here , my colleague Richard Latham is presenting at the Open Group’s Enterprise Architecture Practitioners Conference on April 30th at 11am. The conference itself runs from 28-30th April and is located at the Central Hall Westminster, Storey’s Gate in London.

Richard will be presenting on the subject of “Sustainable Enterprise Architecture” – based upon real world experience from our recent Enterprise Architecture engagements, how to create and make EA work without undue strain on resources of money, political capital and change to an organisation’s status quo.

Here’s a summary image from his presentation to give some context…

Richard and other Smarties will be there throughout the whole event, so if you’re there grab them and say hello!

 

Six Sigma and EA viewpoints

As it’s an interest area of mine (honest!), I had a 30 minute chat with a Six Sigma black-belt colleague of mine yesterday about how EA and process improvement methods like Six Sigma fit together. His viewpoint was interesting:

• EA/BPM people tend to see things as a technology problem/a problem to be solved using technology first – and maybe jump to creating a “change programme” very early, i.e. tend to solutionize too quickly. Often when working with clients I see projects that have already been dreamt up in the business/change community, and so the “master plan” behind them all is never clear – and some projects are almost contradictory in their objectives/vision.
• On the other hand, six sigma people see things as a process problem to be measured first (set up the right metrics etc), understand where that process can be improved, and then instigate change initiatives. So once the metrics are in place, it may take 6 months before you are confident with your data that you know what to do. His example was to take the business goal “increase sales conversions from x% to y%” and then set up/capture the right metrics to understand why people don’t buy, and then (and only then) drive changes to improve it. I thought this gave the magic linkage/traceability between business vision->objectives->goal->change programmes that I rarely see in the EA world (although it is often talked about).
• His view was that the bulk of business processes in an organisation are performed by people with limited technology support. What I mean by this is that a person might deal with some post (ok – scanned and held in a CMS), decide what to do, make a phone call, check a report, escalate to their manager if necessary etc, then key the result into a system – most of the real action happens outside an IT solution. Therefore the bulk of process change and improvement options lie in the marshalling of human resources first. The “IT is just an enabler” theme was really true to him, and it occurred to me that although we say this a lot in the EA world, we don’t really mean it in the same way and with the same conviction that he does.

Even in the organisations which are reasonably mature in EA terms, it is interesting that I’ve not seen a ‘Change Process Improvement’ team having much contact with the EA team. It’s really confirmed to me that there are two camps who both believe that they should have CEO mindshare – but where neither necessarily has the full picture or skills though.

 

Smartie presenting at forthcoming Open Group London conference

I’m delighted to announce that one of my colleagues, Richard Latham, will be presenting at the Open Group’s Enterprise Architecture Practitioners Conference on April 30th at 11am. The conference itself runs from 28-30th April and is located at the Central Hall Westminster, Storey’s Gate in London.

Richard will be presenting on the subject of “Sustainable Enterprise Architecture” – based upon real world experience from our recent Enterprise Architecture engagements, how to create and make EA work without undue strain on resources of money, political capital and change to an organisation’s status quo.

We’ve been members of the Open Group for a while now so it’s good to put something back into the EA community.

 

Process Modelling and Process Oriented Organisations

I have recently been on a course about Business Process Modelling, which gave me some other perspectives of BPM and how it can be promoted and used by companies.

Prior to the course, I have used a few BPM tools to graphically represent business processes (including IBM Business Process Modeller, Oracle SOA Suite and AquaLogic BPM tools). When using those, I have felt that their use is more related to the automated execution of business processes, through BPEL and service integration capabilities. This seems to be just a technical approach, which isn’t really the solution – although that does depend on how you classify the problem to be solved.

In working with clients, and team members, I have had numerous discussions and explanations on modelling of business processes where there is no technical view involved. It is from this approach that modelling the process can help in understanding, defining and subsequently refining or improving the operations of an enterprise. In process modelling terms, this would consist of creating the Process Architecture for an organisation. From an Enterprise Architecture, this could correspond to the Business Architecture view, where the business is represented as a series of processes operating across defined value chains.

The interesting part of the BPM course I attended was not so much around the approach and methodology described for modelling, but more about the real-world experiences, cases and examples put forward by the course trainer (who does this as a real job, not just as a trainer). Many industry speakers and research analysts are promoting the benefits of process modelling and in structuring companies around process delivery and value chains, rather than in the more common functional silos and hierarchies. The examples discussed on the course seemed to put forward a strong case for this approach (as you would expect), but perhaps with more explanation. My task could now be to summarise and promote those concepts within my own company, as well as that of clients that we work with.

A parallel was frequently drawn with the way in which manufacturing has long been structured and organised around processes, with the production line of Henry Ford being one example. Also, the quality and time controls from Deming et al being another way in which that industry has rationalised and improved over time.

In contrast, the service industry is still mostly structured in functional areas, with a process crossing over many areas and responsibilities from start to finish. That is clearly inefficient. The hand-offs between teams mean that no one person or function is responsible for the process as a whole; each functional area is mostly tasked with ‘doing their job’ and not focused on the end result of the process within which they are working. This is further highlighted by the way in which company budgets are defined. These are nearly always on an area-by-area basis, not on a process-by-process. That can result in functional areas not having any strong interest in delivering value through a complete process, merely in getting their piece of work done in the quickest, easiest or cheapest way. Generally, not the behaviour that an organisation would truly wish for.

A point I would like to repeat from the course is that processes should have objectives or targets and associated measures that cover not only efficiency, but also effectiveness and adaptability. Many measures look just at basic efficiency, which is a waste if the overall process being followed is not actually effective (why optimise a part of a process to the nth degree if that part isn’t even needed in the first place). Analysing and designing processes against such measures can give an objective outcome for any recommendations, and a way to show the gains as a result. Consider also that efficiency gains through optimising process steps may gain percentage improvements, but making larger-scale changes to the overall process may result in many-fold improvements. Figures such as reducing a process from weeks to hours, those are the major gains available to companies if they do things right.

I would think that the one take-away from my views and comments above should be that organisations can definitely be improved through process re-engineering, and that business process modelling is a great approach to achieve this in a visible way. In fact, if you spend time looking at things from a BPM perspective, you would wonder how companies can look for large benefits without such modelling and associated organisation structures.

 

Enterprise Architecture and Six Sigma

Prompted by one of my EA colleagues, I’ve been reading up a bit on Six Sigma recently, and I’m surprised that I cannot find very much info on the web about the relationship between EA and Six Sigma. The best article I could find was this from Andy Blumenthal, but not much else. No real mention of any relationship to it in TOGAF 9 that I could find either.

Whilst Six Sigma has a heavy quantitative and process improvement focus to it, it is very aligned to the loftier business architecture aspects of EA and so they have very similar ambitions. I’m sure this question must have come up at various EA/Six Sigma conferences – or does this just demonstrate the IT rather than business roots of EA? All views welcome…

 

BCS Enterprise Architecture Specialist Group – Inaugural meeting

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.

 

BCS Enterprise Architecture Specialist Group inaugural meeting this week

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.