“There’s no point being right if you can’t take everyone with you”. I heard this on the radio today from one of the contestants of The Apprentice last year. The contestant had failed to win the competition and on a number of occassions had been r…
- “Enterprise architecture as strategy” by Jeanne W. Ross, Peter Weill, David C. Robertson
- “Beautiful evidence”, Edward Tufte
- “Hope is not a strategy”, Rick Page
All the good intentions to write this blog fall apart if I keep cancelling the daily reminder to put something in. Today I was spurred back into action by someone mentioning they had started to read it (Jon you’re the spark today!) – now that’s not going to take long I thought, so time to post some more.
This all started because of a presentation at a conference last week – I’ve been asked many times since then for a reminder of the key book recommendations for further reading. Before I list them here’s a little insight into why I recommend them. Firstly, these are to my mind some of the key non-technical subjects that enterprise architects need to be proficient with. I’ll go further and say it’s subjects like these that separate the system /infomation/ technology architect from the enterprise architect role. I did say ‘some’ of the subjects and in future postings I’ll get to the rest (but you won’t find many technical entries!)
There are many postings on the internet which attempt to define the EA role, probably with as many variations as there are EA positions. I liked this as I browsed the list thrown up at www. live-com. I’m going to partially define the role by example of one of the roles the Enterprise Architect takes on-chief salesperson for the EA work. And with that definition back to the books which help the EA create the ‘sales materials’ and go about selling them.
So now I’d better justify this selection. Jeanne Ross et al do a great job with real evidence to show how to take Enterprise Architecture work to the top table and clearly show it as the IT strategy. One of my favourite mechanisms for doing just this is the creation of a one page view that links all the critical pieces together. If ever thought I would write the book on this approach I’ve given up the idea now. Just buy this one and do it. My one criticism is that the examples used are a little simple, they give all the right ideas but one fell example world be great. I speak from personal experience here- my audience at the conference wanted more real-world examples. the problem is these usually contain a lot of company details which people don’t want to shave. But having said that I’m going to try & create some generic versions now.
When it comes to putting the information on a page the master is Tufte. The 6 principles he describes in his new book should become the mantras for effective EA communication. One of his other points I’m going to throw in now comes from his thinking on the shuttle disaster. There are a number of points to draw from the analysis but the one I will highlight is that splitting information down into individual entities and then presenting them does not allow the audience to easily work out the relationships and the consequences. In EA terms the entities are necessary to have enough detail in the decomposition to fully define processes, applications, information and technology but you cannot present them independently (or even in small groups) to describe the architecture – a good description of an EA might well include business, information, application and technology all on one page linked with justifications, strategic direction, opportunity, timelines and benefits!
Hope is not a strategy is a good book out of the many that are available to describe the sales process for complex sales (responding to RFPs, developing demand etc). Why is this important to the enterprise architect? Because the architect has to sell the architecture to people in IT and importantly across the whole business. But they have competition -every sales team that turns up, well prepared, with a solution that fits the business need, regardless of how it fits with the architecture plan. So the enterprise architect needs to be a salesperson and that means having the having the materials, processes and information that sales teams work with. More on this in a future blog and also in the conference materials.
The conference papers have all been posted http://www.microsoft.com/uk/msdn/architecture/architectinsight/2007download.mspx and you can access the worksheet I used here http://download.microsoft.com/documents/uk/msdn/architecture/architectinsight/2007/Enterprise/ENT06-Creating-Core-EA-Diagrams.pdf
We find it so hard to cope with complexity in IT, that every time an evolving standard, like UML, is becoming too complex, we tend to drop it in favor of something new. The new being, because it is new, simple and understandable. While it lasts … We see this with the rising popularity of […]
This is Dries testing.