Friday, November 16, 2007 2:24 PM
It is becoming common practice to build up the content of an Enterprise Architecture over time. Because an EA is highly dependent on feedback to grow it takes a lot of continued time and investment to constantly refine the content of an EA so it grows into being a genuinely useful and ingrained into the organisation. The best tactic is to engulf the organisation with EA overtime. It is a long game not a ‘Pot-Noodle’. Therefore a sensible approach would be to version as an effort to change control.
Versioning is the most common approach which does leave you with a dilemma, what are you going to put into version 1?
The point of version 1 is to demonstrate what an EA is and its potential to the principle stake-holders. Getting stake-holder buy-in right up front is essential. EA takes a long time and stake-holder fatigue is highly likely unless they are utterly sold which you can’t rely on.
The trick is to make version1 highly ‘stake-holder friendly’ as you want them to use what you have on their own, so make it simple and attractive. However, it is well advised to manage the expectation because the quality of version 1 will be ‘good-enough’ not gold plated as this comes with time and investment so make sure the potential is crystal clear even if the content isn’t. So amongst all of the attributes an Architect has to be have these days are the ability to be PR guru and Politian is also needed.
Forget using a document unless it’s short, you want your stake-holders to use the things you are giving them to demonstrate the EA to others unaided, yes without you being around! Yes, I know this could fill you with dread but if stakeholders are comfortable with the content they will be confident in showing others meaning you will get wider acceptance and buy-in. The problem with document is no-one reads them if they are longer than afew pages and even then they are likely to just zero-in on the content that they are interested in at that time and not read it again.
Try and use some sort of web-pages technology if you can but insure they are easy to use and navigate. Make sure the URL is easy to remember. Think about producing an EA take away, yes a gimmick, this can be a small but attractive book which has simple policy statements summaries and diagrams of common software or hardware configuration important to the organisation, lists of site and contact phone numbers stuff that just makes this thing useful. If electronic then put it on a USB key (the memory size will need to be decent) and give out a number of those. People like useful presents. Vendors know these things sell their products and this is what you will be doing to the stake-holders, selling the EA to them.
The next point is to build confidence in you, your team to deliver EA, nothing does that better than delivering, so aim to deliver something frequently and I mean at the very very least every 90 days as people are fickle so you will need to constantly remind people you are there working away slowly but surely building momentum.
So what are the actual deliverables? This depends on the focus of your stake-holders whether IT or business.
By now you should work out if you want to dip your toe into TOGAF, Zackman, Gartner or whatever EA methodology. So you would also know whether you want to follow them prescriptively or an amalgam of the best bits.
So firstly a Charter document that basically says what your goals are, the scope and how you intend to do it. There are a few examples of EA charters on the web. The one I would recommend is by Gartner but sadly you will have to be subscribed to them to download it. Don’t try and fill in each section from the template, delete the ones that don’t apply to you.
The next thing on the list is an idea of your framework, the structure of your EA, how does everything hang together? You will only need to describe this at a high-level. Don’t drown the reader in detail. Put in place-holders for the bits that are missing.
A high-level metamodel that describes how the ‘artefact’s or ‘objects’ (or whatever you want to call them) are related to each and hang together in your business. This will be the basis of your models and is essential in linking business unit and process to data and technology.
If it’s an IT sponsored EA programme (like mine) start with technology standards, since this is an area over which they have some control. Identify technology owners, take a quick inventory of what they have today and classify each technology in terms of its life cycle position (for example, prototype, preferred, supported, unsupported or decommissioned). This reasonably quick to do and is instantly useful.
Glossary of terms and technology patterns, process maps, corporate data diagram etc and all the other stuff you could add in are all nice to have’s but not essentials for a version 1. Remember the audience and the point is to only demonstrate and be good enough! Avoid anything to complex like the plague!
The best piece of advice I can give you today is do a version 0.5 and this is just a release to your peers before version 1. Your peers will tell you if you’re on the right lines or whether you suck.
Now I am conscious that will have missed out plenty and there is probably a classic gotcha so I would urge you to use the comments and tell me and I will feed that back here as this blog is as much an exercise in learning for me and sharing as anything else.