In his new post - A Value Proposition for Enterprise Architecture - Richard Veryard discusses the role of enterprise architecture (EA).
In the case of Enterprise Architecture, there is a traditional view (EA-as-IT-planning) and an emerging view (EA-as-business-strategy). I think the question about the value proposition opens up a ... discussion about the possible evolution and potential multi-tasking of enterprise architecture teams.
According to Richard one of the key questions of value proposition is timescale. On one hand, a typical EA team’s goal is to bring a long-term value through research and development of new business and technical capabilities. The issue with this EA direction is that a business typically requires a long time to measure and realize this kind of value. On another hand, EA teams are often tasked with participation (leading) in enterprise projects in order to improve IT success ratios.
Richard points out two major problems of too closely aligning EA with projects:
The first is one of perspective. If EA is working closely with the projects, then how is the EA perspective any different from project perspective? And if the problem is that projects are doing things wrong, then how can EA fix the problem from within the project perspective? The EA view of business requirements is hardly going to be very different from that of the good business analyst on the project. If EA is no longer taking the long view, then its value proposition is largely based on the hypothesis that the architects may have a bit more knowledge and experience than the business analysts, and some slightly superior tools and techniques. ... The second difficulty is that the job of overseeing projects and ensuring project success is hugely duplicated. Within a large IT organization, we might have project management, program management, IT governance, tools and methods, quality management (control and/or assurance) as well as enterprise architecture, each with its own "body of knowledge", each trying to prevent projects from getting things wrong (and claim the credit). The word "silo" springs to mind here.
This also links with the question of who the real EA customers are:
... the CIO or CFO who have to pay for it, or the business line management and IT project managers who are being asked to spend time and effort on EA "for their own good", and are not always grateful for EA attention?
This topic is also discussed in another post of Richard - EA: Think Globally, Act locally.
He notes that there is plenty of opinions of what the role of EA should be:
- Nigel Green
I'm the 'global' if you mean Business Technology a la Forrester ... EA is about biz transformation not just IT
- Anders Østergaard Jensen
EA = S + B + T from which we can infer that EA is global
- Colin Wheeler
I think Enterprise Architecture is a logical framework in which the business can make rational decisions. Definitely part of the global focus for me.
According to Richard, the way to bring together local and global aspirations of EA was suggested by Tom Graves who quoted Patrick Geddes' slogan Think Global, Act Local
Global. IT alone is too narrow ... Lack of whole-org EA creates problems for IT. Act local (IT) think global (EA). Apply EA in detail for IT-systems etc, but always remember the global." With most of the others, Tom remains convinced about the importance of the global. "EA is architecture of enterprise, not IT - IT is just an implementation, nothing more - drop the IT-centrism!!
Richard summarizes this post by saying:
There is clearly a wide gap between AS-IS (enterprise architects frustrated within the IT department) and TO-BE (enterprise architects respected across the business). Even if we go along with Chris Potts's line that enterprise architecture should be a form of corporate strategy, there's a way to go in most organizations. Nothing wrong with thinking about the future, but some enterprise architects have got a day job as well.
The role of enterprise architects, and architects in general, keeps evolving. In the early 90s, architects’ population was small and typically included good developers, which did not want to manage people. By the end of 90s, being an architect was the most fashionable IT profession. By this time IT had (and often still has) all kinds of architects, from J2EE architects to [name your favorite product] architects to security architects. And then the notion of an Enterprise Architect - a highest ranked architect - emerged. The role definition was and is different, depending on the company, and can be anything from business strategy to technical guru. As a result there is very little clarity on the role. The question: "What is EA all about, what is the (emerging, changing) identity of EA?" still has to be answered.
