The use of road maps to illustrate technology plans is fairly widespread. Whether it's a vendor explaining its product plans or a technology architect showing the evolution of a particular area of the infrastructure, road maps are great for communicating what happens when. And when plans as illustrated by the road map get sign-off, they can become a useful tool in change management as well. Someone wants your key resources for a special project? Fine, but all the dates on that road map they just approved just shifted six months to the right. Road maps tell the story of what to expect an organization to accomplish for the foreseeable future, and that's what makes them powerful.
That's why road maps that link traditionally difficult-to-explain areas of technology, such as those related to information management, to specific and highly desirable business outcomes can be a major win for architects looking to communicate what they're doing and why. There's always been a Catch-22 about explaining the value of complex technologies to audiences with no appetite for technical complexity -- but with needed sign-off authority for key resources (like funding). If the EA team has credibility (OK, that can be a big "if"), just showing the interrelationships between business outcomes, business capabilities, IT projects, and required activities in the various EA domains can satisfy the need for "explaining" that complex technology. Or for explaining the need for that not-well-understood architecture process that requires business involvement, such as information architecture development or governance.
In Forrester’s EA Practice Playbook, we describe high-performance enterprise architecture programs as “business-focused, strategic, and pragmatic.” They are business-focused so that the direction and guidance EA provides has clear business relevance and value. They are strategic because the greatest value EA brings is to help its business to achieve its business strategies. They are pragmatic because, well, the path to strategy is never straight, and EA teams who aren’t agile in their approach get pushed aside.
National Grid, facing the enormous changes to the utility industry, developed an enterprisewide business capability model and made that the center of their joint business-IS planning. The result? All the way up to the C-level, EA is being recognized as a strategic change agent.
Scottish Widows Investment Partnership “reinvented” their EA program, centered on a business capability model developed over four weeks, and used to organize and link all the EA portfolios. They now have business managers as well as EA using their architecture planning tool.
I recently finished reading Moneyball, the Michael Lewis bestseller and slightly above-average Hollywood movie. It struck me how great baseball minds could be so off in their focus on the right metrics to win baseball games. And by now you know the story — paying too much for high batting averages with insufficient focus where it counts —metrics that correlate with scoring runs, like on-base percentage. Not nearly as dramatic — but business is having its own “Moneyball” experience with way too much focus on traditional metrics like productivity and quality and not enough on customer experience and, most importantly, agility.
Agility is the ability to execute change without sacrificing customer experience, quality, and productivity and is “the” struggle for mature enterprises and what makes them most vulnerable to digital disruption. Enterprises routinely cite the incredible length of time to get almost any change made. I’ve worked at large companies and it’s just assumed that things move slowly, bureaucratically, and inefficiently. But why do so many just accept this? For one thing, poor agility undermines the value of other collected BPM metrics. Strong customer experience metrics are useless if you can’t respond to them in a timely manner, and so is enhanced productivity if it only results in producing out-of-date products or services faster.
George Colony, our CEO, just released a post on his blog about enterprise architecture, aptly enough named “Enterprise Architects For Dummies (CEOs).” I retweeted the post to my followers and received a flood of responses, most of which were violently disagreeing with George’s assertion that EA works for the CIO. I think this is a pointless argument, but underscores a very important change that most are missing.
Here’s what I mean:
The objection to putting EA under the CIO is based on an old-school notion.That notion is that CIOs are chief technology infrastructure managers. Our data shows that the role of CIO is changing, fueled by cloud and other as-a-service technology. CTOs or VPs of IT are increasingly taking on the job we used to think of as the CIO, while progressive CIOs are evolving to something else. Locating EA under the CTO is a bad idea, we all agree.
Every business is a digital business.If you don’t believe me, I’ll send you a pile of research. There is no such thing as a non-information-centric business anymore — or at least there won’t be for very long, because they are going out of business. Forrester has been using the term “business technology” (BT) for a while to indicate that there is no room for having separate business and IT — it simply won’t work much longer. Even in the most paper, analog verticals, we can give you example after example; check out Monsanto’s IFS (they are a seed company!).
In our Forrsights Business Decision-Makers Survey, Q4 2011, we asked business technology leaders to rate IT’s ability to establish an architecture that can accommodate changes to business strategy. While 45% of IT rated its ability positively, only 30% of business respondents did. Clearly, both think there is room for improvement, but business is more concerned about it.
So are we agile? Only 21% of enterprise architects in our September 2011 Global State Of Enterprise Architecture Online Survey reported being even modestly agile, so I think we all know the answer.
What do we do about it? Continue to focus on technology standardization and cost reduction? Give up on that and focus on tactical business needs? Gridlock in the middle because we can’t make the business case to invest in agility? This is the struggle EA organizations face today.
To act with agility, firms must create a foundation for it, and three barriers can get in the way:
Brittle processes and legacy systems. We all know it this one; the current state mess of processes that cannot adapt to change and legacy systems where everything is connected to everything else, so even the smallest changes have broad impacts. Techniques to overcome this barrier include partitioning the problem into digestible pieces to show incremental progress and short-term payoff.
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.
Several recent Forrester reports home in on what we call “The Age Of The Customer” in which firms must seek to become customer-obsessed to build differentiation and loyalty. Those firms that embrace this will ramp up investment in four priority areas: 1) real-time customer intelligence; 2) customer experience and customer service; 3) sales channels that deliver customer intelligence; and 4) useful content and interactive marketing. All these needs are technology-infused – wholly dependent on technology and in categories where technology is evolving rapidly. Underlying these investments is the need to master the flow of data about customers: capturing/collecting data about them, analyzing it, distributing to those points of engagement, and, finally, integrating the insights into the customer experience.
Companies can’t succeed at doing this without a close partnership between the business areas leading the charge and IT. The rate of change of your customers, markets, business opportunities, and technology is simply too fast. Forrester is exploring this theme in our first CIO/CMO joint forum.
The reality, though, is companies flounder at this marketing-IT partnership. They flounder because of:
More ideas than capacity. A plethora of desired initiatives are constantly being surfaced – beyond the limits of available budget and with no mechanism to sort them into an achievable plan that IT can deliver on.
Just attended a Big Data symposium courtesy of IBM and thought I’d share a few insights, as probably many of you have heard the term but are not sure what it means to you.
No. 1: Big Data is about looking out of the front window when you drive, not the rearview mirror. What do I mean? The typical decision-making process goes something like this: capture some data, integrate it together, analyze the clean and integrated data, make some decisions, execute. By the time you decide and execute, the data may be too old and have cost you too much. It’s a bit like driving by looking out of your rearview mirror.
Big Data changes this paradigm by allowing you to iteratively sift through data at extreme scale in the wild and draw insights closer to real time. This is a very good thing, and companies that do it well will beat those that don’t.
No. 2: Big is not just big volume. The term “Big Data” is a misnomer and it is causing some confusion. Several of us here at Forrester have been saying for a while that it is about the four “V’s" of data at extreme scale - volume, velocity, variety and variability. I was relieved when IBM came up with three of them; variability being the one they left out.
Some of the most interesting examples we discussed centered on the last 3 V’s – we heard from a researcher who is collecting data on vital signs from prenatal babies and correlating changes in heart rates with early signs of infection. According to her, they collect 90 million data points per patient per day! What do you do with that stream of information? How do you use it to save lives? It is a Big Data Problem.
Greetings — thanks for taking the time to read my inaugural blog! Let me introduce myself by way of continuing a discussion that I started at Practicing EA and CIO.com on innovation and technology that I think strikes at the heart of our challenges as enterprise architects. It also provides a good context for my future research, which I discuss at the end.
Closing The Innovation Gap
In part 1 of this post, I claim that a gap opened while we were fighting the overly complex, expensive current state and trying to help our business partners innovate with new technology.
The gap – We cannot deliver new technology and innovation quickly or cheaply enough.
Shadow IT Is The Symptom, Not The Cause
The Symptom – We often blame Shadow IT and manual workarounds for increases in complexity, reduction in quality of service, and obscuring true technology costs. These are symptoms of the problem, not the problem itself.
The Cause – Business users know more about what they need and when they need it and are the most motivated to solve their problems now, not once the budget cycle gets around to funding a project. Central IT, where most EAs practice, is a knowledge store for designing enterprise-scale systems but is constrained in its ability to deliver.
Step back and think: How would you answer the question, “What does your IT group deliver to your business?” Your answer will indicate how you think about the relationship between business and technology, and, in turn, it will affect your business agility and your business-IT alignment.
If you answer anything close to “IT delivers and integrates solutions to meet business requirements,” your mental model boils down to thinking that your solutions support the business: Business is one thing; solutions are a separate thing. If the business has a problem, let it come ask IT for some application to address the problem — maybe IT will even help the business figure out what it needs. Each application supports (typically overlapping) parts of the business, and IT performs whatever behind-the-scenes integration is necessary to gain some degree of coherency across the whole. The result is the sort of siloed spaghetti application mess that most organizations are dealing with — even if SOA and BPM and the rest make it easier to deal with.