A new metaphor for editing structured documents   Table of contents   Indexes   Realizing Parts Catalogs in a Web Environment Based on Graphic Objects
 

XML in the BMW Group: Sharing information components across the enterprise
 Simon   Watts
  Managing Consultant
  OpenMIND Consulting  77 Heyford Park, Upper Heyford
Bicester   Oxfordshire  United Kingdom  OX6 3HD
Phone: +44 1869 238080
Fax: +44 1869 238081
Email: swatts@open-mind.co.uk Web: www.open-mind.co.uk
 
Biographical notice:
 
Simon Watts is a Managing Consultant for OpenMIND Consulting (http://www.open-mind.co.uk ), a provider of corporate information solutions, data warehousing, data mining and risk management services.
information delivery
 
Simon runs the Information Delivery practice group at OpenMIND and is the lead information consultant in the ongoing BMW and Rover structured publishing project. As Project Manager, he successfully implemented the SGML solution at Technical Communication, Rover Group. Simon is also the founding chairman of the Astoria User Group.
 
Before working at OpenMIND, Simon spent ten years as a consultant working with a wide range of industries involved in object oriented technologies, publishing and translation.
 
ABSTRACT:
 
Since the purchase of Rover Group by BMW, great emphasis has been placed on the successful convergence between the two companies. A key part of the strategy are the information structures employed across the group rather than systems and platforms.
 
In this paper, I propose core goals and strategy for implementing enterprise wide structured information. The goals act as the compass for the project and provide a framework that will support measurable objectives. In exploring these goals I define the benefits that BMW expect from XML  (eXtensible Markup Language) , and the possibilities that are anticipated in the future.
 
Drawing from the experience at BMW and Rover, I present a range of problems that obstruct progress in a cross cultural, cross organisation project. I look at techniques that help solve these problems. However, with the goals and strategy firmly in mind I will develop a coherent approach that can bring shared information into production.
 
Topics discussed include:
  •  The need to identify at an early stage where the primary reuse of information lies
  •  Defining or changing ownership of information
  •  Methods of information interchange
 
For those who contemplate starting an enterprise wide shared information project it is invaluable to learn from the experiences of others. This paper will provide a possible framework on which others can base successful implementations.
 

Introduction
 
This presentation will discuss the current BMW and Rover Group initiative to put service information on-line for the global dealer network. We will look at how the project has been defined and its direction and then we will focus on the techniques used to structure and deliver the information.
 convergence 
 
Both BMW and Rover have been using SGML  (Standard Generalized Markup Language) to successfully publish service information for a number of years. The two organisations have developed the same technology into two quite different systems and with the joining of the two companies it has become necessary to converge into a unified approach. Drawing from the experiences in structured publishing within the group, it was agreed that information would be the primary convergence platform rather than hardware or software. Beginning with that as our start point we were able to clearly define the nature of the on-line project and begin work.
compass
guiding principles
 

Project Compass
 
"Things which matter most must never be at the mercy of things which matter least". By Johann Wolfgan von Goethe.
 
Project compass may be an unusual phrase to use when describing project management. However, it is used purposefully to describe the overall direction and governance of a project beyond defining and working to objectives. In initially scoping the project we identified guiding principles that would help us deliver information to the person who needs it, when he needs it, and that this should be available to all dealerships.
cultural change
vision
 

Understanding the Vision
 
A project of this nature is more than just developing a solution. It is also blending the needs of two organisations, each with a different approach to the business and different cultures, who share a commitment to quality. Our focus is helping the dealer to serve the customers better and to provide the customer with a very positive experience. This project will enhance the service operation within dealerships by providing service engineers with specific information, such as:
  •  Service Jobs
     The range of actions that must be carried out to complete a specific vehicle maintenance task, such as Changing the Cylinder Head Gasket.
  •  Vehicle Systems
     The large complex systems that make up a production vehicle, such as engine or electrical.
  •  Parts
     Specific components required by a service job.
  •  Tools
     Any special tools that are specifically required by this service job.
 
We believe that XML is an ideal technology to:
  •  deliver this information to the person who needs it most
  •  to be able to update it quickly
  •  to be able to control the level of information each user sees based on their role
 
For example, when a customer brings in a BMW Series III for a 30,000 mile service, the service engineer will be able to query his system based on the vehicle configuration. He will receive all information related to the service jobs for a 30,000 mile service. In addition, he will be able to access a list of tools and specific parts with their part numbers that are required for the job.
 
With XML it will be possible for a service engineer to extract all the discreet pieces of service information that he requires to complete his job. He will not have to conduct an extensive search as related information will be offered based on his level of experience, the customer's vehicle and the type of job.
foundation
project scope
 

Project Scope
 
Delivery of a working XML solution for service engineers will provide a strong foundation for many other solutions within the dealership.
 
However, we must create the foundation first and our vision of providing a personalised after sales experience for BMW and Rover customers is the basis.
 interchange 
ownership
 processes 
 reuse 
 
The project must focus on four key areas:
  1.  Reuse
  2.  Ownership
  3.  Interchange
  4.  Processes
 
In addition, the project must support the following types of information:
  •  service information chunks
  •  vehicle configuration
  •  parts
  •  special tools
  •  descriptive text relating to vehicle systems and components
 
Each of these information types is designed with the four key areas in mind.
 reuse 
 

Planning for Reuse
 
The initial consideration is how an information type will be used, because this in turn defines its capability for reuse. When we examine an information type we must ask a series of questions, such as:
  •  How is the information shared?
  •  What is common between the organisational approaches to the information?
  •  How can the common part be reused whilst specific requirements are still supported?
 
Let's apply this to configuration information. Both BMW and Rover use configuration meta-data to uniquely identify the systems and components within a vehicle. Once defined, this information can be used to apply a piece of service information such as a service procedure to that component. For example, if the removal and refit of an engine is affected by whether the customer has an air-conditioning unit fitted on the car, there would be two versions of the service procedure:
  1.  the steps required to remove and refit an engine with air-con
  2.  the steps required to remove and refit an engine without air-con
 
We add configuration meta-data to each procedure to control which procedure is displayed. The delivery of the information is dependant on the customer's vehicle configuration entered by the service engineer.
 
As we examine the different types of configuration information collected by the organisation it's clear that there are three collections that must be supported:
  1.  Common configuration meta-data
  2.  Unique BMW attributes
  3.  Unique Rover attributes
 
Our design must force the collection of common data and must optionally allow the collection of both organisation data sets. For the data to be consistent each configuration item must be drawn from a validated list which is accessible to authors. The same data must be provided to the engineer to ensure that he can consistently select the information.
 
Working with XML we have been able to create a structure that allows the use and capture of both the common and specific configuration information through each part of the group. Using the correct structure these can exist together.
 
Depending on who is viewing or using the information, the relevant individual configuration information can be presented along with the common.
 convergence 
 

Convergence Issues
 
We have had to address a number of areas to ensure that the solution can be used effectively throughout the organisation. These are:
  •  Naming conventions
  •  Cultural business terms
  •  Language
 
Each of these points presents their own problems. We agreed that it is important to define a standard which the whole organisation will adhere to. Each organisation uses different terms which are widely recognised in their own business. Our approach has been to blend the terms used. In some cases we adopt new terms which retain meaning for the entire business but reinforce the fact that this is now a shared approach to information creation. Also, while it is possible to maintain multiple language versions of an information structure, we have elected to use English terms for our storage and use these English terms to support the author environment. However, we have not yet decided whether it is appropriate to force dealerships to work with information elements named and described in the English language or whether it would be better to support them in their native languages.
information ownership
 

Information Ownership
 
Each information type that will be created, stored and delivered using this solution may be owned by different parts of the organisation. For example, configuration information is not owned by authors but is owned by the parts department. Authors however do own the service procedures and descriptions of each component as presented in service maintenance and repair publications.
 
Having identified the owner of an information type we must involve them in the design and prototype phases to ensure that we can collect the information and use it effectively.
 
In the case of configuration information we must construct a suitable validated feed of data from another system which we can then transform into a usable reuse tool to support the authors and the dealers. This has its own complexity. The ownership and maintenance of configuration information is also being converged, however this convergence may take place at a different speed to the dealer service solution. We must be prepared to draw configuration information from two sources in the organisation and manage the transformation into a single source for this project. Therefore, we have identified a need for an interchange mechanism that allows us to consistently move the information from one domain into another and allow reuse to occur from this secondary point. XML allow us to define module DTDs  (Document Type Definitions) that support the basic structure of configuration information. These modules can then be used within:
  •  Reuse pools
  •  Publishable information
  •  Interchange streams
 
Once the interchange has occurred we can be certain that the information is valid for reuse.
 interchange 
 

Information Interchange
 
As mentioned earlier, constructing an interchange mechanism allows us to draw data from other sources and transform it into a valid structure for our own use. Before XML the possibilities available to us included:
  •  export and processing of text files
  •  interaction with other databases
  •  the localised duplication of known data
 
 XML allows us to construct a usable source of information within our own domain but draw that information in the most efficient way possible from its source. In addition, the owners of information can control the distribution without providing direct access. Also it can be considerably cheaper to update a separate transformation process rather than one embedded within the application that maintains the source data. We are free then to construct an architecture where an interchange back plane uses XML to filter and transform information from varied sources into a consistent structure for our use. Our solution can then work through a single interface to the interchange back plane.
 
Where appropriate we can also make use of the interchange back plane to export data for other uses.
 processes 
 

Designing the Processes
change control
testing
 
While we can do a considerable amount with  XML and its related technologies it is still necessary to support a solution of this nature with business processes. From a project perspective it is vital that we manage the evolution of DTDs that support the information types and the interchange back plane carefully and through formal change control. We must also approach testing in a methodical and tactical manner. Perhaps more importantly the project must also deliver processes that support the creation, maintenance and distribution of the information in the production environment. Processes that must be created include:
  •  Creation and maintenance of reusable information
  •  Migration of single use information into reusable information
  •  Configuration management and distribution
 
Each of these processes must be tested during the development phase of the project and are designed to ease the adoption of this convergence.
prototype
 

Building Prototypes
 
This project is based around the construction of prototypes which are both evolutionary and incremental. Each prototype may explore alternative approaches to a particular problem. Using our configuration information example, our prototype must support:
  •  the inward interchange of the information
  •  its storage in a reusable information pool
  •  presentation of the information to the author
  •  indexing of the publishable components in the delivery to support fast and varied access
 
Our early prototypes allow us to identify problems in all these areas and additionally help refine processes and understand the issues involved in restricted authoring. Our prototypes have three aspects:
  1.  creation environment
  2.  interchange environment
  3.  delivery environment
 
The creation environment is based on existing tools in both organisations. It works through a traditional authoring approach where an editing tool enforces the rules provided within the  DTD  (Document Type Definition) . It may be augmented through the use of lists of validated terms to support the authors.
 
The interchange environment enables different parts of the organisation to provide information to one another. It ensures that all the information remains valid both to the sender and receiver.
 
The delivery environment controls how the information is distributed to the end user. One constraint is that dealerships should not have high-cost implementations imposed on them. We intend to make use of existing technology wherever possible which has a very low or zero per seat cost. It is important that the information is chunked correctly to facilitate the speed of delivery. We deliver a large volume of graphics which may be line drawings or photographs. We can use meta-data to control the presentation of the graphic. For example, large graphics can be presented as a thumbnail initially. This will provide a quick download and if the engineer requires the full image, a reference can be clicked to download the entire graphic just as many web pages do now. However, this behaviour can be built in at source in the XML rather than hard coded into  HTML  (Hypertext Markup Language) .
 

Conclusion
 
We have continued to learn from our experiences in this project. The early steps of understanding the corporate vision and breaking that into achievable goals has allowed us to control the scope of the project. It is vital to the success of this project that we do not try to achieve too much in our initial delivery, but provide a foundational solution that delivers real benefit to the dealers and supports the integration of further systems and convergence work.
 
 XML offers us an exciting opportunity to bring the benefits of structured information to the point of use. We expect to improve not just the delivery, but also the interchange of information. We expect this technology to help us gather better feedback from the dealer network. Also, our phased approach allows us to benefit from the continuing evolution of XML and its tools.
 
What remains ahead of us is the bulk of the hard work but our project compass helps us move in the right direction. By next year's conference we will have delivered our production solution and will no doubt be considerably wiser.
A new metaphor for editing structured documents   Table of contents   Indexes   Realizing Parts Catalogs in a Web Environment Based on Graphic Objects