No self-respecting EA professional would enter into planning discussions with business or tech management execs without a solid grasp of the technologies available to the enterprise, right? But what about the data available to the enterprise? Given the shift towards data-driven decision-making and the clear advantages from advanced analytics capabilities, architecture professionals should be coming to the planning table with not only an understanding of enterprise data, but a working knowledge of the available third-party data that could have significant impact on your approach to customer engagement or your B2B partner strategy.
Data discussions can't be simply about internal information flow, master data, and business glossaries any more. Enterprise architects, business architects, and information architects working with business execs on tech-enabled strategies need to bring third-party data know-how to their brainstorming and planning discussions. As the data economy is still in its relatively early stages and, more to the point, as organizational responsibilities for sourcing, managing, and governing third-party data are still in their formative states, it behooves architects to take the lead in understanding the data economy in some detail. By doing so, architects can help their organizations find innovative approaches to data and analytics that have direct business impact by improving the customer experience, making your partner ecosystem more effective, or finding new revenue from data-driven products.
It's becoming pretty clear that the ability to analyze data is becoming one of the most important technology-based capabilities an enterprise can have. There's a lot of hype around about big data, and it's actually well-founded hype --- if that's not a contradiction (perhaps I should call it well-founded fanfare). In any event, our world is changing as organizations gain the ability to process formerly unheard-of amounts of data with formerly unheard-of speed. New, improved information processing capabilities are significantly changing science, where scientists in labs look for patterns in data rather than dream up hypothoses and run tests to prove them right or wrong. And, in similar ways, it's changing how businesses make decisions. I've been looking for evidence that enterprises are moving on improving their information management capabilities since we started doing our "State of EA" surveys in 2009, and the 2012 data finally shows that developing or expanding information architecture is finally EA's #1 priority (well, OK, it's tied for first place with developing or expanding business architecture).
Information Architecture Is Finally A #1 EA Priority
It seems to be popular these days amongst industry pundits to recommend that organizations add a new Cxx role: the Chief Data Officer (CDO). The arguments in favor of this move are exactly what you'd think: the rapidly accelerating importance of information in the enterprise, and, as important, the heightened perception of the importance of information by business executives. The attention on information comes from all the rich new data that simply didn't exist before: sensor data from the Internet Of Things, social media, process data -- really just the enormous volume of data resulting from the digitization of everything. Add to all that: new technology to handle big data in a reasonable time frame, user-friendly mobile computing in the form of tablets, data virtualization software and data warehouse appliances that significantly accelerate the process of getting at the information for analysis, and the promise of predictive analytics, and there's plenty of cause for an information management rennaisance out there. With a little luck, the activity it catalyzes will also improve enterprises' ability to manage the data and content that's not so new but also very important that we've been struggling with for the last decade or so.
The only argument against creating this role that I've run across is that if CIOs and CTOs did their jobs right, we wouldn't need this new role. That's pretty feeble since we're not just talking about IT's history of relative ineffectiveness in managing information outside of application silos (and don't get me started about content management) -- we're adding to that a significant increase in the value of information and a significant increase in the amount of available information. And then there's the fact that the data could be in the cloud and not managed by IT, and there's also a changing picture regarding risk that suggests a new approach.
In a month or so I’ll be launching a survey to research issues around information strategy, information architecture and information management in general. I thought it might be useful to do a bit of crowdsourcing to get the best ideas for what questions to ask and make sure I’m covering your top-of-mind issues. We ask you all fairly often to provide answers to survey questions – maybe you’d like to provide input into the questions this time out?
Surveys are interesting – one is tempted to ask about everything imaginable to get good research data. But long onerous surveys produce very low percentages of completes vs. starts -- it’s classic case of less is more. Twenty completes for a very comprehensive survey is nowhere near as valuable as a couple hundred completes of a more limited survey. For example, I really wanted to provide an exhaustive list of tasks related to information management or information architecture practices and then provide an equally exhaustive list of organizational roles to get data on who does what in the typical organization and what are the patterns regarding roles and grouping of responsibilities. But the resulting question would have been torture for a respondent to go through, so I edited it down to the 15-ish responsibilities and roles you’ll see below, and I’ll probably have to reduce the number of roles further to make the question viable.
So, below are the questions I’m thinking of asking. Please use the comment area to suggest questions. I can’t promise to use them all but I can promise to consider them all and publish some of the more interesting results in this blog when they come in.
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.
Today’s organizations must manage the explosive growth of all types of information while addressing greater-than-ever business demand for insights into customer needs and the business environment. Meanwhile, the significant regulatory and compliance risk associated with information security has increased the urgency for tightly controlled information management capabilities. These requirements are hard to meet, with scant best practices available to tame the complexity that firms encounter when trying to manage their information architecture. Enterprise architects must define the organizational capabilities they need to develop and evolve their information resources — as well as the technology to exploit them. You can only achieve all this with a coherent information strategy that defines and prioritizes your needs and focuses resources on high-impact goals.
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.
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.
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.