The CIO Code

I had the pleasure of joining a few folks at the ASAE Tech Swap on 12/9 last week. The topic was on Build or Buy. I think if we talk about this again, we’ll probably be using new terms, as our exploration touched upon the very rich continuum regarding constructing new sofware vs acquiring existing software. I’ve been thinking about what new words we might use. . .

A term that was new to me in this context was the word “adopt” to designate acquiring software without performing modifications to it. I like this terms because it implies you aren’t doing anything to the original. The paradigm for this acquisition strategy is to purchase something like QuickBooks that possesses a built-in business process that organizations are unlikely to modify.

In the continuum of adopt vs build, we identified several points:

• Adopt and do nothing (e.g., Microsoft Word, PowerPoint)
• Adopt and configure to suit business practices within the application (e.g., Salesforce)
• Adopt and configure to suit using consultants (e.g., Microsoft CRM)
• Acquire commercial software and customize (e.g., SharePoint, Raiser’s Edge, most association management systems)
• Acquire open source software and customize (e.g., Moogle, Drupal)
• Build using an application server to accelerate development (e.g., Cold Fusion)
• Build using proprietary or open source components to accelerate development (e.g., corporate class libraries)
• Build from scratch using class libraries and design patterns (e.g., Microsoft MVC, factory patterns, AJAX libraries)
• Build from scratch using core libraries (e.g., develop unique base patterns)

These examples are archetypes which won’t hold up under the closest scrutiny. Microsoft Word, for instance, has extensive capabilities to customize and configure. That being said, I believe most people who purchase Word do so to gain its innate capabilities, not because of its ability to support macros and .NET development.

In working towards a set of criteria to make this choice, let’s remember the fundamental goal: what is the most cost effective means to achieve a business end?

The answer to that question is too big for any single entry, but here are some of the factors that can go into answering the question:

• At what level does the functionality you seek exist already?
• What is the cost to implement existing functionality?
• What is the cost to modify functionality to match yours?
• To what extent are your business practices a strategically valuable differentiator?

The answer to these questions? The process of real examination of business practices, both existing and desired, in-depth requirements analysis, attention to, but not limitations of existing skill sets, and, above all, razor-sharp focus on strategic outcomes. It’s easy to get lost in the weeds of a decision like this. Let’s just make sure when it comes to making this decision, we don’t lose sight of what we are trying to accomplish.

There’s more to come. . .

Have you developed any rules of thumb for software acquisition? Let me know your stories!

For more information on the ASAE Tech Swaps, check out the ASAE Calendar of Events: http://www.asaecenter.org/programsevents/calendar.cfm?CalendarID=15482&navItemNumber=14535&navItemNumber=24387

Also, put the ASAE 2010 Technology Conference on your calendar for February 10-12 here at the Washington Convention Center. There is more information at ASAE: http://www.asaecenter.org/ProgramsEvents/EventDetail.cfm?EventID=675695