Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
I read a blog posting from the other day by a frustrated software as a service (SaaS) vendor venting that:
For example, the author said "There are multiple points of failure and I can’t seem to think of how we could avoid these types of issues going forward."
Welcome to the world of running a service. Whether the service is SaaS, a service you provide inside your organization (e.g. a SOA service), or a traditional business service (e.g. like those provided by Reuters, Bloomberg, and Thomson), the issues are the same: You can never anticipate all the ways your consumers will use the services in advance. This means the risk of consumers experiencing problems is much higher than in other situations.
It also means you can't operate in a "let's get it right, ship it, and go on to the next project" traditional development-shop mentality. You need to think about solving the problem in a fundamentally different way.
The first step to addressing this problem is being able to insulate consumers from one another (even when they use the same instances of your service). The most important thing is to ensure that the actions of one consumer can't cause problems for another consumer. For example, if a consumer goes into an endless loop making requests of your service, you need to ensure this doesn't impact your other consumers (for example, using infrastructure to implement request throttling controls). Basically you're controlling the ripple effect.
Once you've figured out how to insulate consumers from each other, you can now think about "onboarding" each consumer as a separate project (even though you are in production your consumers aren't). What assistance do you need to provide to them so they can successfully complete the project of going live with your infrastructure? If, for example, they use REST or SOAP services you provide, how do you help them to ensure that they are using them correctly and appropriately?
Thirdly (and really this is just an optimization of the past point): How do you empower your consumers to do this for you (so you don't have to do all the work of making them successful). You'll never be able to fully avoid the responsibility of "owning" consumer satisfaction (and fixing it if it's bad) - but you can put measures in-place so that your consumers can be more successful with less effort. This can be as simple as providing much better documentation, samples, and tutorials - all the way to providing an interactive environment for the consumer to explore how to best use your service.
View all posts from dan foody on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.