The Next Big Thing
Posts about next generation technologies and their effect on business.

Serious Gaming and IT

serious gaming.pngLast month there was a humorous piece written in InformationWeek magazine that I am still thinking about titled: Forget Farmville: We Need CIO-Ville Or Call Of CIO Duty. The article was describing at the use of serious gaming techniques to train IT personnel – in this case the CIO. Well, it was really poking fun at the CIO role and what a game would have to actual simulate. There is a serious side here though...

 

The “digital natives” joining most organizations are comfortable developing experience with simulation and modeling techniques. They’ve had computers only a keyboard away since birth. Why not simulate the role! The military has been doing serious gaming for decades.

 

If you remember early computer gaming, there was a game that Henry Kissinger loved called “Diplomacy”. I played it a few times and it could be the template for the game the article described. It seemed too much like work to me back then. On the other hand there are thousands of people who play Microsoft Flight Simulator in realistic modes with air traffic controllers… Even people who fly for a living. At least if you make a mistake there you can always “do over”.

Why Not Use UML to Model Everything?

UML (Unified Modeling Language) provides a powerful capability for modeling software systems.  The various modeling elements and views, along with an extensibility mechanism, can be applied for modeling other systems.  So why not use UML to model any system? Users would only need to buy one modeling tool, and the market for UML tools would be expanded.


Standard extensions of UML for specialized applications are called "UML profiles."  OMG (Object Management Group) has defined a number of UML profiles.  For example, there is a UML profile for modeling physical systems called SysML, a UML profile for modeling software development processes called SPEM (Software Process Engineering Metamodel), a UML profile that extends UML for specification and integration of services called SoaML, and a UML profile for DODAF (Department of Defense Architecture Framework) and MODAF (Ministry of Defense Architecture Framework) called UPDM.  


A UML profile can be imported into a standard UML tool to create a specialized modeling environment.  UML tools support views (graphical displays) that are appropriate to a variety of modeling applications.  The extensibility mechanisms of UML enable existing UML elements to be adapted as new types of model elements and attributes.  While a UML tool may be able to support useful diagrams, in the long-term users will suffer from a limited modeling capability.


There are three basic limitations: (1) the UML modeling elements were designed to represent the concepts of a software system design, (2) the graphical representations are not designed for most effective human understanding of the models, and (3) a UML tool does not provide the computational support for structural consistency and functional analysis.


One of the problems encountered in the design of a UML profile is the design baggage that restricts the use of UML elements.  Design of a UML profile (a specialized language) requires deep knowledge of the design of UML in order to work around these restrictions.  The result is a compromise that provides a less than ideal representation of the problem domain.  The semantics of the profile are in the profile documentation and minds of the users.  The tool only reflects the semantics of software design. 


UML does not provide good quality graphical representations for modeling software, and this does not get any better for UML profiles.  An excellent paper by Daniel L. Moody, "The Physics of Notation: Towards a Scientific Basis for Constructing Visual Notations in Software Engineering," refers to UML for examples of the ineffective use of graphical notation.  Users should be able to quickly associate the graphical representation of a concept with its semantics.  In many cases UML makes very limited use of visual variables, thus obscuring semantic distinctions, and in many cases combinations of these variables create complexity.  For example, combinations of three visual variables (shape, brightness and texture) are used to distinguish 20 different types of relationships in a UML class diagram.  In a UML profile, a text label is often used to identify a concept.  Text requires less efficient, serial human interpretation (reading) while distinctions using graphical shapes are interpreted through parallel, image recognition.  As a result, good graphics make it easier and faster for users to grasp the meaning of a diagram.


Perhaps the most important limitation of a UML profile is that the modeling tool does not provide computational support for structural consistency and functional analysis of the model.  Enforcement of structural consistency of the model using a UML profile is based on consistency of UML software design models.


A good modeling tool will help the user develop a consistent and complete model.  Furthermore, a robust tool will assist in the analysis and improvement of the model.  For example, BPMN 2.0 (not a UML profile) defines a modeling language for specification of business processes. This includes modeling of executable processes and choreographies-interactions between participants supported by their executable internal processes.  A good BPMN tool will support analysis of compliance of an internal process with the requirements of interactions specified by a choreography.  A robust tool might also provide simulation capabilities to analyze the flow of business transactions. 


These functional capabilities are not defined by the standard, but will be developed as differentiators by the modeling tool vendors.  Addition of such functional capabilities for a UML profile would require implementation of functionality that may not be consistent with the use of the tool for generic UML.  The resulting profile language would still not be the best representation and visualization of the problem domain. 


The development of UML profiles may provide a quick and cheap solution to modeling new problem domains, but, in the long term, it provides less effective domain representation and visualizations, and it undermines the market incentives for development of functionality that improves modeling efficiency and the quality of results.

Integration of Business Models as Viewpoints on an Enterprise Architecture

Existing business models provide useful abstractions of the design and operation of an enterprise.  However, optimization of the enterprise requires multiple viewpoints, and these viewpoints must reflect a consistent underlying design.  Integrated models are essential to management of continuous change and optimization at an enterprise level.


When each viewpoint represents the current state of the enterprise, then the enterprise itself determines the consistency of the viewpoints.  However, when we consider a future state of the enterprise, there is a need for a unified representation of the future state to ensure that the viewpoints are consistent.  This is essential for a full understanding of the implications of changes since changes from one viewpoint will likely have effects in other viewpoints. 


In the Object Management Group (OMG) we have developed and continue to develop specifications for business modeling viewpoints.  These define models that are useful as stand-alone abstractions of the business, and support the development of viable software products.  However, there is increasing concern that these models should be integrated-that they should be viewpoints on a more comprehensive model of the enterprise architecture.


The OMG recently chartered an Architecture Ecosystem special interest group to consider approaches to integration of models.  Preferably the solution would support integration of not only models defined by OMG, but other models as well.  So the solution should not require changes to existing modeling specifications, but should provide a means to integrate heterogeneous modeling technologies.


Integration of these models involves aligning the representation of the same concepts that occur in different models.  Sometimes the same concept will have different names, and sometimes the same name will be used for different concepts.  Sometimes the same business entity appears differently in different viewpoints.  Consequently, the reconciliation of model elements becomes an issue of semantics-their meanings.  If elements from two viewpoints represent the same thing, then they should be represented once in the integrated, enterprise architecture model.


There has been a lot of discussion about semantics.  Should OMG specifications be represented in RDF (Resource Description Framework)?  Should the integrated enterprise model be a semantic model?  How do the OMG SBVR (Semantics of Business Vocabulary and Rules) and the ODM (Ontology Definition Metamodel) specifications fit into this picture.  How big would a semantic model be?  Does it only represent concepts that appear in viewpoints, or does it require the representation of related concepts in order to properly qualify the concepts of interest. 


I think we need to back up a bit and consider the problem we are trying to solve.  Ultimately we want a model of the enterprise that supports multiple viewpoints, stored in a database to be accessed and updated from multiple viewpoints.  So let's think about this as a database problem.


There's nothing new about views of a database.  A view defines a subset of the database that supports a certain purpose.  So each modeling viewpoint needs to have a view of the database to store or display that model. 


But first we will need a data model for the enterprise model database.  The database must store a union of the sets of data elements that make up the viewpoint models.  The challenge is to reconcile the elements that represent the same concepts in different viewpoints.  For that we need semantics.  We can consider if that means we need to create a semantic model or just a mapping of data elements performed by humans.


The other problem we must solve is the integration of updates.  If two or more modelers are working on different viewpoints that include some of the same business elements, what happens when they put their models back into the database?  Again this is not a new problem.  That's what locking is for.  When a viewpoint is retrieved, the elements are locked so that they can't be changed until the changed viewpoint is stored.  However, simple locking may prevent other modelers from doing their work, and changes to elements in one viewpoint may have implications to related elements in other viewpoints, so an update could make the enterprise model inconsistent. 


Consequently, there must be a discipline and supporting technology for updates that not only prevents conflicting updates, but provides a mechanism for reconciliation of changes that goes beyond the scope of changes made by a viewpoint.  This is similar to the problem of managing the development of engineering designs for complex products.


So I see these as two distinct problems: (1) defining the unified data model and mapping the viewpoints to it, and (2) reconciliation of updates.  I don't have the solutions, but I think this is a useful perspective for development of solutions.

Case Management for Managers

I listened to a podcast by Setrag Khoshafian of Pegasystems in which he talked about "Smart Case Management and CRM."  It struck me that case management has potential to improve continuity of service, efficiency and reliability in a number of contexts that may not be considered case management.


I like the following definition of case management presented by Singularity in a white paper entitled "Case Management: Combining Knowledge with Process: "


 "Case management is the management of long-lived collaborative processes that require co-ordination of knowledge, content, correspondence and resources to achieve a goal or objective. The path of execution cannot be pre-defined. Human judgment is required in determining how to proceed and the state of a case can be affected by external events."


 The goal of case management technology is to provide computer support for managing these ad hoc processes.  Henk de Man of Cordys provides an extensive review of past approaches to case management modeling in his BP Trends article Case Management: A Review of Modeling Approaches


In Setrag's discussion of smart case management, he describes using case management to manage a customer support interaction through participation of various organizations that otherwise might each provide their contribution within the scope of their own silo.  Case management can provide a unified view of the customer, the problem to be solved and the cumulative knowledge about that problem without each silo starting their analysis from scratch.  This also provides some opportunity to personalize the customer relationship as the solution is developed.  However, I see a greater opportunity that, I think, goes beyond Setrag's solution.


I see the opportunity for case management to provide continuity and personalization of service for the on-going customer relationship-an on-going case.  This is more like a primary physician's patient care that retains a patient history and incorporates knowledge of, not only the patient's current malady, but a complete file of the patient's problems, treatments and responses potentially over years.


This opens up many more possible applications of case management.  Look again at the Singularity definition.  Isn't this what managers do?  The difference is that unlike the common perception of business processes, management processes go on and on.  A manager has a collection of documents pertaining to his or her responsibility and the state of the organization, as well as a history of problems solved and initiatives completed-a manager's case file.  He or she manages various problems and initiatives to fulfill that responsibility, engaging the participation of others. The focus of the manager's case is the functional capability of the organization.  The manager collaborates with others, applies business knowledge and experience, and performs ad hoc planning and decision-making in pursuit of his or her business goals.  At the same time, the manager engages other employees and services, applies business policies and regulations, and must respond to various events both external events and those that arise in the operation of the organization.


Couldn't we approach any business responsibility in a similar manner?  It seems that this characterizes the job of a quality assurance manager, an information security manager, a vendor relationship manager, a strategic planning facilitator, the chair of a task force and many other on-going business responsibilities involving cross-enterprise collaboration.


The Object Management Group (OMG) has issued a Request for Proposals (RFP) for a Case Management Process Modeling specification.  Work on this specification is in the early stages.  I don't know if we can address this case-management-for-managers capability, but I think it's worth considering.

What Do Organization Structures Really Look Like?

Traditional organization charts typically depict the management hierarchy and maybe some committees and dotted line reporting relationships.  This is inadequate for today's organizations.  Today there are many more roles and relationships by which business actually gets done.  In general, we don't know what our business organization structures really look like.


I reported in August on a new specification proposed in response to the Organization Structure Metamodel RFP (Request for Proposals) issued by the OMG (Object Management Group).  The RFP seeks proposals for an organization structure modeling language.  This new proposal challenges traditional ways of representing organization structures.  Organization models typically focus on the management hierarchy of "business units" with annotations of some exceptions.  The new specification recognizes that these divisions, departments, groups, teams, etc., represent only one general type of relationship in an enterprise.  The following are additional types of relationships that should be considered.



  • Matrixed product development teams

  • Committees, task forces, work groups

  • Project teams, strategic initiative teams

  • Participants in business processes or choreographies

  • Business partner relationships, liaisons, contracts

  • Ad hoc collaborative relationships

  • Exchanges of materials, work products, business transactions


Each enterprise should consider the types of relationships of interest in an organization model and the amount of update activity this will require to keep the model current.


Each of these relationships has people involved in specific roles.  The relationships and the roles outline how work actually gets done.  Some of these relationships are relatively stable, and some are quite dynamic.  Most of them are not new, but have not been viewed as aspects of an organizational structure.  In a recent BP Trends article, "The Process Managed Org Chart: The End of Management and the Rise of Bioteams," Peter Fingar describes some radically different organizational structures that may involve additional types of relationships.


In the past it was necessary to make announcements or draw diagrams on paper and distribute copies in order to provide this information.  Today this information can be maintained by computer to be readily available to everyone who has a need to know.  We shouldn't need to keep track of who is doing what in our heads or send out email queries to find out from people we think may be informed.  Computers can manage the complexity of a model with many types of relationships, they can perform timely update and distribution of this information, and they can provide the selective display of information to meet particular needs.  A more robust model will provide better definition of responsibilities, and provide a more complete representation of the organization for planning, coordination and business transformation.


A modern enterprise should have an on-line, real-time organization model that is updated as the organization changes and reflects the relationships by which work is getting done.  Some updates may be accomplished by manual input as relationships are established.  Most updates should come from the systems that support these relationships such as business process management systems, project management systems and contract management systems.  This real-time model will not only provide information for people, but should support the operation of systems for reporting, exercise of control and coordination of activities.  Capture of this information in an integrated model will reduce administrative overhead and ensure consistency among different systems.  In addition, such an organization model may retain historical information on roles and relationships to help identify people with insights or experience from past relationships.


Enterprises need this information now.  It will become increasingly important as organizations continually change to meet new business challenges and establish relationships outside the traditional management hierarchy with shared services, outsourcing and virtual enterprises.

Search
Showing results for 
Search instead for 
Do you mean 
Follow Us
Featured
About the Author(s)
  • Steve Simske is an HP Fellow and Director in the Printing and Content Delivery Lab in Hewlett-Packard Labs, and is the Director and Chief Technologist for the HP Labs Security Printing and Imaging program.
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.