There are some points in history that are pivotal for societies and economies, and we are at one of these points right now. As the enterprise resource planning (ERP) technology that we use in our businesses has become more powerful and complex, the ability to simplify and find information in these massive data stores has become more critical. We are now at the crossroads where the technology that solves this problem is catching up with the ERP tools we use in our businesses. Two parallel approaches have developed to offer us different solutions—enterprise search and enterprise application search (EAS). Enterprise search allows full search of a broad spectrum of data sources ranging from content of enterprise applications, e-mail servers, intranets, and other structured or unstructured content. EAS, on the other hand, is a search function built directly into an enterprise application, allowing context-specific and general searches within the application.
Let's explore these two approaches and what they mean for those of us responsible for making the most of ERP investments.
An Historic Crossroads
Historical dates are divided into years BC, or before the birth of Jesus of Nazareth, and AD, or Anno Domini. It is not our intention to debate the mistakes that the monk Dionysius Exiguus made in arriving at the date of transition between eras, or whether the more neutral terms BCE and CE (for Before the Common Era and Common Era, respectively) are preferable. Instead, we will focus on the passing of two other historic landmarks and their implications for enterprise computing.
The first date we will focus on is the advent of the Internet, which changed computing forever.
When the US Department of Defense's Advanced Research Projects Agency Network (ARPANET) and open architecture networking first gave rise to the galactic network that we now refer to as the Internet, life online was very different than it is today. We can refer to this period as BG, or Before Google (although perhaps it would be more correct to refer to this period as BAV, or Before AltaVista). This new era started at the second date of importance here—the advent of full-text Internet search, which changed the Internet forever. In August of 1995, technicians at Digital Equipment Corporation's Western Research Lab completed the initial index of the entire Web, allowing full-text search of ten million Web pages. AltaVista, the first globally successful, text-based search engine was born—only later to be eclipsed by Google.
What is so earth-shattering about that moment? In the early days of the Web, bookmarks, portals, and Web indexes were very important in order to find what you were looking for online. The Internet had succeeded in connecting countless remote computer networks, but in order to find anything, paradoxically, you had to first know where it was. Many sites on the Internet prominently featured links pages, which were designed to be reference points thoughtfully provided by the sites' owners to make it easier for their visitors to find specific resources online. Earlier search tools required site owners to register their web sites, and then, only very narrow keywords would be searchable rather than the entire site contents. So using an early search engine, you might, at best, be able to find a site about sports history, but not specific information on how many home runs baseball great Hank Aaron accumulated during his career (775) or the number of goals Brazilian soccer great Ronaldo has scored in World Cup play. You could find sites containing information on industrial equipment, but probably would have trouble finding "for sale" listings for a used dewatering screen for your mining operation, or a rotary die cutter for your printing and converting company.
Searching within Your Own Systems
The ability to find things on the Web using powerful search tools like Google and AltaVista is a tremendous time-saver. Similar time-saving and efficiencies can also be achieved by expediting the search for information within your company's own systems—specifically, within an enterprise application.
An enterprise application is in some ways similar to the public Internet, as it connects computer data throughout your company, uniting islands of information into a single data universe. And like the Internet, the application features some type of navigation structure to help you surf between the different screens and functions. These tabs or hierarchy of screens are the equivalent of the bookmarks we used to have to navigate the Internet. To run a query on your enterprise data, you go to the correct form and run a query in the appropriate field or dialog. Just like in the early days of the Internet, to find information in your business application, you need to know where it is.
In searching for information about a particular company, you need to know whether the information you want is attached to records regarding individual companies, records on people who work for the company, or records of active projects having to do with the company. With enough knowledge of precisely how you have configured your enterprise application, you can find what you are looking for.
This search method is probably an acceptable way for frequent users of a system to search for purchase orders, or to search by supplier or customer information. But it does not work that well for the occasional user of a system, or even for a heavy user of the system who is searching an application in an area with which he or she is not intimately familiar. Because enterprise applications are so broad and cover so many different disciplines within a company, it is hard for any one person to have a thorough understanding of even a majority of an application's functionality.
That is why application vendors are coming to market with various search solutions for use within their products. There are two distinct approaches to delivering this critical search function.
In short, EAS is a tool that is tightly integrated with an enterprise application, and it delivers targeted search results from within the application's knowledge base. Enterprise search is a product marketed separately from the application, and searches data both inside and outside of the application.
Enterprise search is the approach taken by a number of technology vendors, including Google, which has launched its Google Search Appliance and Google Mini products. SAP and Oracle are each marketing their search tools as a separate product to locate data not only within their own applications, but elsewhere on a company's intranet and databases. Other vendors, including Thunderstone, Index Engines, Autonomy, Convera, FAST Search, and Verity, focus more exclusively on search tools rather than the enterprise applications they are to work with. All of these offerings can be considered examples of pure enterprise search. They are generic search appliances for use within an enterprise. The alternative strategy, EAS, involves a search function more tightly integrated with a specific application, and is a critical feature to look for in an enterprise application.
Going Further with EAS
For various reasons, very few enterprise application vendors are focusing first and foremost on delivering EAS, which offers Google-like search capabilities strictly within their own suites of applications. Some vendors may have a hard time engineering this feature into their products because they own a large number of different applications, all with different architectures. Other vendors may find that offering EAS is not an attractive option for them given their business models, as they prefer to develop broad technology stacks beyond the scope of their applications; so developing a stand-alone search appliance is more appropriate for them.
EAS perhaps takes search effectiveness one step further than Google and other stand-alone search tools, since a generic Google-like search does not let you fully leverage context in the design of your search. With Google and other broad enterprise search tools, you get a lot of results, but perhaps very few are relevant. In the case of a Google search of the Web, for instance, a search by a keyword like "Ford" might yield information on President Gerald Ford, actor Harrison Ford, or Ford vehicles. It is difficult to tell the Google engine exactly what it is that you are looking for. Similarly, an enterprise search of your internal data can yield thousands of irrelevant documents on any customer, with little opportunity to narrow the search to find only purchase orders, only word processor documents of correspondence, only invoices, only change orders, etc.
By integrating search technology directly into an enterprise application, application designers can allow users to specify whether they are searching for a company, a person, a purchase order, or other types of information. This helps to filter out irrelevant search results and deliver even more efficiency than a typical Google-like search.
There is a place in organizations for stand-alone search products. If a company needs to index multiple sources of data, including company intranets, local documents, e-mails, databases, etc., a number of these bolt-on search appliances can do that.
Conversely, true EAS capabilities are integrated as a component within an application. The primary purpose of EAS is to make the information within that specific application suite easily searchable through a unified interface. Because EAS is integrated into the application it is designed to be used with, it offers a number of benefits for searching application data when compared to generic products like those offered by Oracle, Google, Thunderstone, Index Engines, Autonomy, Convera, FAST Search, Verity, and others. These advantages include
- Cost—Because the EAS tool is integrated into an application, it does not carry additional software licensing or hardware fees. Moreover, there is no work or cost involved in integrating the search tool with your systems. EAS functionality is part and parcel of a modern enterprise application, so no integration project is necessary.
- Security—Even if a bolt-on search tool has security features, these security features need to be integrated with each application and data source they are to be used with. A full-featured application search relies on the underlying security schema of an application, which means search results are only visible to people with the proper user permissions to view that data. For instance, general ledger data, closely guarded in both publicly and privately held companies, is automatically protected from unauthorized viewers.
- Context—An EAS tool can use contextual information, including data on what tasks that user has been performing in the applications, to deliver more targeted results. This is similar to how Google has added various tools to allow search results to become more specific, such as geographic filters so that local results can be moved up in the list of results when appropriate. But this concept can also be used to leverage business process context rather than geographic context, so that if a system user is involved in finance-related functions, results that conform to his or her organizational role can be accentuated.
- Intent—Because EAS has full knowledge of the application metadata (information about information), it is possible for the user to express intent of a search in simple, well-understood business terms such as "customer information," "order data," "product data," or other descriptors.
- Hybrid search—It should be possible to combine the EAS results and traditional database search results into a single query to deliver the best of both search methods at once.
EAS and enterprise search are two different approaches that are taken by different types of companies. A company that focuses on investing in and improving its enterprise application products will naturally offer a search tool for use within those applications. Marketers of bolt-on search appliances cannot design their tools for use within specific enterprise applications. Companies that market enterprise applications along with other technology products, including middleware and bolt-on search appliances, are invested in a broad number of technologies, and naturally will want to deliver a search tool for use across its own portfolio of products and beyond. That is why, like best-of-breed enterprise search companies, SAP and Oracle may have a hard time refining their search technologies specifically for their own enterprise suite products.
Moreover, companies like Oracle and Infor Global Solutions may have a very difficult time offering refined EAS functionality for their products, as they each own so many of them. Each of the applications purchased by Oracle and Infor feature distinct data architectures, which means the EAS tool would have to be developed separately for each of the broad portfolio of products. On the other hand, companies that offer systems based on more of a uniform platform with consistent architecture throughout the enterprise suite will be able to rapidly offer integrated EAS.
Of course, there is no reason that it is not possible to, on the one hand, operate an enterprise application with its own internal EAS function and to, on the other hand, also implement an enterprise search application like Oracle SES, Google Enterprise, and other like products. An application based on a service-oriented architecture (SOA) can make its EAS capabilities available as a Web service in order to facilitate this exact scenario. But while many organizations may have a hard time justifying the cost of a universal search tool, they will find it highly desirable and more affordable to choose an enterprise application with EAS functionality that provides better, deeper integration with the application's data and user interface.
Furthermore, employing an enterprise application with EAS functionality may encourage users of the system to be more diligent in entering data into the enterprise application. Correspondence, diagrams, photos, engineering drawings—all of these documents can be attached to records within a top-tier application. The presence of EAS may also motivate users to make more complete use of the application. If users know that it will be much easier to find information once they upload it to an enterprise application, they will be inclined to store more correspondence and supporting data within the application.
Specific versus Universal Search
Both the Internet and enterprise applications are vast sources of information, and while we have become accustomed to powerful Internet search tools like Google, we are only beginning to harness similar tools in our internal systems. But while Internet search engines are working to offer more targeted search options, the ability to refine and target results of a search within an enterprise application is even more critical than it is on the Web.
While a number of companies—including Google—are offering search appliances that can be bolted on to enterprise applications, they are costly, and they might not work optimally with the applications they are running with. Moreover, substantial work and cost can be involved in configuring a search tool with these applications. Of course, these bolt-on search tools have an upside: they can search information both inside and outside of applications, indexing intranets, e-mail servers, and other data sources.
In particular, companies running a large number of unrelated systems ought to look long and hard at these search appliances, because for these companies, EAS will only deliver a fragmented search solution. But bolt-on search appliances cannot offer the type of highly relevant and immediately useful search results that are possible when EAS functions are tightly integrated into an enterprise application itself. Enterprise search and EAS both have their places. But a tier-one or tier-two enterprise application ought to offer quality, integrated search functionality to help users save time and increase productivity.
EAS should be a criterion in selection processes, and something enterprise software users should ask their existing vendors about.
About the Author
Dan Matthews is the chief technology officer of IFS research and development (R&D). He has been with IFS since 1996, working with software architecture and IFS technology platforms. Matthews holds an MSc in computer science and software engineering from Linköping University, Sweden. Matthews can be reached at dan.matthews@ifsworld.com.
For more information and to start your own custom solution comparison, please visit