The pace of technology-fueled business innovation is accelerating, and enterprise architects can take a leading role by helping their firms identify opportunities for shrewd investment. In our 2012 global state of EA online survey, we asked again what the most disruptive technologies would be; here’s what we found:
The results shouldn’t surprise anybody; however, if you are only looking at these, you are likely to get smacked in the face when you blink -- things are changing that fast. In the near future, new platforms built on today’s hot technologies will create more disruption. For example, by 2016 there will be 760 million tablets in use and almost one-third will be sold to business. Forrester currently has a rich body of research on mobility and other hot technologies, such as Forrester’s mobile eBusiness playbook and the CIO’s mobile engagement playbook. But by 2018, mobile will be the norm, so then what?
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.
Out of all the inquiries I get from Forrester enterprise clients, the above question is by far the most common these days. However, the question shows that we have a lot to learn about true public cloud environments.
I know I sound like a broken record when I say this, but public clouds are not traditional hosting environments, and thus you can't just put any app that can be virtualized into the cloud and expect the same performance and resiliency. Apps in the cloud need to adapt to the cloud - not the other way around (at least not today). This means you shouldn't be thinking about what applications you can migrate to the cloud. That isn't the path to lower costs and greater flexibility. Instead, you should be thinking about how your company can best leverage cloud platforms to enable new capabilities. Then create those new capabilities as enhancements to your existing applications.
This advice should sound familiar if you have been in the IT business for more than a decade. Back in 1999 we did the same thing. As the Web was emerging, we didn't pick up our UNIX applications and move them to the web. We instead built new web capabilities and put them in front of the legacy systems (green screen scrapers, anyone?). The new web apps were built in a new way - using the LAMP stack, scaling out, and being geographically dispersed through hosting providers and content delivery networks. We learned new programming architectures, languages, and techniques for availability and performance. Cloud platforms require the same kind of thinking.
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!).
I think we would all agree that BPM and business architecture set out to overcome the issues associated with silos. And I think we would also agree that the problems associated with silos derive from functional decomposition.
While strategy development usually takes a broad, organizationwide view, so many change programs still cater to the suboptimization perspectives of individual silos. Usually, these individual change programs consist of projects that deal with the latest problem to rise to the top of the political agenda — effectively applying a band-aid to fix a broken customer-facing process or put out a fire associated with some burning platform.
Silo-based thinking is endemic to Western culture — it’s everywhere. This approach to management is very much a command-and-control mentality injected into our culture by folks like Smith, Taylor, Newton, and Descartes. Let’s face it: The world has moved on, and the network is now far more important than the hierarchy.
But guess what technique about 99.9% of us use to fix the problems associated with functional decomposition? You guessed it: yet more functional decomposition. I think Einstein had something to say about using the same techniques and expecting different results. This is a serious groupthink problem!
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.
There are many types of criminals. These include thrill-seeking hackers, politically motivated hackers, organized criminals after financial gain, and state-sponsored groups after financial gain and intellectual property or both. Any of these have the potential to break these capabilities through information loss, or denial of service. Business processes and their associated transactions need to look at information security as a key component of any architectural design we might create as Enterprise Architects.
Security architecture is dependent on the idea of “security.” Security by some definitions is the trade-off of convenience for protection. When I am unloading the car and have an armful of groceries, it's challenging to unlock the front door at the same time. Alternatively I could just leave the front door unlocked but that might invite guests I had not planned for. So I trade convenience for protection.
Security is often seen as in conflict with business users; however, security is a process that protects the business and allows it to effectively operate.
Security is in response to perceived business risks.
Security can be seen as a benefit and a business enabler and can aid organizations to achieve their business objectives.