Now I have a slight problem with Sam's idea in that IT does actually mean "Information Technology" so clearly IT isn't abstracted from technology. What I think Sam was trying to say however is that EA isn't about solutions its about the general goals that IT should have within and organisation. I'll go along with that as an approach. There is a rule of thumb I've always used: Plan for a year, have a goal for 2, a target for 3 and vague fag packet stuff beyond then.
The problem is that EA is beginning to be seen as the goal in itself, so Enterprise Architects lay out the "vision" of where the organisation should get to in 5 or even 10 years time and create huge amounts of documentation in which to detail this end state. Simply put that is a massive waste of time and effort and something that will only impact in a negative way on the projects being done today.
Enterprise Architecture should never be the goal, it should aim to guide and steer and help to select the good from the bad. This should not be done against some grand IT or technology vision but should be done against the business value that elements will derive. The reality is that this will change significantly over a 5 year period, let alone more, and so any decisions that are made today on the basis of progression towards the mythical enterprise architecture are going to be an increased burden which is done to achieve something that won't happen.
Note here I'm talking about enterprise architecture. If you have a 5 year programme of work to deliver against a new business area or goal than that is fine, because that isn't an enterprise thing, its a solution thing.
Enterprise Architecture isn't a goal, in the same way as IT strategy isn't a goal, the point is that the business changes and IT needs to adapt in line with the business and someone needs to herd the cats to make things consistent. This is why the key skills in EA are not the creation of big documents that try and define some vague future but the ability to influence people and to help them reach the right choice for their current solution that also makes sure that the next thing down the line isn't going to be screwed.
Technology changes far too fast for anyone to make bold ten year plans. Back in 1997 some companies hadn't caught onto the concept of the internet, I even interviewed with an IT company back then who didn't have email that went outside the company! Anybody who attempted an Enterprise Architecture with a 10 year goal back then would almost certainly have looked like a muppet after only 3 years, and I doubt that the rate of IT development has slowed since then.
Enterprise Architecture is required, its required as an active day to day part of the operation of how IT operates, it should continually evolve and iterate the "to be" state of the IT estate in line with the demands of the business and it should never be allowed to start defining goals that sit way beyond the technology horizon of today. Enterprise Architecture is not R&D, its meant to be a practical solution to ensuring that solutions are consistent. Word documents rarely help make anything better, normally they make things worse, this means that EA has to be about active participation and direction of projects and programmes and about the people and communication skills that this requires. This also means that while EA is about the general cases and direction of IT that it must understand the technologies of today and those that will soon be arriving. Without a proper understanding of technology it is hard to see how EA can ensure that pieces are progressing as required.
Technorati Tags: SOA, Enterprise Architecture
8 comments:
Steve - Excellent post and I'm enjoying your commentary. I paraphrased part of it in my ongoing collection of EA definitions but had problems with the trackback. The post can be viewed at http://enterprisearchitect.typepad.com/ea/2007/01/the_enterprise__1.html
Keep up the good work!
Regards,
Bob McIlree
I've always viewed strategy as being a desired destination after 3-4 years (e.g. all custom systems replaced by SAP, cost reduction through outsourcing). You have to have some future vision of where you want to be, otherwise you lack context for making decisions. Individual initiatives may sometimes be large enough to provide their own context, but by and large IT shops get into a mess when multiple projects get launched without a big picture in mind. Enterprise architecture provides the context - it sets out the plan for achieving the strategy, detailed in yr 1, more vague in yr 2 etc. and needs to be revisited, as you say, on at least an annual basis. To me, a set of decent "as is" and "to be" diagrams that show processes, systems, applications, major subject areas are the key deliverables of enterprise architecture - and they should be produced and updated as part of an ongoing process rather than by a group of people in an ivory tower that never have to deliver a solution.
Do you have a view on enterprise architecture tools ? Seems to me that they are one source of the problem you outline - they appear to be getting more traction lately.
Yes. EA is a tool not a destination. It establish the common foundation and building blocks to enable simple, agile and cost efficient automation solution. Here is my defintion:
EA is the archtiecture effort which include both processes and technology design with enterprise considertion to over come the challenge of stove pipe solution. The key is to see the whole which enable enterprise wide consideration. The principle is to reuse the experience from the other without reinvent wheel. The approach is to establish common foundation and building blocks. The goal is to achieve a simple, agile and cost efficint automation solution.
For more information on the concept please visit
http://e-cio.org/lea_book.htm
OK ... so IT does mean Information Technology.
But inside organisations (except technology companies that is) 'IT' refers to the department/business-unit that exists to serve the organisation's information needs. It has to naturally imply the application of technology to the business, rather than the technology itself.
So I differentiate between IT and technology in an enterprise environment. Technology-centric strategies are a dubious activity for a non-technology company to undertake at best. It implies sandpit/fiefdom characteristics. I believe IT strategy on the other hand is totally valid, even critical. But the confusion is that people say they have the latter, when actually they have (or want) the former.
BTW: totally agree with your main point about EA being a tool rather than a destination. The worst type of EA become unapplied work-creation exercises when this gets lost.
Rather than starting from the perspective of what EA method/framework/tool you are going to use and searching for the perfect abstract definition of the semantics, I wish more start from considering the other IT processes they want architecture to play a role in, the outcomes they want to achieve, and the change programme needed for it to stick. That way the EA toolkit you need becomes almost self-evident.
Otherwise EA can just become yet another IT silo like I blogged about at http://sol1.blogspot.com/2006/10/three-content-silos-of-it-functional.html .
Regards,
Sam.
Bob, glad you are enjoying it.
Anthony, EA tools... now there is another post. Mostly I've found that they are a career in themselves rather than being anything that helps.
John, I'm almost with you but the key for me is an understanding of the technology and an iterative approach. Sure you don't want to re-invent the wheel, but that doesn't require documents to achieve. The problem is when EA starts to be complex and talk about large amounts of things, there is where it fails. EA needs to be simple and consistent, rather than deep and broad.
Sam, I agree mostly with what you are saying, but I do think that EA that doesn't understand technology is like a President of the US who doesn't understand international politics.... its just not a smart idea. 100% it shouldn't be technology centric, but in order to achieve that you must understand the technology to ensure that you aren't focused on it.... I know that sounds a bit "Zen" but when EAs don't understand technology they get rings run around them.
Yes absolutely, you can't understand the application of technology to the business if you don't understand the relevant technologies. Just like you can't if you don't understand the relevant bits of the business.
Sometimes this gets missed because it seems obvious, but it does need stating. Sometimes well intentioned people get so focused on the architecture process and the conceptual elegance that they're after that they lose focus on the outcomes. So, whilst levels of abstraction are useful to drive consistency, collaboration and traceability if you leave all the actual physical stuff to the end you end up with a kind of waterfall situation where you're running blind, wasting effort etc.
That doesn't work in IT project delivery - it's just as flawed in architecture.
I would recommend one of my articles in this regard. Enterprise Architecture Tools: What is in the Enterprise Mind?. Your valuable readership will be much appreciated.
Best Regards,
Soumen
Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment