That’s the question. We’re going to assume that since you’re reading this blog, you have an interest in, work for, or run some kind of publishing company. Presumably, you create Things that you sell to People. Presumably you’re successful at that becuase you’re in business. Presumably the People like the Things you produce because they’re buying them, which allows you to stay in business. Presumably you know how to produce those Things because you keep making more of them for People to buy. Presumably you, your colleagues, your managers, and your staff all know what they’re supposed to be doing in order to make those Things that you eventually sell to People.
So why would you want to screw with that?
Maybe it takes too long to make the Things. Maybe it’s very complicated with many steps and you, your colleagues, your managers, and your staff get angry and upset and have to work lots of overtime. Maybe your competitors can make more Things faster and you’re losing the People who used to buy from you. Maybe your Things aren’t as good as they used to be.
Why XML? It depends on what you think needs to be changed. Do you want a simpler workflow? More products coming out in shorter timeframes? To spend less on producing the products? Can XML really help with any of that?
Because you know, and this isn’t a secret, XML isn’t anything more than a markup standard. It’s not even a file format. It’s a text file with lots of pointy brackets in it. By itself, an XML file just kind of sits there, bristling with pointy brackets, taunting you, daring you to figure out what to do with it.
And that’s the trick. What, exactly, do you want to do? Because this is going to be expensive. You’re either going to have to buy lots of stuff, hire somebody to program lots of stuff for you, or hire somebody to take your box of 8-tracks and return the excellent Things you sell, without telling you how they did it.
In other words, you’re going to have to
1) Buy, configure, test, train on, and support the equipment and software required for an XML workflow;
2) Hire a consultant to do all of the above for you, or;
3) Hire a vendor to do all the XML workflow stuff at their plant, so you don’t have to deal with any of it.
You’d do number 3 if you have isolated projects that don’t have anything to do with your normal workflows. Maybe you have 25,000 old documents that have to be converted for web use. You don’t want to invest in an expensive system if you’re only going to use it once or twice.
You’d do 1 or 2 if you produce something, and are going to continue producing it for the long term. 1 and 2 get you to the same place eventually: a system that you own and control. If you have or want to hire the people to build it, then 1 works. If you don’t then 2 is probably a better idea. In either case, though, you’ll need people who can keep the system running after the initial build and testing phase is over.
1 and 2 aren’t mutually exclusive either. We did a combination. We had some in-house experts doing some of the work, and we hired some outside consultants and vendors to do the rest of it.
So why XML? XML can help simplify workflows, speed time to market, help with quality, and save money in the long run. But you have to build a system that stores and manipulates the XML first. That’s going to be expensive and take some time. And the only way you’re going to be able to spend that money and take that time is to make sure that the people running the company are behind the project. You need a good business case. That’ll be the topic of my next ramblings: How To Make Friends and Influence People.
Filed under: XML |