Migration of Your Data to XML

	Don Bridges
	Data Conversion Laboratory

Outline

	Who is DCL?
	What to convert?
	The business side of the equation
	How long will it take?
	What about Automated tools?
	How much will this cost?
	Data conversion process
		What should I look out for?
	Case Studies

Slide 3

Slide 4

Slide 5

Slide 6

Slide 7

What to Convert?

	Option 1: Convert nothing
		No conversion costs
		Delayed ROI
	Option 2: Convert everything
		High conversion costs
		Reduced ROI
	Option 3: Convert ‘frequently used’ documents
		Some conversion costs
		Maximized ROI

Convert with intelligence!

	Convert documents that are most used
		They will have the most re-usability
		ROI will be demonstrated faster
	Convert documents that are customer favorites
		They will enable customer satisfaction
		Don’t forget: Customers are internal and external
	Convert documents with longest product life
		You’ll reap the investment longer
	When in doubt start in the present and go back

Return on Investment

Business Benefits of XML

	Increasing Revenue
		Increase Customer Satisfaction
		Decrease Time to Market
		Expansion into New Markets
	Decreasing Expenses
		Increasing Authoring Productivity
		Reducing Publishing Costs
		Increasing Information Reuse
		Reducing Translation Costs
		Future-Proofing Data

Business Costs of XML

	Hardware
	Software
	Labor
		System Configuration
		Training
	Data Conversion

Resources on the Web

	The Business Case for XML
		by DCL
		www.dclab.com/businessxml.asp
	Building the Business Case for XML
		by Arbortext
		www.arbortext.com/html/webinars/webinar11_files/frame.htm
	XML Cost Savings Toolkit
		by Arbortext
		www.arbortext.com/html/cost_savings.html
	XML Business Case Calculator
		by SPX Valley Forge TIS
		www.vftis.com/presentations/SPX_Valley_Forge_bus_case_calc.xls

What about Schedule?

	Schedule depends on complexity of the project and resources available
		Is there a paradigm change?
		How good are your conversion tools?
			Set-up requirements
			How much post-conversion clean-up
	As a rule of thumb, plan on 3 - 5 minutes per page to clean-up and correct if the paradigm is consistent

Automated Tools

	Programming languages
		Flexible & powerful, but not always straightforward
		examples are XSLT, Omnimark, PERL, AWK
	Integrated packages
		most authoring packages have basic import tools (such as Interchange in Arbortext’s EPIC)
		typically not “industrial strength” tools
	Stand-alone tools
		most are format specific such as Filtrix (Blueberry), WebWorks (Quadralay), WorX (Hypervision)

Automated Tools

	So how good are they?  Yield will depend on three main factors:
		Consistency of input data
		How much of a paradigm change
		Flexibility of tool to your situation
			does your data have the ‘hard stuff’ (such as effectivity tagging, tables, cross references, headers, footers, equations, figures, etc..) and can the tool handle your data

Typical conversion issues

	Time to Market
		Can the world wait a year for you to be ready?
	Quality
		When you show it to the world, will you be proud?
	Cost
		Do you really know what it will cost?  Are you sure?
	Scalability
		Can you do thousands or millions of them the way  you did your demo?

Which way should you go?

	Data is so sensitive that it must stay internal
	Paradigm is consistent
	Your schedule is flexible
	Materials are not complex
		Clean-up requirements may vary widely
	Budget is tight & in-house resources available
		Tools are relatively cheap
	Project is small

Which way should you go?

	Paradigm is changing
	Meeting schedule is critical
	Materials are complex
		Demonstrate expected results while there is still time to make modifications
	Budget is well defined
		Understanding the project costs and the trade-offs
	Project is large
		Process scales as big as needed

DCL’s Conversion Methodology

	Project Engineering (Set-Up)
		Document Analysis
		Conversion Specification
		Pilot (Proof of Concept)
		QA Plan
		Production Planning
	Production
		Conversion
		Post Processing QA

Document Conversion - Flowchart

Slide 22

"Example:"

	Example:  Automated Links
		See figure 15.5
		See fig. 15.5
		Refer to figure below
		As illustrated on previous page
		… drawing 15.5 years at hard labor.
		See figure 15.1 in volume II of …

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Case Study 1

	GE Power Systems (Schnectady, NY)
	Manufacturer of gas turbine motors
	Migration from Interleaf to XML
	Very large volume of data and very demanding schedule did not allow for time to become data conversion experts

Case Study 2

	Mercury Marine (Fond du Loc, WI)
	Manufacturer of small boat motors
	Migration from Interleaf to XML
	Multiple languages, a very demanding schedule, and decomposing the data into elements complicated the issue.
	Change of paradigm

Case Study 3

	Schlumberger (Houston, TX)
	Oil field services company
	Migration from many formats (Word, Frame, Paper, etc..) to XML
	All technical and training documentation across multiple divisions migrated to a single DTD.  Consistency critical.
	Change of paradigm

Case Study 4

	BEA Systems (San Jose, CA)
	Application infrastructure software company
	40 writers and 400k pages of extremely consistent FrameMaker documents
	Requirement to provide daily update of data in HTML and PDF
	Utilize WebWorks for automated conversion that delivers converted content during nightly builds
	No change in their paradigm

Case Study 5

	Large electronics manufacturer
	Desktop Printer Division
	Migration of 250 pages from Frame to XML
	Utilized manual conversion as a method for tech writers to gain familiarity with XML. This approach was enabled by low volume and manpower availability.

Slide 37

Questions?  
       






Don Bridges
DCL Tech Doc Sales
dbridges@dclab.com
(505) 275-2223