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 R&D 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 in enterprise IT projects.
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. “
Then who are the real EA customers?
“… 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? “
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!! “
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 all kinds of architects, from J2EE architects to [name your favorite product] architects to security architects. And then the Enterprise Architect – a highest ranked architect – emerged. The role definition is different, depending on the company. As a result there is very little clarity on the role.
Thus the question, “What is EA all about, what is the (emerging, changing) identity of EA?” remains.
Read the full article here: http://rvsoapbox.blogspot.com/2009/06/value-proposition-for-enterprise.html
What are your perspectives on EA? Can you answer the question above?