Last week in the blog entry Dark Clouds, Silver Linings I discussed a few of the most frequent concerns I’ve been hearing about the construction industry’s move to cloud computing. I left one concern for this week’s blog since I felt it deserved a little more explanation—the topic of software integration and what that will look like in the cloud.
A web of data
Connecting various pieces of construction software together to act as a single system has been a client request since I started developing construction management software over 30 years ago. I’ve yet to encounter the one vendor who provides every application a contractor needs in a single system. For example, it’s common to have separate vendors for your estimating and accounting software. And it’s common to connect these applications together. Doing so reduces the need to enter data multiple times and limits the amount of information that exists in silos, available only to a select few individuals.
These software connections are usually centered on a company’s business management software (i.e., their ERP system). While data can flow both ways, the ERP system serves as the hub of integration. But what happens when this hub moves to the cloud? Does it “break the tethers” of connection to other more “earthbound software?” Well, (spoiler alert) the answer is no. Enter the concept of the web service.
So what is a web service? The most basic description is that it is a way to move data into, out of, or between applications that use the web as their platform—in other words, cloud applications. Web services use a well-defined set of protocols to define the way web applications talk to each other, or that any application can talk to a web-based application. Getting into the details of how this works would involve diving into an acronym soup of terms like SOAP, REST, and WSDL. The important thing is the existence of a standard that developers can use to make cloud integration work.
There’s the cloud, then there’s The Cloud
The creation of standardized protocols for web services was a big step in helping us move toward cloud computing. But be warned—not every application that lays claim to being “in the cloud” can take full advantage of this connecting technology.
Web Services depend on the use of protocols inherent in the World Wide Web—including one most people are familiar with—HTTP (Hypertext Transfer Protocol). If an application is written expressly for use in The Cloud, it will naturally support the protocols used by web services. These applications will typically be browser-based, meaning you simply open a browser, go to a specific web site, and log on to use your application.
Many other applications, in a rush to get on the cloud bandwagon, have simply been placed in a hosted environment. These applications typically remain Windows-based, and the user needs special connectivity software in order to access them in what is essentially a virtual environment. This makes invoking web services problematic. Special access to your hosted applications needs to be engineered for each instance of a web service connection. So while technically feasible, this approach is far from easy or seamless.
The web service protocols that enable designed-for-the-web applications to work together are a simpler, easier approach than integration through traditional application programming interfaces (APIs). And one thing I’ve learned in years of software development is always to bet on simpler and easier.