A solution for expertise location within an enterprise is very effective when it provides a holistic view of experts across the business for a variety of expertise topics which are usually as diverse as the business itself. There are several key facets to an enterprise-wide expertise location system. They are:
- Classification of Expertise Topics - Typically, a taxonomy of expertise topics created by the various parts of the business and augmented using the folksnomy approach ensures expertise topics are current and popular expertise topics are also represented accurately.
- Identification of Experts based on their level of expertise, obligation to assist and scope of visibility (example: Enterprise-wide, community or group, etc) - There are different levels of expertise and experts are usually identified and made visible with one of the levels of expertise for a given expertise topic as shown in figure 1 and figure 2.
- Nomination of Experts - Experts may be self-nominated or business nominated for a given expertise topic.
- Methods of engagement with experts - Once experts are located, they may be engaged synchronously or asynchronously. End users may chat (instant message) with experts or submit a question to the system which may route the question to a group of experts or a single expert.
- Influence of Social Media on identification of experts - Given the widespread adoption of social media by the public and by enterprises of all sizes for different aspects of conducting business, one of the key uses of social media is in the identification of potential experts based on their activities or eminence in social media internally and externally to the enterprise. For example, a person who blogs extensively about Cloud Computing may actually be an expert in Cloud Computing.
- Reputation system for experts - To encourage sustained participation of experts to help others, an Expertise Location system must provide ways to identify popular experts and a rating mechanism for the interaction between end users and experts. Importantly, implementation must be compliant with the enterprise's privacy guidelines.
Figure 1. Levels of expertise
Figure 2. Expertise location committment levels
Requirements for an enterprise Expertise Location system are identified from various business stakeholders across an enterprise. Besides the key facets listed in the Introduction section, the following are high level requirements that an Expertise Location system should implement:
REQ-01: Common user interface and experience - Provide a common user interface and experience for end users, experts and administrators in the form of a web application.
However, capability to gather information about experts and expert enrollment should be also be enabled in other intranet sites. The web application may be accessed
via Mobile devices.
REQ-02: Expertise Taxonomy - The business has a goal to expose experts from various parts of the business, for example, Sales, Marketing, Finance, etc to end users across
the enterprise. These areas may utilize specific taxonomies to represent the different expertise topics for that area.
REQ-03: Automate the taxonomy administration process - The business has a goal to automate the synchronization of expertise taxonomies that are
imported from external master data sources. The process will need to account for expertise topics being dropped from the taxonomy and the system needs to notify
the taxonomy administrators of the changes and notify experts in those expertise topics as well.
REQ-04: Enhanced Collaboration - Provide enhanced collaboration capabilities between end users, experts, and administrators to facilitate more informed and timely help,
improved search via social collaboration (tagging), and reporting. Real-time interaction and asynchronous Question and Answer interaction is required between the end
user and expert. Capability should be provided to provide feedback to experts in terms of rating the interaction.
REQ-05: Enable multiple intranet clients and external clients to access services - Multiple service consumers, for example, web application presentation tier,
intranet web pages, external web pages, mobile devices, etc will need to access the expertise location services via multiple bindings.
The expertise location system should allow these clients to access these services.
REQ-06: Services re use - Identify services that can be re used from other systems.
REQ-07: Adoption of standards and common middleware - Adopt industry standard technologies that include the selection of recommended deployment infrastructure
middleware and tooling.
REQ-08: Provide access to internal and external clients in a secure and reliable way - Provide access to Expertise Location services to internal and external
clients in a secure, reliable way, without exposing the solution infrastructure to external access.
REQ-09: Flexible communication between connectivity domains - The Expertise Location connectivity domain should integrate well with the external connectivity domain
to ensure service consumers from outside the enterprise can access services within Expertise Location system in a loosely coupled manner. Support for message
transformation and multiple protocols should be provided.
REQ-10: Minimize impact of changes to service consumers - Changes to expertise discovery services or changes in infrastructure to Expertise
Location system should avoid disruptions or keep disruptions to service consumers to a minimal.
REQ-11: Enable service consumers to access data via API - Web pages in the intranet and external sites will need to display information stored
in the relational database which contains data about expertise taxonomies, experts and knowledge base of questions and answers. The data in the relational
database may be enriched via analytics and this data will need to be accessed by service consumers.
REQ-12: Enable consumers to access a diverse set of data in real time - The Expertise Disocvery system needs access to expertise information
that is stored in a diverse set of data sources. The system needs real-time access to these sources to retrieve suggested experts based on social
activities within IBM. Queries must be processed within 5 seconds.
REQ-13: Authentication - When a user interacts with the Expertise Location services via the web application or from other clients, there is a
need to authenticate and determine the identity. The solution needs to provide authentication services.
REQ-14: Authorization - The system needs to ensure that the user has access to permitted information based on the identity of the user or system.
Authorization might be required for many components, including coarse grained service-based authorization (service components), to a fine-grained service
level data access control.
REQ-15: Incorporate human interaction for workflows - Robust human workflows to support the approval of expertise area setup, taxonomy setup and
expert signup should be implemented.
REQ-16: Implement services providing master management of data - The system should implement services that enforce expertise data integrity.
The system should make improvements in the consistency and quality of data and ensure the data is accurate.
The architecture style defining a SOA describes a set of patterns and guidelines for creating loosely coupled, business-aligned services that, because of the separation of concerns between description, implementation and binding, provide unprecedented flexibility in responsiveness to new business changes and opportunities. The SOA patterns simplify the understanding of the overall solution from an SOA perspective. Applying SOA patterns and best practices makes it easier to understand the impact of each piece of the solution and helps in the adoption of the solution in phases. Table below shows the SOA entry point and related SOA patterns pertaining to the requirements of an enterprise Expertise Location system.
|SOA Entry point / Discipline||SOA Scenario||SOA Patterns|
|People entry point||Interaction and Collaboration||Rich web-based applications|
|Services||Invoking services on the glass|
|Information entry point||Information as a Service scenario||Master data management|
|Connectivity Entry point||Service Connectivity SOA Scenario||Internal Connectivity|
|Enterprise Service Bus|
|SOA design entry point||SOA design scenario||SOMA for service design|
|SOA security, governance and management discipline||SOA security and management scenario||Service security|
|SOA governance scenario||SOA governance|
|End-to-end service management|
This pattern demonstrates the value proposition of AJAX clients over classic or simple clients, which includes benefits in performance and responsiveness.
- Technical problem: Provide user interfaces that facilitate collaboration and sharing between users and that also speeds up web interface responsiveness. When end users search or browse for experts or search the knowledge base, the results should be updated without having to refresh the entire page.
How this pattern is applied:
Expertise Location solution will use AJAX-based user interfaces. These interfaces are used to, for example, dynamically load content during
user interactions with the system. To provide content refreshes, the entire page is not refreshed only the changed content is refreshed.
Figure 3. Rich web-based application SOA scenario
- Business value of adoption: End users, Experts, and Administrators can work more efficiently, with faster user interface response times. This results in enhanced user experience.
The invoking services-on-the-glass pattern describes how to provide a common user interface and experience to access disparate applications from a single location.
- Technical problem: Expertise information based on employees social activities is available in multiple applications and this information should be consolidated for end users to quickly find registered experts as well as suggested experts based on their social activities.
How this pattern is applied:
Proposed solution provides an integrated capability via a web based interface to allow end users search for experts. The solution will provide an
open interface in which common, channel agnostic services can be served by any front end. A widget displayed in an intranet site may
register experts in a context sensitive manner and that information will be available to end users from the web application.
Figure 4. Invoking services-on-the-glass SOA scenario
- Business value of adoption: The proposed solution will provide increased productivity for all end users who use the web application as well as users of other intranet sites where experts may be displayed in a context sensitive manner as well as allow for end users to sign up as experts. This significantly reduces the barrier for expert enrollment.
The master data management pattern illustrates how to reconcile expertise taxonomies and expertise keywords from external sources with a single, definitive, master source that can be reference source since expertise information may exist in multiple sources.
- Technical problem: Expertise taxonomies and expertise keywords is usually distributed across multiple heterogeneous systems. The information in these sources exists in various formats and several batch programs may be required to periodically synchronize the information.
How this pattern is applied:
The proposed solution incorporates a centralized master data management (MDM) relational database repository to store a consistent set of Expertise taxonomies
and expertise keywords. The MDM repository is initially populated using the Extract / Transform / Load (ETL) pattern. Using services, data in MDM is
synchronized from external sources on a periodic basis. Information is also extracted from MDM by other systems through services.
Figure 5. Master data management SOA scenario
- Business value of adoption: By adopting Master Data Management pattern, the proposed solution can eliminate inconsistencies in expertise taxonomies. It also stands to provide accurate, real-time expert information to other systems.
The business intelligence pattern describes how to use information in expertise taxonomies, experts enrollment, knowledge base and social activity based suggested experts to make informed decisions about targeting expert enrollment.
- Technical problem: Expertise Discovery solution needs the ability to provide in-depth intelligent analysis and reporting to understand expert enrollment patterns, gaps in expert enrollment across different business units. Solution should also provide the ability to analyze questions being asked of the experts.
How this pattern is applied:
Figure 6. Business intelligence SOA scenario
- Business value of adoption: This architecture facilitates business users across the enterprise to view critical gaps in expert enrollment and get intelligent reporting on what type of questions are being asked and help business users to make decisions on targeting expert enrollment.
Internal Connectivity describes how multiple internal clients within the organization can access the expertise discovery services.
- Technical problem: Expertise Location services will need to be accessed from different environments, such as browsers, mobile devices, Portals, etc. These environments will be using multiple protocols to access the services, however, developers should not write or change code every time a new environment wants to access the services.
How this pattern is applied:
Expertise Location architecture adds Service Component Architecture (SCA) implementation. Service Component Architecture (SCA) has emerged as
a standard in SOA and the promise of SCA is that developers will only need to focus on developing business logic and SCA provides a single programming
model for invoking a component. Also, SCA allows a single component to have multiple configurable bindings.
Figure 7. Internal connectivity SOA scenario
- Business value of adoption: By adopting internal connectivity through Service Component Architecture (SCA), the solution is better positioned to adapt to new clients accessing the services. Enables developers to write business logic once and be accessed by multiple different clients without the need to be concerned with infrastructure logic.
In order to fully support the variety of interaction patterns that are required in a comprehensive SOA (for example, request/response, publish / subscribe, events), the Enterprise Service Bus must support in one infrastructure the three major styles of Enterprise Integration: Service-oriented architectures, Message-driven architectures and Event-driven architectures.
- Technical problem:
Since the Expertise Location system will need to be integrated with external clients, the following are required:
- Provide location transparency and support service substitution
- Support integration in a heterogeneous environment and support service substitution.
- Support SOA principles, separating application code from specific service protocols and implementations
- A point of control over service addressing and naming.
How this pattern is applied:
An ESB architecture is introduced into the architecture for loose coupling, basic routing and to easily integrate and adapt to many of the external clients.
The ESB provides support for different protocols and exchange of message formats between the system and external clients.
Figure 8. Enterprise Service Bus SOA Scenario
- Business value of adoption: By adopting ESB, the system is better positioned to adapt to changes in integration styles with external clients. The system will have the ability to respond to special integration requirements as they arise. The ESB also decouples the Expertise Location services from external clients.
The process automation pattern addresses the problem of how to automate workflows including the integration of automated human tasks. It also addresses the ability to automate the integration across multiple applications and back-end repositories.
- Technical problem: If experts are enrolled in an expertise topic and if that expertise topic is changed by an administrator, the experts should be notified. Expertise taxonomies from external sources should be synchronized on a periodic basis. Additionally, for global enterprises, processes related to privacy compliance may be different in different countries and implementation should handle the variations. Experts who help should also be recognized and need to be integrated with existing employee recognition processes. Enterprises sales processes have requirements to optionally tap into experts within the enterprise during 'pre sales' operations.
How this pattern is applied:
The proposed solution uses a process for expertise taxonomy administration which is more efficient and better aligned to Expertise Location requirements.
When an expertise topic (with enrolled experts) changes, the experts are automatically notified and administrators of the affected expertise areas will be
able to monitor the impact of the changes via the web application. Administrators will also be notified of the status of expertise taxonomies synchronization. The solution
also interfaces with an existing employee recognition program and sales systems.
Figure 9. Process Automation SOA scenario
- Business value of adoption: Experts would be automatically notified of changes in expertise topics. Administrators would be notified to monitor the changes and impact to the expertise area thus gaining operational efficiency. Compliance with privacy laws is achieved, experts are recognized for their contributions which helps with sustained expert participation and timely identification of experts is also achieved to help with sales opportunities.
The service security pattern covers aspects of security management specifically in the security policy/configuration across a multiple set of endpoints for authorization, message security and access control.
- Technical problem: The proposed solution needs an integrated and centralized SOA security policy management across all end points for interactions with service requestors and providers. The solution needs to efficiently manage identities, and this identity information must be available across request flows. Currently, there are no requirements for data encryption.
- How this pattern is applied: The proposed solution adopts a federated security framework that is a combination of Java security, LDAP, firewall security (for external service consumers) and web-based security. Enforcement of authentication is managed by enterprise directory services. Regarding access control, the users (end users, experts and administrators) have access only to functionality that is permitted for their roles. SCA implementations supports role based access control at the service level or component (grouping of services) level.
- Business value of adoption: By adopting a federated security approach, the proposed solution can secure the services end-to-end, control access to its back-end systems and comply with an enterprise's security policies.
The SOA governance pattern includes regulating new service creation, getting more reuse of services, enforcing standards and best practices, service change management and service version control.
- Technical problem: Integration with other applications will be required and open standards based communication protocol is required. Additionally, governance on the identification and specification of business services is needed as services will be accessed from multiple clients.
- How this pattern is applied: A governance policy is used to enforce security authentication policies for access to any of the services by internal and external clients. There is also governance for identification and specification of services that are needed to be accessed by various service consumers. SOMA is used in the identification, specification and realization of services.
- Business value of adoption: Service re use and thus reduced costs are a major benefit of adopting SOA governance and duplicate services are not created and more services are re used conforming to best practices and industry standards.
SOMA method is an analysis and design method that is used for the design and construction of SOA to enable target business processes. SOMA accomplishes this through the Identification, Specification and Realization of services, components and flows. See Reference section for links to information about SOMA.
The goal of the service identification step is to create an initial set of candidate services and their associated operations that are meaningful to Enterprise Expertise Location. Key inputs to service identification include:
- Use Case Scenarios, System use cases and User Needs model (See References section)
- Services from existing systems that can be re used
To build the Expertise Location system, Domain decomposition and Existing Asset analysis techniques are used to identify services. Goal-service modeling is not used since metrics to evaluate the performance of the business are not defined for Expertise Location.
- Domain Decomposition - With Domain decomposition, the Expertise Location business domain is decomposed into major functional areas and subsystems. At the next level, the functional areas are further decomposed into processes, sub processes and high-level business use cases.
- Existing Asset Analysis - The main objective of the existing asset analysis is to maximize the reuse of application modules from any current solutions A bottom-up approach can be taken taken to identify existing asset analysis to determine if any existing services can be re used.
The following major services are identified to meet the requirements of an enterprise expertise location system. The services listed below may be further decomposed into fine grained services during Service Specification and Service realization steps of SOMA. This will be discussed in Part 2 of the article.
|#||Service Name||Service Description|
|1||Expertise Classification||Classification of Expertise Area topics which can be business managed starting with the enterprise standard taxonomies or created by user base. Classification can also be via social tagging and folksnomy.|
|2||Expert sign-up||Expert sign-up service can be business managed (business nominated) or opt-in by experts (self-nominated) to the expertise topics in the Expertise Classification (Taxonomy). Expertise levels and committment to assist is also handled by this service. Ability of experts to describe themselves using a growing vocabulary of expertise topics. This facilitates search service.|
|3||Availability Management||Enables the expert to specify their availability and other expertise which may help the system to identify them by end users.|
|4||Managed interaction||Synchronous (Chat) and asynchronous (email, Web UI) interaction between end users and experts for the purposes of answering a question from the end user. Feedback on interactions is also managed by this service.|
|5||Knowledge Harvesting||Experts should have the ability to harvest knowledge from the interaction and enrich the knowledge base.|
|6||Publish/Subscribe||Information about experts should be displayed in other intranet sites as well as the ability for end users to be notified when an expert signs up for an expertise topic that is being "watched" by the end user.|
|7||Search||Ability for end users to determine experts based on their needs (Expertise topic, tags, rating, expert availability, business location, willingness to travel,etc)|
|8||Delegation||In the case of peer assist, an expert should be able to delegate the answering capability to another expert. In the case of administration, expertise area administrators can delegate their authority to others.|
|9||Analytics||Service to provide business insight and intelligent analysis based on expert enrollment and knowledge base.|
|10||Reporting||Experts and administrators have the ability to view a variety of reports related to QandA, tags and expertise area administration.|
|11||Data Access||End users, administrators and experts may need access to data from other intranet or external portals.|
|12||Broadcast||End users may communicate the question in a broadcast mode to many experts.|
Using the SOA patterns, published OASIS guidance on SOA reference architectures, and solution architectures from successful implementations of Expertise Location systems, a reference architecture has been created as shown in Figure 10.
The four guiding principles are:
- Technology Neutrality refers to independence from particular technologies since the prinicples that underlie SOA-based systems have the potential to outlive any specific technologies that are used to deliver them.
- Parsimony refers to economy of design, avoiding complexity where possible and minimizing the number of components and relationships needed.
- Separation of Concerns refers to the ability to cleanly delineate architectural models in such a way that an individual stakeholder or a set of stakeholders only see those models that directly address their respective areas of interest. This primarily referring to loose coupling of models.
- Applicability refers to that which is relevant. The architecture is relevant to as many facets and applications of SOA-based systems as possible.
Figure 10. Enterprise Expertise Location Reference Architecture
Expertise Location systems are becoming strategic within many enterprises. In this article, you learned how SOA patterns are applied to Expertise Location system requirements and how a reference architecture was derived. In part 2 of the article, Solution Architecture, Data Model, Implementation technologies and Architetcural decisions will be discussed.
The author wishes to thank:
- John Bosma and Vicky Griffiths-Fisher for the work related to identification of Expertise Location services.
- Michael Ticknor and Vicky Griffiths-Fisher for the work related to Expertise Location commitment levels.
- John Bosma, Galina Grunin, Michael Ticknor, Erich Walls and Sandy Yarchin for their insights and contributions to the Expertise Location solution within IBM.
- "OASIS - Reference Architetcure for SOA
- "IBM Redbooks - SOA Patterns - Several useful books on SOA patterns and case studies
- " MIT article on Expertise Location - A great article on Expertise Location
- In the XML area on
developerWorks, get the resources you need to advance your XML
skills, including DTDs, schemas, and XSLT.
- Stay current with developerWorks technical events
and webcasts focused on a variety of IBM products and IT industry
- Attend a free developerWorks Live!
briefing to get up-to-speed quickly on IBM products and tools as
well as IT industry trends.
- Follow developerWorks on
- Watch developerWorks on-demand demos
ranging from product installation and setup demos for beginners, to
advanced functionality for experienced developers.
Get products and technologies
Evaluate IBM products in the
way that suits you best: Download a product trial, try a product online,
use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to
implement Service Oriented Architecture efficiently.
- Get involved in the My developerWorks community.
Connect with other developerWorks users while exploring the
developer-driven blogs, forums, groups, and wikis.
Murali Vridhachalam is an Open group certified IT Architect and has been with IBM since 1994. He has architected and deployed several enterprise applications within IBM. His current interests include architecting solutions in the software as a service and platform as a service domain. He provides technical leadership to a team of software engineers whose mission is to develop innovative solutions using IBM's wide array of enterprise software products.