British poet and cleric John Donne never heard of a computer, but something he wrote nearly 400 years ago applies to the most modern technology, and to the company of anyone who reads this post. He wrote it in 1624: “No man is an island.”
Here’s the whole citation from Donne’s Devotions:
“No man is an island, entire of itself … any man’s death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee.”
In other words: No one is self-sufficient; everyone relies upon others.
In our context here on the blog, let’s put it this way: No app is self-sufficient; every app relies upon many others.
That twist on Donne’s famous line is so true that we should make it a motto for this website.
Until recent years, applications were built and operated as islands unto themselves — in a single environment that you controlled. No longer. Today, your applications are routinely integrated into myriad other apps. They might be CRM, HRM, analytics or billing systems.
When a customer logs in to buy a pair of pants from your retail site, he’s interacting with a supply chain app, an inventory app, your billing system and the systems of any number of third-party systems, from shipping to social media.
Here’s the bad news: If any of those third-party systems fail, the customer blames you.
For your customer to have a seamless experience, all of the data required to make the application work is dependent on integration with these different systems and the different ways the data must move. Oh, and there’s this tidbit to consider: Some third-party SaaS providers update their systems 10-20 times per day.
How does your IT team ever keep up with that?
If your company relies on giving customers end-to-end continuous experiences (and what company today doesn’t?), then here are three true statements about the challenges your tech team faces:
- Your apps must be integrated with many others and continuously tested to ensure uninterrupted customer experience.
- Writing mocks and stubs to conduct that testing is slooooooow and expen$$$$ive.
- Verifying integration with third-party services is a pain in your wallet. Those services, which are vital to your success but not under your control, are difficult and expensive to access, they change without notice, and you don’t control their performance.
Your success as an enterprise relies on you defeating those three challenges. As my colleague George Lawton wrote in 2013, Service Virtualization is your silver bullet.
- Service Virtualization gives your team the ability to accurately model any number of dynamic environments your app-in-development may encounter. That frees them to begin testing from the beginning and as often as they need, without worrying about lining up for access to dependent systems or paying excessive access fees. With one “conversation” with the dependent system, they’ll have the information needed to model any type of traffic or transaction. They’ll be able to test every imaginable scenario.
- Creating a virtualized service is faster and easier than creating mocks and stubs. That means your team is freed up to do more interesting and important problem-solving tasks. SV’s other big advantage over mocking and stubbing is that the old method severely limits the number of scenarios you can model. That means, inevitably, that you’ll release apps that aren’t yet fully tested.
- SV provides peace of mind for you and your customers. For you because you’re no longer hostage to third-party services when they roll out updates, or when they want to charge you for excess server time, or when they can’t schedule you for access to their network. And for customers, because they’ll know that when they use your app, it won’t fail for lack of testing and integration with dependent third-party systems.
Think about the implications, what you have at risk when you roll out an app, and whether you can afford not to protect yourself and your enterprise against the three challenges of integration. And, remember, no app is an island.