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:
Consider the following scenario. You have realized that your firm can benefit from having a documented business architecture – perhaps based on business capabilities – not for any one issue or need but rather as a general framework for planning, strategic execution and coordination by different parts of business and IT. You are in a meeting with your CIO, making the case, when the CIO says, “In a couple of minutes our CEO is dropping by. You can make your case to him. If he’s interested, we’ll go ahead.”
OK – that scenario may seem like kind of a stretch – after all, how often does the CEO drop in on the CIO and want to listen to a pitch on business architecture? Well, something like this happened to me recently, and I’d like your thoughts on how to make the case. I was visiting a client – the head of EA at this client (a medium-size financial services firm) – when he said, “I’ve started to lobby with our business management that we need a business capability map. The CEO is dropping by and would like to hear the reasons from you. I think you’ll have about 15 minutes.”
Talk about a challenge! When CEO arrived, after initial introductions, this is the case I made:
In developing a technology strategy for your organization, what will be your basis for deciding which technologies to pursue, when to pursue them, and how to implement them? In other words, what will be the foundation for your technology architecture and strategy? In considering this question, I assume we agree that technology strategy should directly support improvement of business outcomes, both now and over the long haul. To provide for the long haul, your technology architecture and strategy must be crafted to support a continuous stream of business change, both small incremental steps and large radical shifts.
Your strategy could begin with a list of hot technologies — perhaps even ones that business colleagues are clamoring for — but how would you know which of them would lead to the most important improvements in business outcomes? You could begin with your top executives’ current business plans and strategies — which would clearly address today’s priorities for improving outcomes — but over the long haul, business plans change, sometimes dramatically, making them an unstable foundation for technology strategy.
Since the goal of technology strategy is to improve business outcomes, let’s refine the question with that as our focus: What basis for technology architecture and strategy:
(a) Aligns best with the ways that business leaders conceive, plan, execute, and measure improvements to business outcomes,
(b) Provides the best structure for building technology implementations that align with and facilitate the ways that businesses change both now and over the long haul, and
(c) Best guides the prioritization, planning, architecture, design, and usage of technology within business improvement projects?
I recently published a sample business capability map for insurance firms as a way to illustrate many aspects about the description and use of this business architecture methodology. One of the readers of this report commented “It seems the business capability maps provide value as a complement to existing methodologies” and referenced Strategy Maps and Business Process Modeling. This made me realize that I should explain more how Forrester sees capability maps as more than a complement – and why we, along with many of our clients are so ‘jazzed up’ about this methodology.
A bit of background: Forrester views capabilities as stable elements of a business model, where the dynamics of a firm are reflected in the business goals for the capability, and the processes, functions, information and other assets which are how a capability is delivered. A capability map describes all the capabilities, and the relationships between them, which an organization needs to have as part of their business model to achieve outcomes. Think of Sales as a simple example, where there are business goals and associated metrics for Sales, and processes, functions, information and people assets necessary for this capability to be delivered. And Sales has a relationship to Fulfillment, to Customer Service and to Marketing.