Enterprise architects I talk with are struggling with the pace of change in their business.
We all know the pace of change in business, and in the technology which shapes and supports our business, is accelerating. Customers are expecting more ethics from companies and also more personalized services but do not want to share private information. Technology is leveling the playing field between established firms and new competitors. The economic, social, and regulatory environment is becoming more complex.
What this means for enterprise architects is that the founding assumptions of EA — a stable, unified business strategy, a structured process for planning through execution, and a compelling rationale for EA’s target states and standards — don’t apply anymore. Some of the comments I hear:
“We’re struggling with getting new business initiatives to follow the road maps we’ve developed.”
“By the time we go through our architecture development method, things have changed and our deliverables aren’t relevant anymore.”
“We are dealing with so many changes which are not synchronized that we are forced to delay some of the most strategic initiatives and associated opportunities.”
The bottom line is that the EA methods available today don’t handle the continuous, pervasive, disruption-driven business change that is increasingly the norm in the digital business era. Our businesses need agility — our methods aren’t agile enough to keep up.
The pace of business change is accelerating. The reason why it is accelerating is the mushrooming of disruptive factors: your customers expecting anytime/everywhere access to you through their mobile devices, competitors leveraging big data technology to rapidly execute on customer-centric value propositions, and new market entrants with lean business models that enable them to outmaneuver your business.
Most companies deal poorly with disruptive change. If they are the “disruptor,” seeking to use these disruptive factors to steal market share, they often run without a plan and only after, for example, a poor mobile app customer experience, realize what they should have changed. If they are the firm being disrupted, the desire for a fast response leads to knee-jerk reactions and a thin veneer of new technology on a fossilized back-office business model.
This is where the value of business architects and business process professionals comes to play: you help your company plan and execute coherent responses to disruptive factors. That’s why your company needs you to attend Forrester’s Business Architecture & Process Forum: Embracing Digital Disruption in London on October 4 and Orlando, FL on October 18–19, 2012.
We’ll start with James McQuivey describing how technology is changing the playing field for disruption in his keynote: The Disruptor’s Handbook: How To Make The Most Of Digital Disruption.
We’ll look at how firms have used technology to rethink their operating models, eliminating low-value activities to focus on what their customers value in Craig Le Clair’s Implementing The Different In The Age Of Digital Disruption.
As the pace of change continues to accelerate in an increasingly complex business environment, organizations need to thoroughly understand how their business operates and plan the technology-fueled business transformation they'll need in the future. Establishing this understanding and enabling the transition to the future state have always been the concerns of enterprise architecture programs, and EA has emerged as a critical practice for managing an enterprise's evolution.
But EA programs have existed for more than a decade, and most of them have fallen short of these lofty goals. Why? Old-school EA has been too tactical, too technology-centric, or too disengaged from business priorities to have significant impact. Enterprises need a high-performance approach to EA that is laser-focused on driving business outcomes. To plan their future, organizations have the following alternatives:
Try to get there without a formal EA program.Enterprises that have yet to initiate an EA program — or have abandoned their effort — are operating without a coherent plan to evolve toward a clearly articulated future state. The lack of an EA program may not derail business as usual, but business change is likely to occur in a siloed, uncoordinated fashion.
Stick with the status quo EA program.Highly skilled and knowledgeable architects typically staff EA programs. But resources are typically focused on project-level activities. Strategy work is likely to be about technology road maps — not business capabilities. Isolating technology planning from business planning maintains the old-school, arms-length relationship between IT and the business.
There’s a big mistake often made with business architecture — a very big mistake, yet a very subtle mistake. As you might expect, there are a number of mistakes one might make with business architecture, but there’s a particularly big and common one that multiplies its effect through all the others.
The mistake is this: To position business architecture as a new layer on top of your existing processes and structures for EA domains such as application architecture, information architecture, and infrastructure architecture.
Here’s the issue: The traditional way many organizations have pursued EA, it should have been called “enterprise technical architecture” — ETA. The central focus has been on the likes of technical standards and reference architectures for application implementation — i.e., on the technology — and not on the enterprise itself. In a phrase, ETA is “technology-centered,” leading us to odd behaviors like assuming it’s only natural that business users, product data, customer data, and the rest will be fractured and split across multiple applications. We put applications at the center and make the business gyrate and adapt around our siloed and broken applications.
You already know it. Technology is completely pervasive in our lives, and in how businesses operate. It’s pervasive in how business execs think — they know that every change they make has a technology aspect to it. As my colleague Randy Heffner says, “It’s no longer enough to say that technology supports business. Today, your business is embodied in its technology.”
You already know it. The pace of change in our highly interconnected and interdependent world is increasing — and along with this are the opportunities and risks which change brings. From emerging markets to new social platforms such as Pinterest, business leaders are finding they can’t assume stable business models and environments anymore. Gone are the days of three-year strategic plans — the mantra now is: “How quickly can we sense and respond to new opportunities and threats? How quickly can we shift our business for these changes?”
Several recent reports on Forrester.com start with the sentence: "EA organizations often toil out of the limelight . . . " There are fewer and fewer reasons why this should be the case.
We hear fewer stories of EA teams as purely "the standards police" or with "their heads in the clouds, not producing anything useful." We hear more and more stories of EA teams changing how business and IT plan, taking the lead in application simplification and rationalization, or being the broker for innovation. Infoworld and Forrester want to recognize these success stories with the 2011 Enterprise Architecture Award.
Discover Financial created an EA repository that aggregates information from its Service Catalog, Fixed Asset, PPM, and Business Goals to provide decision-making insights that saved more than $1M of avoided costs.
Aetna used its Business Capability Map to combine more than 30 business unit strategies and road maps, highlighting common opportunities and gaps that it then used for its annual planning.
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.