This is some notes that I took whilst watching a presentation by Erik Dörnenburg (@erikdoe), Head of Technology Europe at ThoughtWorks. The presentation is titled “What is enterprise architecture?” and gives a software engineers view of EA.
The presentation is found at: http://www.infoq.com/presentations/Questions-for-an-Enterprise-Architect
I think I spent about:
- one third of the time thinking “good point, that’s really interesting”
- one third of the time thinking “this guy is the devil / bloody software engineer / he has not clue what EA is”
- one third of the time thinking “this guy has worked with some terrible EAs.”
- one third of the time thinking “where can I learn fractions?”
The presentation i definitely worth watching because there are a lot of good examples and a lot of good points. Also I would love to know what tool they are using to show the presenter and the presentation deck at the same time. Very cool!!
The summary below is just notes of the points and where they appear in the presentation.
3-8 mins – Gives some good examples of the various models in Ross & well’s EA as strategy. just one picky point: He thinks Ross & Wiell are from Harvard Business School. Try MIT’s CISR in the School of Management
8 mins – Critiques EA metaphors ending with EA as Gardeners
15 mins – Questionably implies that all EA is a progression from software engineer rather than it being a separate discipline. This may be because he is presenting to soft are architects and he is contextualising the story.
17 mins – Good point that strategy and execution could benefit from more agile approach. But how do we manage the current generation of C-level execs to accept this idea?
18 mins – suggests that Google executed (developed Page Rank) and only later created a strategy. This is not really correct. I would say that Google had a strategy (“let’s create a cool search appliance”) that they executed and that they then evolved their strategy to achieve new outcomes (“let’s make some money”)
23 mins – Makes an interesting point about the attitude of some enterprise architects having a superior mentality and says they would benefit from seeing themselves as just another role in the enterprise team. He must have been working with some really bad EAs.
26 mins – “You get the behaviour you reward” – Amen
27 mins – Very interesting story discussing a group that is looking at the limitations of running a business through a budget cycle.
29 mins – Describes a trade-off between projects wanting to deliver on time and on budget vs operations people wanting maximum uptime and this works against change
31 mins – Conway’s law “any software you write, reflects the structure of the team.”
32 mins – Suggests that standardising on one technology (e.g. Oracle) will be reported to management as a cost saving (e.g. $10M reduction in license costs) but the “cost of the business opportunities that were missed because everyone was retraining in the new systems” is not counted or reported”
34 mins – “You shouldn’t have centralised architecture groups, you should have architects in the business units … that come together on a regular basis.”
35 – mins A good example of the benefit of EAs being present to see the consequences of architectural decisions
36 mins – He says “I have seen a 50 page document once … written by an enterprise architect” – No you haven’t. You may have been looking at a 50-page document but you weren’t looking at an enterprise architect
37 mins – very good example of disconnect between strategy and execution and a failure of perspective from the IT group
38 mins – Interesting argument about the relative risk of buying vs building
45 mins – Funny parody of the tendering process “we beat them down on price and play IBM up against HP to beat them down even further … and then they can’t deliver because they over promised, and we’re running late … but it’s all normal and that’s fine”
45 mins example of cost trade-off in running a data centre
A very good review, shared the very same sentiments when watching and was about to write a post, but yours made the idea obsolete, good job !
He has some good points but overall he is really looking through developers “viewpoint”.
Some strategies that he talks about, should also be taken with caution. Like, that 1-ring out approach, or prefer to build rather than buy, without a proper context (which tends to be very narrow btw) can prove to be very – I mean, very- harmful in every possible way.
Thanks once again for your insightful analysis.
Sidar