Doug Gorman, Simply XML

Gorman_1Gorman_2

My family has a house on Cape Cod, in Chatham.  This small fishing town has become the Shark Center of the Northeast.  Sharks are generally submerged and mostly a danger if you are a seal or are swimming with the seals.  I’ve never seen one from our boat, but my kids have—twice—while I was working. But I’ve got a New England accented “Shaaaaakkkk” T-shirt, and we’ve had summer guests who were at times less than enthusiastic about swimming in the ocean.  The shark on the right chased its prey up onto the beach and got stuck, then rescued. You may have seen it on the national news or read about it on the web or in the Wall Street Journal.  Shark information is always a big sell.  The shark on the left traumatized first the town of Amity Island and then a significant subset of the world population who went to see the movie.

It is the 40th anniversary of Jaws (music playing dododododododododo).  In the hope of breaking the use of modern XML architectures and tools out of TechPubs, in the same way that Jaws shattered box office records, let’s see what we can learn from the movie.

Defining the Menace

Instead of miscellaneous body parts washing up on the beach, your problem might start off by realizing that a customer is getting conflicting information from your company or that you are paying to translate the same content over and over again because of the way it is organized.  Or maybe your technical staff is spending huge amounts of time and money re-architecting content so it can be published with your corporate look and feel.  Maybe your engineering content is late and irrelevant to the content supply chain.  Perhaps a customer CEO’s staff sees that proposals and reports from your consulting company don’t have a consistent look and feel, but, more importantly, there is no consistency in the content itself.  The menace seems really bad but you know there must be a solution.

Seeing the Vision—You are going to need a bigger boat!

About halfway through the movie, Chief Brody says the famous line, “You are going to need a bigger boat.”  He has seen the problem and realizes they will need a bigger boat.

And so it is with your required efforts to serve customers and save money with information reuse and flexible publishing.  You are going to need to bring more people into the mix.  People in marketing, compliance, manufacturing, and translation will need to be brought along into this new XML architecture.  So you are going to need a bigger boat.

You are going to need a better boat!

But the technology tools and systems required can be much simpler, more incremental, and more familiar to your staff.  The better boat includes an information standard that gives writers just enough structure of a common nature and use of authoring, repository, and publishing tools that you have in place. It necessarily involves any authoring, repository, or publishing tool that supports the Content Supply Chain. So, the better boat includes one or more shared repositories and support across the board for your organization’s publishing look and feel.   And bringing others into formalized workflow for creation, editing, and review will improve both efficiency and compliance.

You should be able to leverage the many tools that you have in place.  Technical staff can continue to use the XML editors that they like. But most authors work in MS Word and like it, so keep it with some add-on tools.  And you’ve probably got SharePoint, Alfresco, Componize, Documentum, or other shared repositories hanging around in the summer doldrums, underutilized.

Budgeting for the Hunt

Please don’t let your boss multiply the per person cost of what was just spent on software and consultants in Tech Pubs by the number of people who necessarily provide the larger amount of content.  You can use your existing hardware and implement your new architecture with a bit of new authoring software and some new processes.  Down the road, your content architecture will be consistent, and you can tie it all together with shared repositories in the cloud or on your servers.

And it won’t take a million dollar army of consultants to teach your staff how to consistently structure content according to a common standard.  However, it will pay for you to take advantage of the skills and expertise of consultants who have seen success in other organizations with similar challenges.

Jumping in

You are going to make huge improvements to your company with an appropriate incremental investment.  These improvements mean change, and people are going to be scared.  Some will be afraid to go into the water.  And some will try to convince others that it will never work.  Don’t let them hold up your progress.  “Come on in, the water is fine.”  Don’t be held hostage to what is possible. Be positive and realistic. Look for many small successes along the way.

Conclusion

If you keep implementation simple and appropriate you will succeed.

  • Create a simple and appropriate information architecture
  • Let groups that need more complexity get there, but under the same base architecture
  • Use your current tools and staff where possible
  • Work with outside consultants and vendors who have relevant experience and a similar orientation.
  • Don’t forget that this is not about implementing XML or DITA. It is about achieving flexible publishing and reuse in an efficient and effective way.

So stop being afraid of the sharks and enjoy the final days of summer and early fall.