Ask most people what IT systems their business uses and you’re likely to get a different answer depending on which area they work in. Operational, structural, personnel and sales-based systems all have their place, and if the business has been around for any length of time, there will be legacy versions running alongside new ones.
Each of these systems are likely to have been brought in for a specific purpose, so they will have their own programming languages, operating systems, protocols and data requirements. This is great for working in isolation, but what happens when one system needs to talk to another and share data in a meaningful way, such as when you need to work out sales attribution between ecommerce and in-store?
This is where a web service comes in – an internet-based way for two different software systems to exchange data without the cost and effort involved in developing custom coding. Also, as web services don’t rely on any particular programming language or operating system, they allow Windows to talk to UNIX, Perl to Java and so on. They also allow independent channels such as mobile apps, websites, back office systems and in-store kiosks to talk to one another and share information and functionality.
The nuts and bolts of web services
Without going into heavy technical detail, web services tend to be REST (Representational State Transfer) compliant – i.e. they follow a set of best practices and open standards, in terms of structure, formatting and behaviour. Security and business logic are handled by the web services, leaving each client free to present data and functionality in the best way for that device / situation (website, mobile apps, etc.).
On the face of it, it’s an easy decision to make – allow web services to take the hassle out of making systems (which may have been introduced a number of years ago) work with each other in an efficient way. But for some businesses, it’s a leap of faith, which they may not be willing to make. The cost can often be difficult to justify, with no immediate recognised benefit and as web services present a well-defined (and often publicly accessible) way for computer systems to access your data and business functions, security can become an issue.
Undoubtedly, there are a number of risks which make web services vulnerable. Most of us will have read in the news about Denial of Service (DoS) attacks, where sites and systems are brought to their knees after being flooded by irrelevant and useless traffic. Data theft is another risk, as is data ‘poisoning’ where rivals infect systems with malicious messages.
Fortunately, the solution is relatively straightforward. As with all web applications, it is possible to scan, identify and manage vulnerabilities to ensure that the web services remain healthy and continue to do the job as intended. Automated, load and penetration tests are also easier to setup and perform on web services than they are on something like mobile applications. This can actually reduce the need for complex security testing across all systems, using your web services as the secure ‘gatekeeper’ upon which everything else is delivered.
As services are offered by some of the largest, most experienced tech-based companies in the world (Amazon Web Services and Microsoft Azure, to name just two), there’s also an inherent trust in the security of their offering.
In reality, the pace of change when it comes to IT and data requirements means that any other choice, including patching existing systems, continuing to work in isolation and developing ever more cumbersome internal communication networks, just won’t be viable in the long term.
Therefore, the business case for web services is simple – long-term maintenance and improvement of many independent systems will become unsustainable if you don’t take action to break down internal systems silos and let them talk to each other.