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.
Can you remember a year when your business both (1) grew in a healthy way and (2) changed more slowly than the year before? Besides a company’s early startup years, such would be the exception, not the rule. So, in 2011, your business is likely to continue accelerating its pace of change. A recent Forrester report, The Top 15 Technology Trends EA Should Watch: 2011 To 2013, named both business rules and SOA policy as items for your watch list — because both of them help accelerate business change.
Back in the mainframe days — and even into minicomputer, client/server, and Web applications — nearly all of the business logic for every application was tightly wrapped up in the application code. A few forward-thinking programmers might have built separate parameter files with a small bit of business-oriented application configuration, but that was about it. But, business changes too quickly to have all of the rules locked up in the code.
Some have tried the route that businesspeople ought to do their own programming — and many vendor tools through the years have tried creatively (though unsuccessfully) to make development simple enough for that. But, business is too complex for businesspeople to do all of their own programming.
Enter business rules, SOA policy, and other ways to pull certain bits of business logic out of being buried in the code. What makes these types of approaches valuable is that they are targeted, contained, and can have appropriate life cycles built around them to allow businesspeople to change what they are qualified to change, authorized to change, and have been approved to change.
Forrester’s recent book, Empowered, describes the type of technology-based innovation by frontline employees that can cause nightmares for enterprise architects. New tools for business innovation are readily available to anyone, ranging from cloud computing and mobile apps to social networks, scripting languages, and mashups. Faced with long IT backlogs and high IT costs, frontline employees are building their own solutions to push business forward.
What worries architects is that (1) solutions built with these new tools — with little or no vetting — are being hooked to enterprise systems and data, opening potentially big risks to reliability and security, and (2) the siloed, quick-hit nature of these solutions will drive up ongoing costs of maintenance and support. Traditionally, architects use enterprise standards as their primary tool to ensure the quality, efficiency, and security of their organization’s technology base. However, when applied in the typical “lockdown” fashion, standards can stifle innovation — often because vetting a new technology takes longer than the perceived window of business opportunity.
To deal with these conflicting pressures, architects must forge a new equation between responsiveness and technology control. The business value of responsiveness, combined with the typically limited size of enterprise architecture teams, means that most organizations cannot wait for architects to vet every possible new technology. Thus, you must find ways to use architecture to navigate the tension between the business value of responsiveness and the business value of a high-quality technology base. The key is to build innovation zones into your architecture; Forrester defines these as:
At Forrester’s recent Business Process And Application Delivery Forum, there was a very interactive session on “Using The Next-Generation PMO To Promote Innovation,” led by Margo Visitacion. The premise of the session was that leading-edge PMOs (project management offices) are evolving to a more strategic role, focused on portfolio management of business investment rather than just IT projects or programs.
Many clients have suggested their PMO mission is already elevated to this level. They now focus their efforts on everything from guiding business leaders through building a business case for the investments they want to make, to guiding decision-makers through selection from the portfolio of investment proposals, to tracking benefits realization and ROI after the fact. PMOs with this kind of business-focused, strategic mission have greater business impact and are often close partners with executives leading their firm.
A funny thing happened while we in IT were focused on ITIL, data center consolidation and standardization. The business went shopping for better technology solutions. We’ve been their go-to department for technology since the mainframe days and have been doing what they asked. When they wanted higher SLAs we invested in high availability solutions. When they asked for greater flexibility we empowered them with client-server, application servers and now virtual machines. All the while they have relentlessly badgered us for lower costs and greater efficiencies. And we’ve given it to them. And until recently, they seemed satisfied. Or so we thought.
Sure, we’ve tolerated the occasional SaaS application here and there. We’ve let them bring in Macs (just not too many of them) and we’ve even supported their pesky smart phones. But each time they came running to us for assistance when the technical support need grew too great.
Ask people what makes May a noteworthy month, and many folks in the northern hemisphere will wax rhapsodic about its being the peak of springtime. Others might mention Mothers' day. Ask Forrester's IT analysts and they're pretty sure to immediately blurt out "IT Forum!" IT Forum -- the conference formerly known as GigaWorld -- is our biggest IT conference as it brings together all our IT analysts and about a zillion of our customers in all the IT-based roles for whom we do research. Each major IT role gets a separate track of research -- that's 10 tracks this year. It's essentially a week of non-stop analyst-attendee interaction in various forms. It's intense for both analysts and attendees and easily the most stimulating week on my calendar. At least, on my business calendar (wouldn't want you to think I don't have a life!).
This is not really a new blog post. It's a relatively recent post that didn't manage to make it over from my independent blog. I wanted to be sure it made it to my Forrester blog because I will have lots of publications and posts on information architecture coming up and this was a post on my first piece in this series. So here's the original post:
In January, the lead-off piece that introduces my research thread on information architecture hit our web site. It’s called Topic Overview: Information Architecture. Information architecture (IA) is a huge topic and a hugely important one, but IA is really the worst-performing domain of enterprise architecture. Sure, even fewer EA teams have a mature — or even active — business architecture practice, but somehow I’m inclined to give that domain a break. Many, if not most, organizations have just started with business architecture, and I have a feeling business architecture efforts will hit practical paydirt fairly quickly. I’m expecting to soon hear more and more stories of architects relating business strategy, goals, capabilities, and processes to application and technology strategies, tightly focusing their planning and implementation on areas of critical business value, and ultimately finding their EA programs being recognized for having new relevance, all as a result of smart initial forays into business architecture in some form.