It’s not news that business user self-service for access to information and analytics is hot. What might not be as obvious is the overhaul of information-related roles that is happening now as a result. What’s driving this? The hunger for data (big, fast, and otherwise) to feed insights, very popular data visualization tools, and new but rapidly spreading technology that puts sophisticated data exploration and manipulation tools in the hands of business users.
One impact is that classic tech management functions such as data modeling and data integration are moving into business-side roles. I can’t help but be reminded of Bill Murray’s apocalyptic vision from “Ghostbusters:” “Dogs and cats, living together… mass hysteria!” Is this the end of rational, orderly data management as we know it? Haven’t central tech management organizations always seen business-side tech decision-making (and purchasing, and implementation) as “rogue” behavior that needed to be governed out of existence? If organizations have trouble now keeping data for analytics at the right level of quality in data warehouses, won’t all this introduction of new data sources and data lakes and whatnot just make things worse?
Well, my answers are “no,” “yes,” and “no” in that order. The big changes that are afoot are not the end of order and even though “business empowerment” translates to “rogue IT” in some circles, data lakes/hubs and the infusion of 3rd party data have actually been delivering on their promise of faster, better business insights for the organizations doing it right.
The data economy — or the system that provides for the exchange of digitized information for the purpose of creating insights and value — grew in 2014, but in 2015 we’ll see it leap forward significantly. It will grow from a phenomenon that mainstream enterprises view at arm’s length as interesting to one that they embrace as a part of business as usual. The number of business and technology leaders telling us that external data is important to their business strategy has been growing rapidly -- from one-third in 2012 to almost half in 2014.
Why? It’s a supply-driven phenomenon made possible by widespread digitization, mobile technology, the Internet of Things (IoT), and Hadooponomics. With countless new data sources and powerful new tools to wrest insights from their depths, organizations will scramble to use them to know their customers better and to optimize their operations beyond anything they could have done before. And while the exploding data supply will spur demand, it will also spur additional supply. Firms will be taking a hard look at their “data exhaust” and wondering if there is a market for new products and services based on their unique set of data. But in many cases, the value in the data is not that people will be willing to pay money for bulk downloads or access to raw data, but in data products that complement a firm’s existing offerings.
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.
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.
If you’re trying to build an effective EA program, you’re in trouble from the get-go. I’d like to paint a rosier picture for anyone involved in this strategic, potentially very high-impact practice, but consider the fact that one of our more frequent client inquiries is about how to communicate EA’s value to non-EAers. How can I not say you’re in trouble if so many people doing EA look for outside help to explain to their own stakeholders that what they’re doing on a daily basis is worthwhile? There’s clearly something wrong with this picture.
So, OK, let’s say you want to build an EA practice anyway, despite the poorly understood value proposition — who should you staff it with? Misguided people with a desire to labor away in obscurity? Actually, no, you want your best and brightest. Those few very smart people who know your business very well, have both deep and broad knowledge and great analytical skills, and who display the potential for strategic-, system-, and design-thinking. That's a little challenging.
And then, when you find these people and attract them to your program, how best to organize them for effectiveness? Centralizing EA resources gives you the most control and makes it more likely that EA can deliver on its strategic value proposition. Decentralizing or federating EA resources puts the architects where the action is, making it more likely business and BT stakeholders will perceive value from the effort. But then those federated resources sometimes get so involved with their local — and usually tactical — issues that they go native and they’re not really working on the “E” in EA anymore.