Which Apps Should You Move to the Cloud? 5 Guidelines
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.
Article Credit to Kevin Fogarty at ComputerWorld