My apologies for not getting this published as I originally intended a few weeks back, but I'd been a bit under the weather and playing catch-up ever since...
This is the first post that elaborates on the 10 factors in evaluating enterprise architecture processes that I outlined previously. As I add detail to the 10 factors that I presented, please keep the disclaimers I made at the beginning in mind as you read.
EA Process Factor 1: Is EA a distinct function in the organization? By 'distinct function,' I'm not simply examining where the EA group fits on the organization chart (even though that does have some impact). More to the matter is where the EA group is positioned within and between IT and the business such that the group achieves maximum influence and impact on both.
Here are some possible answers to this question, with commentary:
"EA is part of the IT organization, and they work very closely with IT development teams." And if they do it for the majority of their time, they might be solutions, software, or integration architects, but they aren't enterprise architects. The majority of EAs come from technical backgrounds, usually in software development. However, if they're spending most of all of their time with development and little or none to with the business, there are going to be issues with the business as that particular constituancy is not being served well, if at all.
"Our enterprise architects are part of the IT organization, but are techno-functional with respect to their duties and output." The term "techno-functional," which is another immortal piece of consultant-speak, makes my hair stand-on-end, because like the ubiquitous "best practices," the term can be used to justify anything, or nothing at all. Consider in terms of techno-functionality how much should be technical, and how much should be functional? Of course, the answer is whatever the users of the term deems it to be, or makes up as they go along.
Organizations and people who use this term expect enterprise architects to be all things to all people, at all times. EA organizations should have this capability from technical and functional standpoints, but to expect individual EAs to know everything about everything within the organization (and technology) is unrealistic. Good EA organizations have a mix of people well-versed in technology and the business, with in-depth expertise in various facets of the business and technical architecture. The synergies created and maintained in this type of EA organization is key to making the EA effort successful.
"EA is part of the IT organization, and they spend the majority of their time establishing standards and developing architectural strategy." This is the traditional "ivory tower approach," where the EA organization develops standards and architecture that no one else pays any real attention to, other than creating turf wars that waste a lot of people's time. EA groups must make decisions and create artifacts that are actionable by others, both in IT and the business. Anything else is a waste of everyone's (including the EAs) time.
"EA is a collection of individuals with broad and substantial knowledge of the business, the current IT environment, and the expected IT environment to meet strategic and tactical business goals." As I mentioned above, to expect the kind of depth EA requires from one or a very small group of individuals in large organizations is not realistic - there is just too much to learn, contemplate, and do on a daily basis. Or more likely, the solo or very-small-group EA gets pigeon-holed within technical or functional work and the other issues and artifacts are not produced or are left wanting. This doesn't mean that an EA organization has to be large - the real issue is that the varied expertise and synergies of the group are leveraged to meet the needs of the business and IT, without stinting either side.
Next up is Factor 2: Does the EA group have both functional and technical responsibilities and generate actionable outputs to both?
Enterprise Architecture is a holistic architecture environment to improve the initial stovepipe environment. Enterprise Architecture team is a distinct team to enable the holistic architecture. Enterprise Architects see the big picture, establish common foundation and provide building blocks to enable simplicity and agility to support the dynamic of business transformation.
It is not only limited to IT soultion but also business process solution. The key is Enterprise vs Stovepipe rather than IT or business as described in the following :
http://blogs.ittoolbox.com/cio/lea/archives/enterprise-architecture-vs-stovepipe-architecture-20228
EA team is part of the CIO office as shown in
http://www.e-cio.org/
For more information please read
http://www.liteea.com/lea_book.htm
Posted by: John Wu | November 07, 2007 at 06:46 AM