Recording Venue:
Guest(s): Wolfgang Keller
Host(s): Alexander
Enterprise Architecture is already common practice in most Fortune 100 companies. As the topic is comparably young, knowledge about it is not so widespread in the Software Architects Community, who deals mostly with project architectures. In this episode Alex speaks with Wolfgang Keller who has practical experience as an enterprise architect and has written a book on the topic. He is a Partner with BusinessGlue Consulting. They are specializing in the relationship between EAM and SOA. This episode gives a rough overview what Enterprise Architecture actually is touches the standards in the field and also gives hints on the practical work of Enterprise Architects.
Sorry for commenting on a podcast that was put up some months ago (I tend to listen to podcasts that have immediate appeal and then go back over those I’ve missed).
Anyway, this was an interesting one particularly since it viewed Enterprise Architecture (EA) from the non technical perspective (well mostly ;-). So in that context, one of the most challenging problems facing architects (apart from being ignored and frustrated as Wolfgang mentioned), is that of ‘who pays’.
In my experience it is very common for organisations to NOT have a centralised budget which pays for what some see as the ‘overhead’ of EA activity and more tangibly the technologies that result from EA decisions (i.e. this bit of the reference model will be fulfilled by product x). More commonly an individual project manages its own costs and of course most if not all projects cannot accomodate the purchase of enterprise scale technology (I don’t mean just licences, but all of the start up costs – skills, environment, run-time support, et al), especially when they are ‘first man in’. So what happens, well … soundly researched EA decisions often don’t get implemented because no-one is willing to pick up the tab ! It all has the side effect (imho) that many architectural decisions are implicitly taken by individual project managers (often for very understandable reasons) leading to a patch-work quilt of solutions, more commonly known as the ‘accidental architecture’.
The company that I work for suffers from this problem a lot and that means lots of smart guys feel ignored and frustrated (not me, I moved out of EA when it got too much to cope with ;-). We have had some thoughts about alternate charging models, for example, one idea was to levy an ‘architetcure tax’ for each major project. That cash goes into the EA central budget and is used to fund .. well EA. The amount must not be prohibitive or unfair of course, we reckoned that it should be no more than [say] 5% of the overall project budget. We’re still thinking about that.
Do you have any suggestions for funding (assuming you don’t have a very trusting and enthuiastic board level sponsor 🙂 ??
On a related subject, this episode talked a little about the relationship between architects and business customers, principally that each can have little appreciation of the other. In many cases thats true of course although its funny that we all seem to realise it and choose not to fix it, at least most of the time. Anyway, one criticism that IT folk often make is that business customers ‘don’t know what they WANT’. Wolfgang I think suggested that IT can have a role here to help flesh out requirements and facilitate, I agree. However, in today’s very tactical world, not only is EA a difficult subject to progress (most projects in my company are not very interested in any strategic thinking), but (as was mentioned) we need to be able to deliver business solutions in an increasingly agile, quick and cheap[er] way than ever before. This got me thinking about a current ‘buzz term’ in my company and that is, IT must ensure that the business get what they NEED not necessarily what they WANT. A similar endevour is to provide SLAs that are ‘good enough’ not necessarily of a ‘gold’ standard. These changing circumstances (I admit they’re not new, we’re just in the part of the cycle where there is less cash available for non delivery specific tasks) often seem to mitigate AGAINST enterprise architecture, and make me wonder about two things, 1) should EA’s give themselves a break and go back to more exciting design and development work for a while, and [slightly] more seriously, 2) what are good ways to leave the current fund-masters in no doubt that tactical rip and replace *is* expensive and EA *can* have a lower TCO ???
Regards
Fraser.