I say "finally" because most of the ideas for these documents were collected during the research Diego Lo Giudice and I did for Forrester's EA Forum 2010, nearly one year ago. If the ideas are quick to come, they sometimes take a long time to be realized in a document! I apologize to the customers who were waiting for the final document.
The goal of this collection of documents is to demonstrate typical EA involvement in IT governances — an area that is usually more or less "beyond" EA's scope. We also said in the EA Forum presentation that these potential involvements are not mandatory and highly depend on your particular EA objectives. EA involvement in IT governance should remain in line with the recommendation we made in Forrester report "Avoid The EA Governance Versus Agility Trap" and in which we still continue to believe: Governance is a lever to obtain nonshared (or even diverging) objectives. When objectives are shared, then governance is not required, and the approach should remain agile.
In preparation for our next EA Forum, I have been doing a lot of reflecting lately about the state of EA and what it means as we move forward into business architecture. And frankly, I don’t like what I am seeing – or more accurately, I don’t like what I am thinking. It seems to me that we are stuck in an outdated – and I will go out on a limb here and say not very successful – paradigm. So what is a paradigm? In this case I am referring to our thinking paradigm – the model in our brains that structures the way we think about EA. Our paradigms represent the “box,” as in thinking inside the box. When we are thinking outside the box, we are essentially trying to create a new paradigm – or thinking model. Paradigms are very powerful. That is why it is so difficult to think out of the box for any extended period of time. Here are the six elements that I see very consistently in the thought patterns of EAs:
Governance – Mechanisms to approve EA designs and enforce adherence to the reference architecture at the project level.
Principles – Decision filters that both EA development and application decisions flow through.
Current state – A snapshot of current issues and technology baseline (often in significant detail).
Reference architecture – The body of work describing EA’s intent, organized in a framework, expressed in strategy, standards, patterns, guidelines, etc.
Target state – An idealized future state viewpoint describing how the organization desires to change the current state based on the current understanding of technology and architecture.
Only a few weeks to go before Forrester’s US EA Forum 2011 in San Francisco in February! I’ll be presenting a number of sessions, including the opening kickoff, where I’ll paint a picture of where I see EA going in the next decade. As Alex Cullen mentioned, I’ll examine three distinct scenarios where EA rises in importance, EA crashes and burns, or EA becomes marginalized.
But the most fun I’ve had preparing for this year’s event is putting together a new track: “Key Technology Trends That Will Change Your Business.” In the past, we’ve focused this conference on the practice of EA and used our big IT Forum conference in the spring to talk about technology strategies, but this year I’ve had the opportunity to put together five sessions that drill down into the technology trends that we think will have significant impact in your environment, with a particular focus on impacting business outcomes. Herewith is a quick summary of the sessions in this track:
When I started as an architect, I was part of the team called “IT Architecture.” It was clear what we did and who we did it for – we standardized technology and designs so that IT would be more reliable, deliver business solutions more quickly, and cost less. We were an IT-centric function. Then the term “Enterprise Architecture” came in – and spurred debates as to “isn’t EA about the business?,” “what’s the right scope for EA?,” and “should EA report to the CEO?” We debated it, published books and blogs about it – but it didn’t change what most architects did; they did some flavor of IT Architecture.
Meanwhile, the interplay of business and technology changed . . . Technology became embedded and central to business results, and business leaders became technology advocates. The locus of technology innovation moved from the “heavy lifting” of core system implementations to the edges of the business, where business staff see opportunities and demand more autonomy to seize them. For enterprise architects, this means that regardless of what EA has been, in the future it must become a business-focused and embedded discipline. Mapping this shift is a key theme of Forrester’s Enterprise Architecture Forum 2011.
Gene Leganza, who will be presenting the opening keynote “EA In The Year 2020: Strategic Nexus Or Oblivion?,” states it this way:
For most of the past year or so, I have been working on a set of research docs in parallel to my inquiry and consulting work at Forrester. And the results are finally becoming available on the Forrester RoleView platform. With seven docs out in the past few weeks, this set should provide a comprehensive guide to Forrester clients setting up and running BPM programs.