The division of labor at most companies is clear: Business development divines the big ideas, and IT toils to turn these concepts into workable software. And yet as far as IT's stature in the organization is concerned, this flow of ideas can no longer be in one direction and one direction only. In fact, the IT department that willfully assumes the role of order-taker is increasingly at risk of being outsourced.
Luckily for IT, being on the front lines of new technologies has its privileges. Marry this with an entrepreneurial spirit, and IT can assert a new relationship with the business by launching new, low-cost experiments geared toward exposing opportunities that those less familiar with today's technologies can't foresee.
But to be taken seriously by the suits, IT must move beyond mere tinkering; instead, purpose-driven testing and proven results, when brought back to the business team to help develop a plan that scales appropriately, is the key to shedding the "operations only" stigma and making the organization take notice of the ingenuity of IT.
Of course, developing a meaningful prototype requires more than just an understanding of the underlying technology. It takes a level of cost-benefit analysis and insight into new revenue outlets that may not be as easy as the IT department would like to believe. After all, balancing the competing interests of customers and suppliers is just as tricky as balancing the load of a server farm. Here is where ambition can get the best of you. To avoid getting burned, a small-scale, low-risk approach to experimentation is key.
Here are five technical areas where experimentation can help IT improve its stature with the business development team. These are just a few examples of how IT can grow beyond keeping the server LEDs on and show the suits IT is a valuable partner when it comes to initiating revenue-minded projects.
Find out what options may be open for your enterprise:
Low-risk IT experiment No. 1: APIs While some data must be kept secret, most information gets richer the more it is spread around. In fact, many Web companies trumpet the fact that they share some of their best data with others, even competitors. All it takes is the right call to their APIs.
Even the stodgiest 19th-century holdovers can benefit from releasing the right mixture of information through an API. All it takes is the ability to identify the information customers seek most and to build an API that reveals the right data to the right people at the right time.
In most cases, this information is already being delivered through a Web interface. An API would amount to the same information packaged in a programmer-friendly format such as XML or JSON. For example, a form on your Website can be recast as an API call to post data. Such an API would allow your business partners to automate the process of completing and submitting this form, thereby providing a deeper link between your Website and theirs.
Let's say your company requires registration for new customers. Turning this registration form into an API would enable your partners to register customers automatically. These clients can then gain access to the services of both companies, while both companies stand to greatly increase their customer base by working together through the use of this API.
Opening functions such as registration is easy; other data sources, however, require some care, as automation ceases to be a big help when it opens doors to spammers, bots, and other mixtures of minor and major fraud. Many APIs limit the number of times a partner can submit requests each day -- a simple barrier that can help ensure a mutually beneficial relationship. Companies such as Mashery.com aim to simplify many of the problems that can arise when you expose information in the form of APIs by offering simple throttling and authentication.
Finding the best way to work with other organizations via APIs is where the business development team can help. After the IT department has vetted possible features for the API, the business team can analyze the impact of the project, helping to guarantee that the company will gain maximum payback from this mode of opening data stores to partners.
An API, for instance, might save the company significant development costs if bundling information that way offloads meaningful development work onto its partners. Moreover, if the organization depends on the network effect to drive revenue through increased participation, for example, then the company can maximize its reach by pulling in as many new users as possible through the API. Opening up registration makes it easier for partners to share customers. If the goal is user-driven revenue, then the API should aim to convert users into paying customers by, say, limiting how much free information is available.
The side benefit is that API calls themselves produce plenty of worthwhile data that can be mined to support the bottom line. Even if the API calls are free, the patterns of requests could prove very valuable. Coupled with a NoSQL initiative (see "Low-risk IT experiment No. 5: NoSQL"), the data collected from API calls could surface unforeseen revenue opportunities.
All of these interactions begin with the tech team and end with polish from the business group. One opens up the data stream; the other decides how much to open the doors.
Low-risk IT experiment No. 2: Social networks Most business managers are already racking their brains trying to think of ways to unlock the power of social networks. More likely than not, your organization is no exception. Often the plans these business folks come up with are tricky and involve extensive programming -- but they don't need to. Some of the simplest solutions can be crafted with just a few extra HTML tags.
Twitter, for instance, makes it easy to link your content to Twitter posts with a simple URL: http://www.twitter.com/home?status=MESSAGE. Any message can be added to this URL, making it simple to add a button that allows visitors to share your Website's content or announce, say, their recent purchase of your goods to their followers.
Facebook offers a similar option for URLs that look like http://www.facebooks.com/sharer.php?u=URL= MESSAGE. Replacing the URL and MESSAGE will link up your site with Facebook.
These tricks help you avoid some of the more complex options offered by the social networks. When a user clicks on these links, they'll be taken to the respective social networking site to see if they're logged in. If they aren't, the site asks them to log in before letting them edit their message. In other words, the site handles the authentication, freeing you from the responsibility.
More sophisticated options, such as verifying the user's identity with a protocol called Oauth, offer more detailed integration and may be right for complete buildouts. At the beginning, though, they're not necessary. If the first round of experimentation proves useful, then the extras make sense. Again, start small, prove the sample case, and invite business development to contribute ideas once the results look promising.
After you've added these simple sharing buttons to existing Web pages, it may be worthwhile to analyze the propagation of these messages through your users' social networks. Such analysis can prove useful in planning for loads, designing marketing campaigns, and more. By understanding how users cluster around particular content, goods, or services rendered on your Website, your company will be better positioned to leverage these clusters to increase the exposure of your content, goods, or services to a broader audience, or to deepen the affinity existing users have for your company's offerings.
Unfortunately, using the simple links shown above won't leave you with any data for how the URLs move throughout the social networks. You can get around this limitation for the Facebook example by adding unique parameters to each URL before passing to Facebook. Then your log files will track the unique URL.
Low-cost IT experiment No. 3: Mobile apps The smartphone is now the dominant platform for roving users, and a well-tuned smartphone app can be both an advertisement and a real service to customers and end-users.
Creating smartphone apps, however, can be a headache. The demand for experienced mobile app developers is high, and some manufacturers, like Apple, are increasingly picky about what they allow on their devices.
A simple solution is to build a mobile-ready Website. Basic frameworks such as jQTouch make it easy to put together a site that displays information on Webkit browsers, such as those in use on iPhone and Android devices. All it takes is rewriting some HTML, and users will be able to search through your data conveniently on their phones.
This Web approach works well with APIs and doesn't require manufacturer approval of the content or the app. The user simply creates a bookmark to your smartphone Web page and the content does the rest. The jQTouch framework, for instance, lets you specify an icon that will appear on the user's phone just like an app from the app store. People who use their phone to visit your Web page can store the bookmark with this icon on their front page. It's another channel for distributing apps.
This approach will reward some businesses more than others. If your workers are on the go, then easy access to the company's Website from a smartphone will be popular. The key is to identify the data and transactions that matter most to these workers or to knowledge workers who frequently work away from their desks. Small-screen UI design is tricky, so it makes little sense to offer much beyond the most essential options.
In many cases, the IT department may not know what transactions are the best targets for the company's users. It may be valuable to confer with the sales force and business development team to help establish a game plan for exposing the appropriate data and services to users once you get your smartphone-friendly prototype in place.
Check out low-risk IT experiment No. 4: Geocoding
Low-risk IT experiment No. 4: Geocoding Every IT department has a database filled with tables, and every table could easily carry two extra columns. Latitude and longitude data are becoming increasingly easier to gather these days, thanks to smartphones and browsers that report users' locations. Why not use this information to enrich your company's data store by adding two columns to your most important tables?
Adding geographic data can be surprisingly useful for illuminating trends. Are more of your customers on the East Coast or the West Coast? Are there clusters? A quick glance at any of the maps that can be constructed as a result of this simple data gathering can often reveal more insight than a room full of statisticians.
Consider these maps just the beginning, as location information can help you recognize how clients, requests, contracts, and other revenue opportunities are clustered -- data that can then be mined for relevance. Did a marketing campaign in one region pay off? Is one sales team succeeding? Is one advertising deal worth renewing? Many of these answers can be found by analyzing geographic information, which prior to geocoding was considerably more labor-intensive.
And remember: Not every data point requires asking the customer to approve revealing their location through their browser. Google, Yahoo, and others offer geocoding solutions that convert street addresses into coordinates. Useful maps can be generated with just a ZIP code and a table that lists the geographic center of each ZIP code.
Check out low-risk IT experiment No. 5: NoSQL
Low-risk IT experiment No. 5: NoSQL Just 10 months ago, NoSQL was of interest to just a few IT speed freaks who sought to build the most efficient data storage engines ever. These engineers looked at the SQL databases and realized that JOINs slowed performance and made it difficult, if not impossible, to spread data over multiple machines. Sure, they could have denormalized the tables and investigated some automatic sharding tools, but it's much more fun to spark a revolution.
Many of the resulting open source NoSQL tools -- Cassandra, MongoDB, and CouchDB, to name a few -- require a fair amount of experimentation and a willingness to put up with rough edges. Add the fact that they're not yet ready for mission-critical projects, and you can see why your experience with NoSQL may vary.