What Experts Say about Enterprise Search: Content, Interface Design and User Needs

This recap might have the ring of an old news story but these clips are worth repeating until more enterprises get serious about making search work for them, instead of allowing search to become an expensive venture in frustration. Enterprise Search Europe, May 14-16, 2013, was a small meeting with a large punch. My only regret is that the audience did not include enough business and content managers. I can only imagine that the predominant audience members, IT folks, are frustrated that the people whose support they need for search to succeed were not in attendance to hear the messages.

Here are just a few of the key points that business managers and those who “own” search budgets need to hear.

On Day 1 I attended a workshop presented by Tony Russell-Rose [Managing Director, UXLabs and co-author of Designing the Search Experience, also at City University London], Search Interface Design. While many experts talk about the two top priorities for search success, recall (all relevant results returned) and precision (all results returned are relevant), they usually fail to acknowledge a hard truth. We all want “the whole truth and nothing but the truth,” but as Tony pointed out, we can’t have both. He went on to offer this general guidance on the subject; recall in highly regulated or risk intensive business is most important but in e-commerce we tend to favor precision. I would add that in enterprises that have to manage risk and sell products, there is a place for two types of search where priorities vary depending on the business purpose. My takeaway: universal, all-in-one search implementations across an enterprise will leave most users disappointed. It’s time to acknowledge the need for different types of implementations, depending on need and audience.

Ed Dale [Digital Platforms Product Manager, Ernst & Young (USA)] gave a highly pragmatic keynote at the meeting opening, The Six Drivers for Search Quality. The overarching theme was that search rests on content. He went on to describe the Ernst & Young drivers: the right content, optimized for search, constant tuning for optimal results, attention to a user interface that is effective for a user-type, attention to user needs, consistency in function and design. Ed closed with this guidance: develop your own business drivers based on issues that are important to users. Based on these and the company’s drivers, focus your efforts, remembering that you are not your users.

The Language of Discovery: A Toolkit for Designing Big Data Interfaces and Interactions was presented by Joseph Lamantia, [UX Lead: Discovery Products and Services, Oracle Endeca]. He shared the idea that discovery is the ability to understand data, and the importance of not treating data, by itself, as having value without achieving discovery. Discovery was defined as something you have seen, found, and made sense of in order to derive insight. It is achieved by grasping or understanding meaning and significance. What I found most interesting was the discussion of modes of searching that have grown out of a number of research efforts. Begin with slide 44, “Mediated Sense making” to learn the precursors that lead into his “modes” description. When considering search for the needy user, this discussion is especially important. We all discover and learn in different ways and the “mode” topic highlights the multitude of options to contemplate. [NOTE: Don’t overlook Joe’s commentary that accompanies the slides at the bottom of the SlideShare.]

Joe was followed by Tyler Tate, [Cofounder, TwigKit] on Information Wayfinding: A New Era of Discovery. He asked the audience to consider this question, “Are you facilitating the end-user throughout all stages of the information seeking process?” The stages are: initiation > selection > exploration > formulation > collection > action. This is a key point for those most involved in user interface design and content managers thinking about facet vocabulary and sorting results.

Steve Arnold [Arnold IT], always brings a “call to reality” aspect to his presentations and Big Data vs. Search was no different. On “Big Data” a couple of key points stick out, “More Data” is not just more data; it is different. As soon as we begin trying to “manage” it we have to apply methods and technologies to reduce it to dimensions that search systems can deal with. Search data processing has changed very little for the last 50 years and processing constraints limit indexing capabilities across these super large sets. There are great opportunities for creating management tools (e.g. analytics) for big data in order to optimize search algorithms, and make the systems more affordable and usable. Among Arnold’s observations was the incessant push to eliminate humans, getting away from techniques and methods [to enhance content] that work and replacing them with technology. He noted that all the camera and surveillance systems in Boston did not work to stop the Marathon bombers but people in the situation did limit casualties through quick medical intervention and providing descriptions of suspicious people who turned out to be the principal suspects. People must still be closely involved for search to succeed, regardless of the technology.

SharePoint lurks in every session at information technology conferences and this meeting was no exception. Although I was not in the room to hear the presentation, I found these slides from Agnes Molnar [International SharePoint Consultant, ECM & Search Expert, MVP] Search Based Applications with SharePoint 2013 to be among the most direct and succinct explanation of when SharePoint makes sense. It nicely explains where SharePoint fits in the enterprise search eco-landscape. Thanks to Agnes for the clarity of her presentation.

A rapid fire panel on “Trends and Opportunities” moderated by Allen Peltz-Sharpe [Research Director for Content Management & Collaboration, 451 Research] included Charlie Hull [Founder of Flax], Dan Lee of Artirix, Kristian Norling of Findwise (see Findwise survey results), Eric Pugh of OpenSource Connections and Rene Kreigler an independent search consultant. Among the key points offered by the panelists were:

  • There is a lot to accomplish to make enterprise search work after installing the search engine. When it comes to implementation and tuning there are often significant gaps in products and available tools to make search work well with other technologies.
  • Search can be leveraged to find signals of what is needed to improve the search experience.
  • Search as an enterprise application is “not sexy” and does not inspire business managers to support it enthusiastically. Its potential value and sustainability is not well understood, so managers do not view it as something that will increase their own importance.
  • Open source adoption is growing but does face challenges. VC backed companies in that arena will have a struggle to generate enough revenue to make VCs happy. The committer community is dominated by a single firm and that may weaken the staying power of other search (Lucene, Solr) open source committers.

A presentation late in the program by Kara Pernice, Managing Director of NN/g, Nielsen Norman Group, positioned the design of an intranet as a key element in making search compelling. Her insights reflect two decades of “Eyetracking Web Usability” done with Jakob Nielsen, and how that research applies for an intranet. Intranet Search Usability was the theme and Kara’s observations were keenly relevant to the audience.

Not the least of my three days at the meeting were side discussions with Valentin Richter CEO of Raytion, Iain Fletcher of Search Technologies, Martin Rugfelt of Expertmaker, Benoit Leclerc of Coveo, and Steve Andrews an advisor to Q-Sensei. These contributed many ideas on the state of enterprise search. I left the meeting with the overarching sense that enterprise leadership needs to be sold on the benefits for sustaining a search team as part of the information ecosystem. Bringing an understanding of search as not just being a technological, plug & play product and a “one-off” project is the challenge. Messaging is not getting through effectively. We need strong and clear business voices to make the case; the signals are too diffuse and that makes them weak. My take is that messages from search vendors all have valid points-of-view but when they are combined with too many other topics (e.g. “big data,” “analytics,” “open source,” SharePoint, “cloud computing”) basic concepts of what search is and where it belongs in the enterprise gets lost.

What big companies are doing with big data today

The Economist has been running a conference largely focused on Big Data for three years. I wasn’t able to make it this year, but the program looks like it is still an excellent event for executives to get their hands around the strategic value, and the reality, of existing big data initiatives from a trusted source. Last month’s conference, The Economist’s Ideas Economy: Information Forum 2013, included an 11 minute introduction to a panel on what large companies are currently doing and on how boardrooms are looking at big data today that is almost perfect for circulating to c-suites. The presenter is Paul Barth, managing partner at NewVantage Partners.

Thanks to Gil Press for pointing to the video on his What’s The Big Data? blog.

The Analyst’s Lament: Big Data Hype Obscures Data Management Problems in the Enterprise

I’ve been a market and product analyst for large companies. I realize that my experiences are a sample of one, and that I can’t speak for my analyst peers. But I suspect some of them would nod in recognition when I say that in those roles, I spent only a fraction of my time in these analyst roles actually conducting data analysis.  With the increase in press that Big Data has received, I started seeing a major gap between what I was reading about enterprise data trends, and my actual experiences working with enterprise data.

A more accurate description of what I spent large amounts of time doing was data hunting. And data gathering, and data cleaning, and data organizing, and data checking.  I spent many hours trying to find the right people in various departments who “owned” different data sources. I then had to get locate definitions (if they existed – this was hit or miss) and find out what quirks the data had so I could clean it without losing records (for example, which of the many data fields with the word “revenue” in it would actually give me revenue). In several cases I found myself begging fellow overworked colleagues to please, please, pull the data I needed from that database which I in theory should have had access to but was shut out of due to multiple layers of bureaucracy and overall cluelessness as to what data lived where within the organization.

Part of me thought, “Well, this is the lot of an analyst in a large company. It is the job.” And this was confirmed by other more senior managers – all on the business side, not in the IT side – who asserted that, yes, being a data hunter/gatherer/cleaner/organizer/checker was indeed my job. But another part of me was thinking, “These are all necessary tasks in dealing with data. I will always need to clean data no matter what. I will need to do some formatting and re-checking to make sure what I have is correct. But should this be taking up such a large chunk of my time? This is not the best way I can add value here. There are too many business questions I could potentially be trying to help solve; there has got to be a better way.”

So initially I thought, not being an IT professional, that this was an issue of not having the right IT tools. But gradually I came to understand that technology was not the problem. More often than not, I had access to best-in-class CRM systems, database and analytics software, and collaboration tools at my disposal. I had the latest versions of Microsoft Office and a laptop or desktop with decent processing power. I had reliable VPN connectivity when I was working remotely and often a company-supplied mobile smartphone. It was the processes and people that were the biggest barriers to getting the information I needed in order to provide fact-based research that could be used to solve business-critical decisions.

Out of sheer frustration, I started doing some research to see if there was indeed a better way for enterprises to manage their data. Master Data Management (MDM), you’ve been around for over a decade, why haven’t I ever encountered you?  A firm called the Information Difference, a UK-based consultancy which specializes in MDM, argues that too often, decisions about data management and data governance are left solely to the IT department. The business should also be part of any MDM project, and the governance process should be sponsored and led by C-level business management. Talk about “aha” moments.  When I read this, I actually breathed a sigh of relief. It isn’t just me that thinks there has to be a better way to go, so that the not-cheap business and market analysts that enterprises the world over employ can actually spend more of their time solving problems and less time data wrangling!

That’s why when I read the umpteenth article/blog post/tweet about how transformative Big Data is and will be, I cannot help but groan.  Before enterprises begin to think about new ways about structuring and distributing data, they need to do an audit of how existing data is already used within and between different businesses.  In particular, they should consider MDM if that has not already been implemented. There is so much valuable data that already exists in the enterprise, but the business and IT have to actually work together to deploy and communicate about data initiatives. They also need to evaluate if and how enterprise data is being used effectively for business decisions, and if that usage meets compliance and security rules.

I suspect that many senior IT managers know this and agree. I also suspect that getting counterparts in the business to be active and own decisions about enterprise data, and not just think data is an IT issue, can be a challenge. But in the long run, if this doesn’t happen more often, there’s going to be a lot of overpaid, underutilized data analysts out there and missed business opportunities. So if you are an enterprise executive wondering “do I have to worry about this Big Data business?” please take a step back and look at what you already have.  And if you know any seasoned data analysts in your company, maybe even talk to them about what would make them more effective and faster at their job. The answer may be simpler than you think.

Search: a Term for the Long Haul, But…

There is no question that language influences marketing success; positioning software products has been a game of out-shining competitors with clever slogans and crafty coined terminology. Having been engaged with search technologies since 1974, and as the architect of a software application for enterprise content indexing and retrieval, I’ve observed how product positioning has played out in the enterprise search market over the years. When there is a new call for re-labeling “search,” the noun defining software designed for retrieving electronic content, I reflect on why and whether a different term would suffice.

Here is why a new term is not needed and the reasons why. For the definition of software algorithms that are the underpinning of finding and retrieving electronic content, regardless of native format, the noun search is efficient, to-the-point, unambiguous and direct.

We need a term that covers this category of software that will stand the test of time, as has automobile, which originated after terms too numerous to fully list had been tested: horseless buggy, self-contained power plant, car, motor vehicle, motor buggy, road engine, steam-powered wheeled vehicles, electric carriage, and motor wagon to name a few. Finally a term defined as a self-powered vehicle, was coined, “automobile.” It covered all types of self-powered “cars,” not just those pulled by another form of locomotive as is a rail car. Like the term “search,” automobiles are often qualified by modifiers, such as “electric,” “hybrid” or “sedan” versus “station wagon.” Search may be coupled with “Web” versus “Enterprise,” or “embedded” versus “stand-alone.” In the field of software technology we need and generally understand the distinctions.

So, I continue to be mystified by rhetoric that demands a new label but I am willing to concede where we need to be more precise, and that may be what the crowd is really saying. When and where the term is applied deserves reconsideration. Technologists who build and customize search software should be able to continue with the long established lingo, but marketers and conferences or meetings to educate a great variety of search users could probably do a better job of expressing what is available to non-techies. As one speaker at Enterprise Search Europe 2013 (ESEu2013) stated and others affirmed, “search” is not a project and to that I will add, nor is it a single product. Instead it is core to a very large and diverse range of products.

Packaging Software that includes Search Technology

Vendors are obviously aware of where they need to be marketing and the need to package for their target audience. There are three key elements that have contributed to ambiguity and resulted in a lethargic reaction in the so-called enterprise search marketplace in recent years: overly complex and diffuse categorization, poor product labeling and definition, and usability and product interface design that does not reflect an understanding of the true audience for a product. What can be done to mitigate confusion?

  1. Categorizing what is being offered has to speak to the buyer and potential user. When a single product is pitched to a dozen different market categories (text mining, analytics, content management, metadata management, enterprise search, big data management, etc.) buyers are skeptical and wary of all-in-one claims. While there are software packages that incorporate many or elements of a variety of software applications, diffusion ends up fracturing the buying audience into such minute numbers that a vendor does not gain real traction across the different types of needs. Recommendation: a product must be categorized to its greatest technical strengths and the largest audience to which it will appeal. The goal is to be a strong presence in the specific marketplaces where those buyers go to seek products. When a product has outstanding capabilities for that audience, buyers will be delighted to also find additional ancillary functions and features that are already built in.
  2. Software that is built on search algorithms or that embeds search must be packaged with labeling that pays attention to a functional domain and the target audience. Clear messaging that speaks to the defined audience is the wrapper for the product. It must state what and why you have a presence in this marketplace, the role the product plays and the professional functions that will benefit from its use. Messaging is how you let the audience know that you have created tools for them.
  3. Product design requires a deep understanding of professional users and their modes of pursuing business goals. At ESEu2013 several presentations and one workshop focused on usability and design; speakers all shared a deep understanding of differences across professional users. They recognized behavioral, cultural, geographic and mode preferences as key considerations without stating explicitly that different professional groups each work in unique ways. I assert that this is where so many applications break-down in design and implementation. Workflow design, look-and-feel, and product features must be very different for someone in accounting or finance versus an engineer or attorney. Highly successful software applications are generally initiated and development is sustained by professionals who need these tools to do their work, their way. Without deep professional knowledge embedded in product design teams, products often miss the market’s demands. Professionals bring know-how, methods and practices to their jobs and it is not the role of software developers to change the way they go about their business by forcing new models that are counter to what is intuitive in a market segment.

Attention to better software definition leads to the next topic.

Conference and meeting themes: Search technology versus business problems to be solved

Attention to conference and meeting content was the reason for this post. Having given an argument for keeping the noun search in our vocabulary, I have also acknowledged that it is probably a failed market strategy to label and attach messaging to every software product with search as either, enterprise search or web search. Because search is everywhere in almost every software application, we need conferences with exhibits that target more differentiated (and selective) audiences.

The days of generic all-in-one meetings like AIIM, the former National Online Meeting (Information Today’s original conference), E2, and so on may have run their course. As a failed conference attendee, my attention span lasts for about one hour maximum, and results in me listening to no more than a half dozen exhibitor pitches before I become a wandering zombie, interested in nothing in particular because there is nothing specific to be drawn to at these mega-conferences.

I am proposing a return to professionally oriented programs that focus on audience and business needs. ESEu2013 had among its largest cohort, developers and software implementers. There were few potential users, buyers, content or metadata managers, or professional search experts but these groups seek a place to learn about products without slides showing snippets of programming code. There is still a need for meetings that include the technologists but it is difficult to attract them to a meeting that only offers programming sessions for users, the people for whom they will develop products. How do we get them into a dialogue with the very people for whom they are developing and designing products? How can vendors exhibit and communicate their capabilities for solving a professional problem when their target professional audience is not in the room.

At Enterprise Search Europe 2013, the sessions were both diverse and enlightening but, as I noted at the conference wrap-up, each track spoke to a unique set of enterprise needs and variety of professional interests. The underlying technology, search, was the common thread and yet each track might have been presented in a totally different meeting environment. One topic, Big Data, presents challenges that need explaining and information seekers come to learn about products for effectively leveraging it in a number of enterprise environments. These cases need to be understood as business problems, which call for unique software applications not just some generic search technology. Big data can and is already being offered as a theme for an entire conference where the emphasis on aspects of search technology is included. As previously noted topics related to big data problems vary: data and text mining, analytics, semantic processing aka natural language processing, and federation. However, data and text mining for finance has a totally different contextual relevance than for scientists engaged in genomics or targeted drug therapy research, and each audience looks for solutions in its field.

So, let’s rethink what each meeting is about, who needs to be in the room for each business category, what products are clearly packaged for the audience and the need, and schedule programs that bring developers, implementers, buyers and users into a forum around specially packaged software applications for meaningful dialogue. All of this is said with sincere respect for my colleagues who have suggested terms that range from “beyond search” to “discovery” and “findability” as alternative to “search. Maybe the predominant theme of the next Enterprise Search conference should be Information Seeking: Needs, Behaviors and Applications with tracks organized accordingly.

[NOTE: Enterprise Search Europe had excellent sessions and practical guidance. Having given a “top of mind” reaction to what we need to gain a more diverse audience in the future, my next post will be a litany of the best observations, recommendations and insights from the speakers.]

Leveraging Search in Small Enterprises

A mantra for a small firm or start-up in the 1970s when “Big Blue” was the standard for top notch sales and selling was we need to out-IBM the IBMers.

Search is just one aspect of being able to find what you need to leverage knowledge assets in your work, whether you are in a small firm, a part of a small group in a large organization or an individual consultant seeking to maximize the masses of content and information surrounding you in work.

My thoughts are inspired by the question asked by Andreas Gruber of Informations und Wissensmanagement in this recent post on Enterprise Search Engine Professionals, LinkedIn group. He posed a request for information stating: For enterprise search solutions for (very) small enterprises (10 to 200 employees), I find it hard to define success factors and it seems, that there are not many examples available. If you follow e.g. the critical success factors from the Martin White’s Enterprise Search book, most of them doesn’t seem to work for a small company – simply because none of them can/will investment in a search team etc.

The upcoming Enterprise Search Europe meeting (May 14-16, 2013) in London is one focus of my attention at present. Since Martin White is the Chairman and principal organizer, Andreas’ comments resonated immediately. Concurrently, I am working on a project for a university department, which probably falls in the category of “small enterprise”. The other relevant project on my desk is a book I am co-authoring on “practical KM” and we certainly aim to appeal to the individual practitioner or groups limited by capital resources. These areas of focus challenge me to respond to Andreas’ comments because I am certain they are top of mind for many and the excellent comments already at the posting show that others have good ideas about the topic, as well.

Intangible capital is particularly significant in many small firms, academia, and for independent consultants, like me. Intensive leveraging of knowledge in the form of expertise, relationships, and processes is imperative in these domains. Intangible capital, as a percent of most businesses currently surpasses tangible capital in value, according to Mary Adams founder of Smarter-Companies. Because intangible capital takes more thought and effort to identify, find or aggregate than hard assets, tools are needed to uncover, discover and pinpoint it.

Let’s take the example of expertise, an indisputable intangible asset of any professional services. For any firm, asking expert staff to put an explicit value on their knowledge, competencies or acumen for tackling the type of problem that you need to have solved may give you a sense of value but you need more. The firm or professional you want to hire must be able to back up its value by providing explicit evidence that they “know their stuff” and can produce. For you, search is a tool to lead you to public or published evidence. For the firm being asked to bid on your work, you want them to be able to produce additional evidence. Top quality firms do put both human and technology search resources to work to service existing projects and clients, and to provide evidence of their qualifications, when being asked to retrieve relevant work or references. Search tools and content management methods are diverse and range from modest to very expensive in scope but no firm can exist for long without technology to support the findability of its intangible capital.

To summarize, there are three principal ways that search pays off in the small-medium business (SMB) sector. Citing a few examples of each they are:

  • Finding expertise (people): potential client engagement principal or team member, answers to questions to fulfill a clients engagement, spurring development or an innovation initiative
  • Retrieving prior work: reuse of know-how in new engagements, discovery of ideas previously tabled, learning, documentation of products and processes, building a proposal, starting point for new work, protecting intellectual property for leverage, when patenting, or participating in mergers and acquisitions.
  • Creating the framework for efficiency: time and speed, reinforcing what you know, supporting PR, communications, knowledge base, portraying the scope of intellectual capital (if you are a target for acquisition), the extent of your partnerships that can expand your ability to deliver, creating new offerings (services) or products.

So, to conclude my comment on Andreas’ posting, I would assert that you can “out-IBM the IBMers” or any other large organization by employing search to leverage your knowledge, people and relationships in smart and efficient ways. Excellent content and search practices can probably reduce your total human overhead because even one or two content and search specialists plus the right technology can deliver significant efficiency in intangible asset utilization.

I hope to see conference attendees who come from that SMB community so we can continue this excellent discussion in London, next month. Ask me about how we “ate our own dog-food” (search tools) when I owned a small software firm in the early 1980s. The overhead was minimal compared to the savings in support headcount.

E-discovering Language to Launch Your Taxonomy

New enterprise initiatives, whether for implementing search solutions or beginning a new product development program, demand communication among team leaders and participants. Language matters; defining terminology for common parlance is essential to smooth progress toward initiative objectives.

Glossaries, dictionaries, taxonomies, thesauri and ontologies are all mechanisms we use routinely in education and work to clarify terms we use to engage and communicate understanding of any specialized domain. Electronic social communication added to the traditional mix of shared information (e.g. documents, databases, spreadsheets, drawings, standardized forms) makes business transactional language more complex. Couple this with the use of personal devices for capturing and storing our work content, notes, writings, correspondence, design and diagram materials and we all become content categorizing managers. Some of us are better than others at organizing and curating our piles of information resources.

As recent brain studies reveal, humans, and probably any animal with a brain, have established cognitive areas in our brains with pathways and relationships among categories of grouped concepts. This reinforces our propensity for expending thought and effort to order all aspects of our lives. That we all organize differently across a huge spectrum of concepts and objects makes it wondrous that we can live and work collaboratively at all. Why after 30+ years of marriage do I arrange my kitchen gadget drawer according to use or purpose of devices while my husband attempts to store the same items according to size and shape? Why do icons and graphics placed in strange locations in software applications and web pages rarely impart meaning and use to me, while others “get it” and adapt immediately?

The previous paragraph may seem to be a pointless digression from the subject of the post but there are two points to be made here. First, we all organize both objects and information to facilitate how we navigate life, including work. Without organization that is somehow rationalized, and established accordingly to our own rules for functioning, our lives descend into dysfunctional chaos. People who don’t organize well or struggle with organizing consistently struggle in school, work and life skills. Second, diversity of practice in organizing is a challenge for working and living with others when we need to share the same spaces and work objectives. This brings me to the very challenging task of organizing information for a website, a discrete business project, or an entire enterprise, especially when a diverse group of participants are engaged as a team.

So, let me make a few bold suggestions about where to begin with your team:

  • Establish categories of inquiry based on the existing culture of your organization and vertical industry. Avoid being inventive, clever or idiosyncratic. Find categories labels that everyone understands similarly.
  • Agree on common behaviors and practices for finding by sharing openly the ways in which members of the team need to find, the kinds of information and answers that need discovering, and the conditions under which information is required. These are the basis for findability use cases. Again, begin with the usual situations and save the unusual for later insertion.
  • Start with what you have in the form of finding aids: places, language and content that are already being actively used; examine how they are organized. Solicit and gather experiences about what is good, helpful and “must have” and note interface elements and navigation aids that are not used. Harvest any existing glossaries, dictionaries, taxonomies, organization charts or other definition entities that can provide feeds to terminology lists.
  • Use every discoverable repository as a resource (including email stores, social sites, and presentations) for establishing terminology and eventually writing rules for applying terms. Research repositories that are heavily used by groups of specialists and treat them as crops of terminology to be harvested for language that is meaningful to experts. Seek or develop linguistic parsing and term extraction tools and processes to discover words and phrases that are in common use. Use histograms to determine frequency of use, then alphabetize to find similar terms that are conceptually related, and semantic net tools to group discovered terms according to conceptual relationships. Segregate initialisms, acronyms, and abbreviations for analysis and insertion into final lists, as valid terms or synonyms to valid terms.
  • Talk to the gurus and experts that are the “go-to people” for learning about a topic and use their experience to help determine the most important broad categories for information that needs to be found. Those will become your “top term” groups and facets. Think of top terms as topical in nature (e.g. radar, transportation, weapons systems) and facets as other categories by which people might want to search (e.g. company names, content types, conference titles).
  • Simplify your top terms and facets into the broadest categories for launching your initiative. You can always add more but you won’t really know where to be the most granular until you begin using tags applied to content. Then you will see what topics have the most content and require narrower topical terms to avoid having too much content piling up under a very broad category.
  • Select and authorize one individual to be the ultimate decider. Ambiguity of categorizing principles, purpose and needs is always a given due to variations in cognitive functioning. However, the earlier steps outlined here will have been based on broad agreement. When it comes to the more nuanced areas of terminology and understanding, a subject savvy and organizationally mature person with good communication skills and solid professional respect within the enterprise will be a good authority for making final decisions about language. A trusted professional will also know when a change is needed and will seek guidance when necessary.

Revisit the successes and failures of the applied term store routinely: survey users, review search logs, observe information retrieval bottlenecks and troll for new electronic discourse and content as a source of new terminology. A recent post by taxonomy expert Heather Hedden gives more technical guidance about evaluating and sustaining your taxonomy maintenance.

Mobile development strategy – platform decision update

Last April I suggested that evolving mobile platform market changes meant organizations needed to re-visit their mobile development strategy and said

“What has changed? To over simplify: Apple’s dominance continues to increase and is unassailable in tablets; RIM is not a contender; Microsoft is looking like an up-and-comer; and most surprising to many, Android is looking iffy and is a flop in tablets with the exception of the very Amazon-ized version in the Kindle Fire.”

Not surprisingly, things have changed again. Two major changes are that Samsung is now a major player, and Google has finally made progress in tablets with the Nexus 7 and the much improved Android “Jelly Bean” release. Amazon’s second Fire is also more robust. There are now real choices in tablets – personally I have an iPad, a Fire HD, and a Nexus 7, and I use all three of them, and for many purposes I just grab the closest. But businesses making a significant investment in a platform for development need to carefully evaluate its stability and staying power.

One thing that hasn’t changed is the debate among analysts over what the iOS and Android market share numbers mean – specifically, whether the larger and accelerating Android market share numbers threaten Apple’s dominance. At first glance it is natural to think that dominant market share signifies a safer bet, and indeed many analysts make this point. But it’s not so simple. Last year there was evidence that even though Android devices had a market share advantage, Apple devices accounted for much more total online activity – were used more – and it is probably safe to say that use is a requirement of product success.

More importantly, if you look at profit share, Apple continues to dominate. So the opposing view is that Apple may be the safer bet since for most values of company/product health, profit trumps revenue.

In “The Mobile Train Has Left The Windows 8 Platform Behind“, John Kirk, who doesn’t mince words, has no patience for the view that Android’s market share means it will squash Apple:

“According to Canaccord Genuity, Apple took in 69% of the handset (all mobile phones, not just smartphones) profits in 2012. Samsung took in 34%, HTC accounted for 1%…

No one not named Apple or Samsung is making any meaningful profits from the handset sector…

Many industry observers have the handset market all wrong. They opine that Andoid is destroying iOS. What is actually happening is:

  1. With 69% of the profits, iOS is doing just fine. More than fine, actually.
  2. Android destroyed every phone manufacturer not named Apple (BlackBerry, Nokia, Palm, etc.).
  3. Samsung destroyed every Android phone manufacturer not named Samsung (HTC, Motorola, Sony Erricson, etc.).

Pundits like to predict the imminent demise of iOS, but those profit numbers say just the opposite. And even as Android’s market share has increased, iOS’s profit share has increased too. Market share is no guarantor of profits. This should be self-evident. But apparently, it’s not.”

Kirk follows up with more entertaining disdain for the “church of market share” at “Does the Rise of Android’s Market Share Mean the End of Apple’s Profits?“.

In terms of tablet market share,

“According to Canalys, Apple – despite being supply constrained – sold 22.9 million tablets for 49% share, Samsung shipped 7.6 million tablets, Amazon shipped 4.6 million tablets for 18% share, and Google’s Nexus 7 and 10, combined, shipped 2.6 million tablets.”

In conclusion,

“Only Samsung and Apple are competing in phones. Only Amazon, Google, Samsung and Apple are effectively competing in tablets. The mobile “train” has left the station and companies like HP, Lenovo, Dell and Microsoft are standing on the Windows 8 platform, watching it pull away.”

For more on Microsoft see Kirk’s full post.

Mobile platforms are still evolving and the coming proliferation of new device types guarantee that there will be continuous and substantial change made to those that survive. No one responsible for a mobile development strategy should wait almost a year to evaluate their current plan. Fortunately there is no shortage of useful platform data. It just needs to be interpreted critically.

Big data and decision making: data vs intuition

There is certainly hype around ‘big data’, as there always has been and always will be about many important technologies or ideas – remember the hype around the Web? Just as annoying is the backlash anti big data hype, typically built around straw men – does anyone actually claim that big data is useful without analysis?

One unfair characterization both sides indulge in involves the role of intuition, which is viewed either as the last lifeline for data-challenged and threatened managers, or as the way real men and women make the smart difficult decisions in the face of too many conflicting statistics.

Robert Carraway, a professor who teaches Quantitative Analysis at UVA’s Darden School of Business, has good news for both sides. In a post on big data and decision making in Forbes, “Meeting the Big Data challenge: Don’t be objective” he argues “that the existence of Big Data and more rational, analytical tools and frameworks places more—not less—weight on the role of intuition.”

Carraway first mentions Corporate Executive Board’s findings that of over 5000 managers 19% were “Visceral decision makers” relying “almost exclusively on intuition.” The rest were more or less evenly split between “Unquestioning empiricists” who rely entirely on analysis and “Informed skeptics … who find some way to balance intuition and analysis.” The assumption of the test and of Carraway was that Informed skeptics had the right approach.

A different study, “Frames, Biases, and Rational Decision-Making in the Human Brain“, at the Institute of Neurology at University College London tested for correlations between the influence of ‘framing bias’ (what it sounds like – making different decisions for the same problem depending on how the problem was framed) and degree of rationality. The study measured which areas of the brain were active using an fMRI and found the activity of the the most rational (least influenced by framing) took place in the prefrontal cortex, where reasoning takes place; the least rational (most influenced by framing / intuition) had activity in the amygdala (home of emotions); and the activity of those in between (“somewhat susceptible to framing, but at times able to overcome it”) in the cingulate cortex, where conflicts are addressed.

It is this last correlation that is suggestive to Carraway, and what he maps to being an informed skeptic. In real life, we have to make decisions without all or enough data, and a predilection for relying on either data or intuition can easily lead us astray. Our decision making benefits by our brain seeing a conflict that calls for skeptical analysis between what the data says and what our intuition is telling us. In other words, intuition is a partner in the dance, and the implication is that it is always in the dance — always has a role.

Big data and all the associated analytical tools provide more ways to find bogus patterns that fit what we are looking for. This makes it easier to find false support for a preconception. So just looking at the facts – just being “objective” – just being “rational” – is less likely to be sufficient.

The way to improve the odds is to introduce conflict – call in the cingulate cortex cavalry. If you have a pre-concieved belief, acknowledge it and and try and refute, rather than support it, with the data.

“the choice of how to analyze Big Data should almost never start with “pick a tool, and use it”. It should invariably start with: pick a belief, and then challenge it. The choice of appropriate analytical tool (and data) should be driven by: what could change my mind?…”

Of course conflict isn’t only possible between intuition and data. It can also be created between different data patterns. Carraway has an earlier related post, “Big Data, Small Bets“, that looks at creating multiple small experiments for big data sets designed to minimize identifying patterns that are either random or not significant.

Thanks to Professor Carraway for elevating the discussion. Read his full post.

How long does it take to develop a mobile app?

We have covered and written about the issues enterprises need to consider when planning to develop a mobile app, especially on choosing between native apps, mobile web apps (HTML5, etc.), or a hybrid approach that includes elements of each. And have discussed some of the choices / factors that would have an effect on the time required to bring an app to market, but made no attempt to advise or speculate on how long it should take to “develop a mobile app”. This is not a question with a straightforward answer as any software development manager with tell you.

There are many reasons estimating app development time is difficult, but there are also items outside of actual coding that need to be accounted for. For example, a key factor often not considered in measuring app development is the time involved to train or hire for skills. Since most organizations already have experience with standards such as HTML and CSS developing mobile web apps should be, ceteris paribus, less costly and quicker than developing a native app. This is especially true when the app needs to run on multiple devices with different APIs using different programing languages on multiple mobile (and possibly forked) operating systems. But there are often appealing device features that require native code expertise, and even using a mobile development framework which deals with most of this complexity requires learning something new.

App development schedules can also be at the mercy of app store approvals and not-always-predictable operating system updates.

As unlikely as it is to come up with a meaningful answer to the catchy (and borrowed) title of this post, executives need good estimates of the time and effort in developing specific mobile apps. But experience in developing mobile apps is still slim in many organizations and more non-technical managers are now involved in approving and paying for app development. So even limited information on length of effort can provide useful data points.

I found the survey that informed the Visual.ly infographic below via ReadWrite at How Long Does It Take To Build A Native Mobile App? [InfoGraphic]). It involved 100 iOS, Android and HTML5 app developers and was done by market research service AYTM for Kinvey, provider of a cloud backend platform for app developers.

Their finding? Developing an iOS or Android app takes 18 weeks. I didn’t see the survey questions so don’t know whether whether 18 weeks was an average of actual developments, opinions on what it should take, or something else.

Of course there are simple apps that can be created in a few days and some that will take much longer, but in either case the level of effort is almost always underestimated. Even with all the unanswered questions about resources etc., the infographic raises, the 18 week finding may helpfully temper somebody’s overly optimistic expectations.

 
 

Launching Your Search for Enterprise Search Fundamentals?

It’s the beginning of a new year and you are tasked with responsibility for your enterprise to get top value from the organization’s information and knowledge assets. You are the IT applications specialist assigned to support individual business units with their technology requests. You might encounter situations similar to these:

  • Marketing has a major initiative to re-write all product marketing pieces.
  • Finance is grappling with two newly acquired companies whose financial reports, financial analyses, and forecasts are scattered across a number of repositories.
  • Your Legal department has a need to categorize and analyze several thousand “idea records” that came from the acquired companies in order to be prepared for future work, patenting new products.
  • Research and development is attempting to categorize, and integrate into a single system, R&D reports from an existing repository with those from the acquisitions.
  • Manufacturing requires access to all schematics for eight new products in order to refine and retool manufacturing processes and equipment in their production area.
  • Customer support demands just-in-time retrieval and accuracy to meet their contractual obligations to tier-one customers, often from field operations, or while in transit to customer sites. The latter case often requires retrieval of a single, unique piece of documentation.

All of these groups have needs, which if not met present high risk or even exposure to lawsuits from clients or investors. You have only one specialist on staff who has had two years of experience with a single search engine, but who is currently deployed to field service operations.

Looking at just these few examples we can see that a number of search related technologies plus human activities may be required to meet the needs of these diverse constituents. From finding and assembling all financial materials across a five-year time period for all business units, to recovering scattered and unclassified emails and memos that contain potential product ideas, the initiative may be huge. A sizable quantity of content and business structural complexity may require a large scale effort just to identify all possible repositories to search for. This repository identifying exercise is a problem to be solved before even thinking about the search technologies to adopt for the “finding” activity.

Beginning the development of a categorizing method and terminology to support possible “auto-categorization” might require text mining and text analysis applications to assess the topical nomenclature and entity attributes that would make a good starting point. These tools can be employed before the adoption of enterprise search applications.

Understanding all the “use-cases” for which engineers may seek schematics in their re-design and re-engineering of a manufacturing plant is essential to selecting the best search technology for them and testing it for deployment.

The bottom line is there is a lot more to know about content and supporting its accessibility with search technology than acquiring the search application. Furthermore, the situations that demand search solutions within the enterprise are far different, and their successful application requires far greater understanding of user search expectations than Web searching for a product or general research on a new topic.

To meet the full challenge of providing the technologies and infrastructure that will deliver reliable and high value information and knowledge when and where required, you must become conversant with a boatload of search related topics. So, where do you begin?

A new primer, manageable in length and logical in order has just been published. It contains the basics you will need to understand the enterprise context for search. A substantive list of reading resources, a glossary and vendor URL list round out the book. As the author suggests, and I concur, you should probably begin with Chapter 12, two pages that will ground you quickly in the key elements of your prospective undertaking.

What is the book? Enterprise Search (of course) by Martin White, O’Reilly Media, Inc., Sebastopol, CA. © 2013 Martin White. 192p. ISBN: 978-1-449-33044-6. Also available as an online edition at: http://my.safaribooksonline.com/book/databases/data-warehouses/9781449330439