To most people -- especially in August -- 'Ocean Services' probably conjures visions of boogie boards, sun umbrellas and bringing the drinks without getting sand in the glass.
To Matson Navigation CIO Peter Weis, it means logistics, and the need to gather, analyze and coordinate information so his customers can monitor the location, condition and progress of finished goods in one container on one freighter in the South Pacific, more easily than they'd be able to check on a new phone battery being delivered by FedEx.
It's not the kind of information or access the ocean services business has been accustomed to offering.
"Shipping is a very traditional industry," Weis says. "There a lot of traditional old-school people, and so many moving pieces, solving global problems using IT is much harder than it might be in another industry."
Weis, who took over as CIO of the $1.5 billion Matson Navigation in 2003, says the company is 75 percent of the way through an IT overhaul that focuses on retiring the mainframes, DOS and AS/400 systems the company has depended on for years in favor of a Java-based application-integration platform and a plan to get as many of Matson's business applications as possible from external SaaS providers.
Moving to a heavy reliance on SaaS applications is a key part of the strategy to reduce the company's risk and capital spending on new systems. Matson is unusual not because of its increasing use of software owned and maintained by someone else -- but because it is selecting those services according to a coherent, business-focused strategy and connecting them using an open platform built for the purpose.
"What we're seeing is companies jumping into SaaS or cloud projects without an overarching strategy," according to Kamesh Pemmaraju, director of cloud research at consultancy Sand Hill Group. "There are a lot of departmental initiatives and they do get some quick returns on that, but it's very local in nature and there's no coordination on how to obtain global benefits to get real value out of the cloud."
Defining goals is an obvious step, but not one every company realizes it needs to take, according to Michael West, vice president and distinguished analyst for Saugatuck Technology.
Below are a few more necessary steps to take before deciding to move from a traditional app to a Web-based one.
1. Decide Why You Want SaaS
Weis was hired in 2003 to revamp Matson's IT infrastructure, so part of his mandate was to design an infrastructure and draw up a strategy to coordinate the company's use of SaaS and internal applications.
Business agility, not cost savings, is the leading reason U.S. companies are interested in cloud computing, according to a survey of 500 senior-level IT and business-unit managers Sand Hill released in March. Forty nine percent of respondents listed business agility as their most important goal; 46 percent listed cost efficiency. The No. 3 response -- freeing IT resources to focus on innovation -- got less than half that support, with 22 percent.
SaaS is spreading quickly among business units and departments, not usually with the help or strategic guidance of IT to make sure the functionality isn't duplicated or conflicting with the company's other tools.
"People tend to think of SaaS as a technology choice, which it's not," Pemmaraju says. "It's a business choice, to allow you to access technology to respond to business demands in real time. If you just look at it as technology, you have to answer how you're contributing to your business goals."
2. Think Architecture
Before Weis started signing on SaaS providers and ramping down internal applications, he and his staff spent a year taking inventory of all the company's existing systems and building a reference platform that provided middleware and application servers to connect new and existing applications.
"Our endpoint was that all our apps would run on the target IT platform based on distributed architecture, J2E based middleware and apps servers," Weis says. "That year was spent laying that foundation but also restructuring the legacy organization, hiring the skills we needed, building a QA group, test group, architecture group -- a lot of things the legacy organization didn't have."
That kind of thoughtful architectural planning will help any organization in the long run, though it is becoming less necessary as SaaS providers begin to provide more ways to integrate SaaS and legacy applications, sometimes with another SaaS choice, West says.
More than half the transactions on SalesForce.com come through APIs, meaning the software is programmatically connected to other systems, usually through manual integration work on the part of the customer.
SaaS providers like SalesForce are building much better integration into their apps, however. And third parties such as Boomi and recent IBM acquisition CastIron, can also help with two-way synchronization of data between on-premise and SaaS applications, West says.
Third-party integrators such as Appirio, ModelMetrics, and BlueWolf also offer integrated sets of SaaS applications, sometimes selected by menu from a Web interface, sometimes built in custom engagements.
"You end up with a constellation of functionality, with multiple SaaS providers linked, available on a subscription basis, " West says.
3. Take Inventory and Throw Out Apps
Few companies with significant IT infrastructures have total control over the number of applications they run. Every consultant has horror stories.
West's story: a company with three divisions, one of which had 26 separate ERP systems, mostly from acquisitions in which the company was merged but the software was not. Pemmaraju cites a Fortune 500 finance-company CIO who admitted to an IT portfolio of between 15,000 and 20,000 applications and no idea what they were all for or to what they were connected.
Maintaining duplicate applications costs more for everything IT touches -- storage, licensing, training, support, Pemmaraju says. The problem is incredibly common, and unlikely to go away.
Pemmaraju estimates that one quarter of most corporate apps contain critical data or functions that have to remain inside the firewall. The rest are generic or commoditized enough to be shifted outside or consolidated into a much smaller number of brands.
That's only the first step in matching internal and cloud-based apps, however, Weis says. Back-office applications are good candidates for SaaS-ification, as are finance, HR and accounting apps.
Those that have to meet specific requirements may not be, however.
"In ocean shipping, there are 30 or so major carriers, which isn't a big enough market to have a ton of developers building products for it," Weis says. "So things like core booking systems and order systems -- those are absolutely custom builds because the documentation, the bill of lading, the business rules and requirements are so specific."
4. Check More Than a Provider's Books
In SaaS relationships it's critical to know if a software provider is financially stable, well managed and uses secure, well maintained data centers. So it's important to do due diligence checks on a provider's financial health and ability to pass audits for privacy or financial-reporting regulations, Weis says. Picking the right SaaS provider requires a lot more than that, however, Pemmaraju says.
SMB companies or individual departments might rely on Boomi or CastIron for integration. More ambitious projects require SaaS providers that offer the right tools for tight connections into existing applications, he says.
"I have clients who say if a SaaS company doesn't have Web Services frameworks built in, I don't talk to them," Pemmaraju says. "Being able to manage a lot of SaaS applications from one management console is a big deal. So is identity management. If you have to go to different consoles for every administrative task and to create or change user information, and someone leaves the company, what happens to all that information in all those unconnected places."
"Scale is an issue in the cloud; If there's not a common place to manage them it becomes difficult very quickly to keep tabs," Pemmaraju says.
5. Compare the Right Costs
On-premise software looks expensive because customers have to pay the bulk of the cost upfront or across the first three years they use it, Pemmaraju says. After that the customer's financial interest is to keep what it has paid for until long after the cost is amortized. That means relying on aging software and missing out on potentially beneficial functions in newer versions.
SaaS applications look inexpensive because the subscription cost is far lower than the payout of an acquisition, and they begin delivering useful functionality more quickly than it would take IT to spec, build and test an on-premise application, Pemmaraju says.
Without a coherent strategy and set of criteria for success, however, it's impossible to know if a SaaS application is delivering real value, Pemmaraju says.
Without good integration tools and the ability to use them, customers have to repeat the same cycle of evaluation, testing, deployment and management with each application, rather than streamlining that process with better process and management integration, West says.
That's the real challenge with SaaS, according to Weis. He must make sure that the platform on which the applications are deployed can connect them easily and the end result of many SaaS contracts is less confusion, greater efficiency and a better handle on practical aspects of the business. That means what container is on what ship and how long will it take to get to port, not where data is stored and whose server is running the application.
Follow everything from CIO.com on Twitter @CIOonline, and the CIO.com Facebook page
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.