The information worker of the 21th century is facing with various decision processes where he or she has to react on ad-hoc and unexpected events. Theses processes are unstructured meaning it is not possible to model them in advance by traditional IT systems such as Service-Oriented Architecture systems.
Now, our concept of dynamic enterprise mashups comes into place. It has the potential to overcome this challenge by integrating the peer production principle into the composition of individual applications. By leveraging the wisdom of the crowds, dynamic enterprise mashups allows automating unstructured decision processes which results in a new stage of improved user productivity.
Okay, this is enough buzzword bingo. What is the idea behind dynamic enterprise mashups? Imagine you are a sales manger working in the sales department in Switzerland. On a daily base, you are facing with with ad-hoc events which always differ from each other. One of your colleagues working in a similar context (for example he is a sales manager working in the US), has created a small application for handling this particular problem. It would be great, if you can use the application as well without looking for it. What if your IT system automatically recommends his solution to you? That would be really great. We have developed a concept of so-called context-aware enterprise mashups that makes this vision happen. Based on the actual user context (social and environment), it automatically recommends relevant information-sentive services to react immediately on an event. Neither you have to switch between different applications nor you have to search for a business transaction. No installation and no programming skills are required.
In the following, we demonstrate the power of the dynamic enterprise mashups by means of a real-word scenario. If you are interested in the underlying technical details of the context-aware enterprise mashups, you find at the end of this article a brief introduction of the concept. In case you are not familar with the terms related to enterprise mashups such as widgets, resources, wiring, etc., please read first the introduction article about enterprise mashups.
The Power of Dynamic Enterprise Mashups
New and innovative concepts are really great. But what about the introduction in an application domain for demonstrating their power. By means of a real-world scenario a typical information worker in military organization is facing with, the video below shows the application of dynamic enterprise mashups.
Context-Aware Enterprise Mashups
Now, what is context and how can we model context-aware enterprise mashups? As indicated before, context entities can be interpeted as a person, place, or object. They can be structured along three domains:
Agent Domain (Who?). The first domain deals with the interacting agents (=users) within the community and their relationships. The agent domain represents all human users who make use of an enterprise mashup environment in their daily work. These agents act in a particular context which is determinate on their position (i.e. sales manager) in the company. It includes information such as the department (specialized division of the business organization where the user is working for, i.e. sales department), country (where the department is located at, i.e. Switzerland), or the industry (i.e. manufacturing). Besides this working related context information of the agent domain, the social structure and agent preference are an addition context sources. In a similar way to social networks such as Facebook and Linkedin, users working in the same department consume similar mashups to solve their daily problems.
Computing Domain (What?). The computing domain handles the actual content of the mashup platform which is based on existing composition of widgets into mashups. It mainly includes the widgets and the wiring connections of their input and output ports. This domain builds the primary foundation for context-aware enterprise mashups. The popularity, the availability or the user rating of a mashable component directly influence the context-aware recommendation.
Environment Domain (Where?). The third and last domain addresses environmental aspects. A mashable component can be optimized for a particular environment spanning the device or the business purpose. A mobile device implicates other requirements than a portal application. First, the limitation on the resolution or the reduced bandwidth must be taken into consideration. Second, an enterprise mashup aims at a dedicated business purpose meaning an enterprise mashup is created for a special enterprise resource planing feature.
This kind of structure includes interrelation between entities that are within one domain but also the interaction between the three domains. However, an important aspect is missing so far, the time dimension. It has to be included in the context model in order to characterize a situation in the past and future. A current popularity characteristic of mashable component is more relevant than the statistic three years ago. An old component can be replaced by another one which fulfills the changing requirements in a better way.
Concrete context entities inside those domains can now be expressed as 4-tuples (Sun & Sauvola, 2003). A tuple is a sequence of specific values which are called the components of the tuple. The components of the 4-tuple result in entity name, feature, value and time. Each context entity is identified by its unique name. For the different entities various features can be defined. The two feature categories are internal and external features. Internal features are characteristics inside the entity in its domain. External features describe the context information concerning the interaction of the entity with other entities, i.e. activities. Besides the categorization, a feature may have a value of any significant type, e.g. scalar, vector, integration, string, etc. The value can also be another entity. The component time is mainly used to record history of context entities and to predict the future situation accordingly. It is optional.
The following listing shows how this domain model can be applied and how concrete entities can be expressed by means of the 4-tuples for each of the three domains:
Agent Domain
(MaxMeier, isColleagueOf, PeterMustermann)
(MaxMeier, isUsing, CustomerMappingMashup, 2010/03/04)
(MaxMeier, isUsing, GlobalStartPage, 2010/03/01)
Computing Domain
(CustomerMappingMashup, involves, CustomerData)
(CustomerMappingMashup, wasCreatedBy, MaxMeier, 2009/11/12)
(CustomerMappingMashup, isUsedIn, ERPStartPage)
Environment Domain
(ERPStartPage, isChildOf, GlobalStartPage)
(ERPStartPage, isUsedBy, MaxMeier, 2010/02/05)
(ERPStartPage, canBeUsedFor, CustomerMappingData)
The first three examples describe concrete context entities for the agent domain. The first example demonstrates an interaction of entities inside the domain. According to the definition of tuples for context representation, "MaxMeier" represents the entity name, "isColleagueOf" the feature, and "PeterMustermann" the value. Furthermore, this tuple has an internal feature, which means an interaction inside its domain. Because of that, the entity's value must be another entity, in this case "PeterMustermann". The item representing the time is missing in this tuple because it's not necessary to know the exact time of this activity (Remember that the time component is optional.). In contrast to the first example, the other two entities describe an interaction between domains. In the first case, it's the computing domain and in the second case it's the environment domain. In both cases, the feature is "isUsing" and represents an external feature, meaning an interacting between the two domains. In order to anticipate future events through interpretation, the time needs to be mentioned here. The other examples demonstrate the application of the context model for the computing and environment domain.
This generic context model allows modeling the context space for enterprise mashups. The question is now how to get the raw context data and how to interprete them to relevant context information for a dedicated situation.
The context organization and interpretation is structured by means of three layers as depicted in the figure above:
The first layer (Source Data) is sourced with raw data, like sensor or profile user data. The presented enterprise mashup ontology is resonsible to structure and to obtain the raw data. While interacting as an intermediary, sensors of the enterprise mashup environment collect the data provided by consumers (rating, tagging, etc.) and by providers (composition of mashable components, etc.). Sensors monitor the popularity and the availability of the components. Profiled data can be for example consumers's preferences about a special situation.
The second layer interpretes the raw context data by means of generating and building so-called Context Facts related to the situation. Context facts are something that exist and can be verified as true. They follow the before presented context model: "Max Meier is using the Customer Data Mapping Mashup", "The Customer Data Mapping Mashup is executed in the ERP Start Page", or "Customer Data Mapping Mashup uses the Customer Data Widget".
Finally, new situations can be interpreted (higher context) by describing context at a higher level than facts. Through sorting and weighting with special scores for each context fact, confidence of situations can be achieved (Scoring algorithm). An example for a situation is: "Max Meier recommends the widget Google Maps as the best widget for mapping addresses on a map in the ERP Start Page". This interpretation of the context facts allows expressing context characterized situations and allows extracting relevant information, like recommended widgets for users building enterprise mashups in the same ERP Start Page.
Context information is highly dynamic and makes it hard to create and apply adequate models. In order to provide an adequate computable model for the second layer, the Context Modeling Language (CML) is applied. It reformulates modeling concepts as extensions to the Object Role Language and assists designers to explore and specify requirements of context-aware applications. It is achieved by providing a graphical notation for describing types of information. Besides support of classification for context types (static, profiled, derived or sensed), relevant quality meta data and snapshots of historical events can also be represented.
The figure above models the context information and the types related to enterprise mashups. Solid ellipses represent all necessary context entities. The relationship between the entities is defined by roles and an association which is symbolized by connected boxes. Besides the visualization of the interaction and relationship between different context entities, it also includes capturing capabilities for user activities in the form of a fact type that covers historical activities. This historical point of view is completed by user activities. They include the used device and the acutal business purpose of the executed and created enterprise mashup.
Thanks to the computable context facts model, the situation can now be derived. They are defined in terms of context facts and logical connectives (and, or, not, exists, for all) of the relevant entities. According to the determined context facts, a situation could be that the widget "Google Maps" is a recommended widget to show the customers address on a map. Without interpretation, the according context facts are only describing the quantity of how often the inport of the widget "Google Maps" is sourced with the address from a customer. But through interpretation, it's possible to say that if it's often used in this context.
Regarding from the perspective of the information worker, he only sees the recommendations which are determinated by means of a scoring algorithm. The user interface is depicted in the figure below.
Readings:
Sun, J.-Z., & Sauvola, J. (2003). Towards a Conceptual Model for Context-aware Adaptive Services. Paper presented at the 4th International Conference on Parallel and Distributed Computing, Applications and Technologies, Chengdu, China.
Gilles, F., Hoyer, V., Janner, T., & Stanoesvka-Slabeva, K. (2009). Lightweight Composition of Ad-hoc enterprise-class Applications with Context-aware Enterprise Mashups. Paper presented at the 1st International Workshop on User-Generated-Services (UGS) in conjunction with the International Conference on Service-Oriented Computing (ICSOC), Stockholm, Sweden.
- SAP Managed Tags:
3 Comments
