ONE OF THE perennial questions for IT executives considering enterprise systems is "build, buy, or outsource?" The question
has become so common that it's a clichè.
There are several reasons to consider building a system, the chief ones being control, flexibility, and extensibility. But
with full control over the environment comes the substantial costs of in-house staffing, hardware, and software. Often, the
key parts of an internally developed system are understood by a small group of people who do not like writing documentation.
On the buy side of the equation, you get packaged and supported software that will hopefully do 80 percent of what you need,
but in most cases the software you buy has never been used in an organization exactly like yours, so there's always a risk
that things won't turn out as you expected.
Outsourcing can be a good way to get something up and running quickly, but the loss of control and flexibility can be limiting.
As a CTO, I want maximum flexibility, minimum cost, and an elegant and open system, but I don't really want to be responsible
for its day-to-day operation. As a former developer, I want the ability to interact with a rich API, to get under the hood,
and to turn some dials, which will allow me to leverage a good system into a flexible one that serves the specific needs of
my business.
Fortunately for both the developer and the CTO, a number of "software as service" ASPs have created rich Web services APIs
for their systems that give you all the benefits of outsourcing with most of the benefits of an internally built or bought
system. Until recently, conventional wisdom dictated that Web services were mostly inside-the-firewall phenomena, and most
companies were waiting to dip their toes into Web services as an interface to other companies' services over the Internet.
Some of the early experimentation with Web services occurred in applications that were not mission-critical, as developers
embraced services such as the Google Web API and Amazon's Web Services programs. From what I'm seeing now in the real world
of running IT, the tide has turned as mission-critical applications of Web services outside the firewall come to fruition,
giving CTOs and their teams unprecedented flexibility and cost-effectiveness with outsourced software solutions.
At InfoWorld, in just the past two weeks, we have rolled out two fully outsourced systems that provide XML-RPC (remote procedure
call) interfaces that will give us fine-grained control to extend the systems as needed. The old 80/20 rule still applies
(if you can get 80 percent of the functionality that you want out of an outsourced solution, it's good enough), but the Web
services interface to an outsourced system allows you to turn the 80/20 that ASPs have always provided into 90/10 -- or better.
One of the two systems we rolled out was Salesforce.com's Enterprise Edition, a sales force automation system that replaces
our aging legacy proprietary Lotus Notes-based system. Whereas the Salesforce.com product offers plenty of out-of-the-box
functionality and a nice Web interface for end-users, its XML-RPC API allows us to do almost anything on the development side
while maintaining the benefits of the outsourced arrangement, which makes me happy as CTO. Recently, one of our salespeople
requested a custom report to be e-mailed to him at an irregular interval, but that functionality wasn't available in the base
system. The XML-RPC API allows us to access the data we need and apply our own business logic and processes to it -- again,
going from 80/20 to 90/10 or better.
You can't beat that.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
