Dreaming of KM services

I have a dream … about building composite knowledge management applications. In my dream, I open a Web browser and quickly pull together the KM application and data components I need in a real-time, customized fashion to do whatever business functions I have in mind. But is this just a dream?

The KM value chain

For years I have been identifying, researching, investing in and integrating different knowledge management tools. Many of those tools provide specific capabilities such as enterprise search, categorization and clustering, entity extraction, geo-tagging or visualization of some sort. While some of the tools can provide a standalone service, many KM tools are designed to work together to provide an IT value chain of data processing.

Frequently, the business goal for a KM technology is to somehow incorporate it into existing enterprise business information systems. Usually that is done to offer the user capabilities to support new business objectives or simply to improve efficiency and productivity for existing business processes. Equally often, the business goal is to deliver a technical capability never before seen by users, which changes the way they work or interact. In either scenario, integrating new software products into the existing enterprise is often the most challenging part of KM technology implementation.

A poor KM implementation that doesn’t anticipate users’ needs or give access to important systems or data will probably be underused at best, or ignored at worst. If the target integration environment is a Windows client/server application, integration usually requires in-depth knowledge of application programming interfaces (APIs) for the existing system as well as for the new application. If the target integration environment is an n-tier Web application, it usually requires in-depth knowledge of new APIs, as well as access to a middleware layer with often requisite, complex, n-tier Web integration tools and techniques.

Unfortunately, none of the aforementioned IT implementation activities is straightforward or standardized. The custom development activities required are typically single purpose and can’t be easily reused or repurposed. All of those things entrench IT departments in a legacy support role and make it much more difficult for them to offer or support new applications and data services.

Enter services-oriented architecture (SOA)

SOA is an architectural approach based on Internet standards and XML, in which applications are altered so that they offer their services through a standards-based application interface called the Web Services Description Language (WSDL). Application developers and/or IT implementation staff can define a WSDL for a given application, and once it is available, users (human or machine) can subscribe to the Web service provided via the WSDL through a single point of access, assuming appropriate security and licensing.

Web services and SOA are helping government and industry eliminate redundant computer systems, minimize complex integration projects and reduce overall systems complexity. How is that possible? By IT departments making as many of their legacy systems as possible Web services-based, they thereby create an evolutionary environment. Users will subscribe to the most useful and reliable services, and the rest will wither due to lack of use. Web services are almost Darwinian in nature, allowing for the survival of the fittest service to perform a particular function.

While SOA is not an approach that can be implemented overnight, it can, if implemented correctly, considerably reduce the time it takes to upgrade, integrate and/or modify the systems that use them. Through SOA approaches, older legacy systems can be made available as Web services, as can formerly hard to integrate legacy data sources. Of course, Web services can and should be used to deliver new applications and data sources as well.

The old world vs. the new world

I’m old enough to remember working with mainframe and large-scale minicomputer systems and what it was like asking the mainframe application group to build a new business application. You used to go to the IT and application development group and request a new application at least two years prior to needing it delivered. A systems analyst would study the business issue, gather user requirements, design the application and then give it to a team of software engineers to build, debug and deliver. That approach hasn’t really changed all that much with client/server and legacy Web applications.

What is interesting is that legacy client/server-based systems and older n-tier solutions have brought us right back around to the "bad old days" of mainframe and large-scale minicomputer application development scenarios … only much, much worse. That is because there are orders of magnitude more client/server-based and n-tier Web systems and solutions than there ever were mainframe and minicomputer systems.

In this age of client/server and n-tier Web applications, if you need a new application, you approach IT with a new set of business requirements. Assuming you have a budget, IT management assigns an architect and/or a developer to design, develop and implement the solution in 12 to 24 months. Sound familiar? You hope that when the system is completed, you get something close to what you asked for and that people will use it. It’s no wonder that so many IT projects fail miserably.

Business and government can’t afford to operate in this manner any longer. They need the flexibility to quickly add new capabilities and services at the speed of business in the 21st century. With SOA and Web services, IT can focus on delivering new applications and data as part of the SOA and rely on Web services to provide the means for inter-application and data integration. Enterprises can use standardized portal implementations to exploit Web services, allowing users to pick and choose the application and data services they need when they need them.

Through the portal, users access the services of interest as small program components and configure them in different groupings that result in uniquely configured sets of applications that more precisely meet business user needs at that moment. A good example is the free iGoogle Portal. To access iGoogle go to google.com and sign up for a Google and/or a gmail account. You will be assigned an iGoogle home page.

Google has a large collection of different types of utilities that it refers to as gadgets. Google gadgets are application components