Go single vendor or go toolbox? (build vs buy)

Summary: Do you build or buy? What's the true cost of integrating different product from different vendors? What are the ramifications for integration and process flow? And how do you make that determination?

Recently I've had the opportunity to think about my first single-sourcing project and the way we went about it.

Silicon Valley is notorious for being a difficult place to sell software into: You can't throw a rock on the street without hitting 10 software engineers (today, 3 of them are looking for work). And, as a result, there's culture of do-it-yourself that is magnified because implementation and customization work is work that software engineers do.  Although this situation is magnified in the valley, it's not unique to it. In this economic climate, the pressure to leverage existing resources is tremendous everywhere.

So I took the time to sit back, think about what our true costs were to do things the way we did. It's the classic discussion: build vs buy. And, until the last several years, I'd thought we'd done it right.

Now, I'm convinced we didn't.

The cost of building

As a full-time employee, hired to make the project come together, I saw the cost of the tools as the only cost. I saw the resources at my disposal—me, IT, people I knew in engineering, the skills and technical bent of the writers in the group—and I saw the cost of tools vs the cost of the enterprise system. We had done a deep dive into the organizational requirements we'd need to get it done. We knew how content was created and delivered in every part of our organization.  However, because I didn't socialize it properly—because I let myself and my management be distracted by the technology—it took far longer to complete and cost far more than it should have.

While I can say I learned a lot through trial by fire, the full cost of implementing the system the way we did was a lot higher than the cost of purchase would have been.

Most Techpubs departments don't get the luxury of having a software engineer dedicated to their needs. Writers are typically tasked to add tool admin and implementation to their ever growing list of responsibilities. Many writers stop being writers entirely. The don't get to generate, architect, and design the company's information strategy, they end up tied to implementing and maintaining the toolset.

This gets more and more difficult the more content you have. As the need for a real information architect grows—as it always does—the ability for that tools-focused writer to have any part of the content side of things falls away to nothing.

It took 4 years from concept to stable, production environment. The costs included my salary over those years. The time from several IT staff members at the beginning and over time sustaining and making process changes. The time from engineering staff who were co-opted here and there along the way. The time from engineering staff was an invisible cost—it didn't show but it diverted their much more valuable time from product development to tool implementation and maintenance.  This is one cost that is extremely expensive to the company that we're all quick to ignore when we're not thinking of the larger business needs.

If we had gone the enterprise route, bought a 'system' that we could leverage out of the box, we'd have seen ROI in 2.

4 vs. 2: That's an expensive lesson.

In this economic climate, it's very easy to ignore the hidden costs of toolbox solutions. Enterprise solutions are more expensive than toolbox solutions, but they have a different goal—for a reason. And worse still, it's easy to be distracted by the technology and miss the organizational needs that drive the need for a single sourcing system.

The value in buying

There is value in things like these:

• Eliminating manual effort
• Simplifying product version– or configuration-specific deliverables
• Tracking when product changes requires documentation updates
• Automatically identifying all affected documents when changes occur
• Integrating all of the components up front and building solutions that work together out of the box.

Every situation is different. If you've got a software engineer, or a writer that wants to be one, then your choices are different from the group that doesn't have the funding to get support from IT. Doing more with less applies to products as much as to staff members. Less hassle, less implementation work, less sustaining costs year after year all mean that you are doing more with less.

In an enterprise solution like Arbortext, everything is tested together, deployed together, and upgraded together. In other words, enterprise software vendors have done the work of building the system so that you don’t have to.

Learn more