Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Host, deploy and scale Node.js, Java and .NET Core apps on premise or in the cloud
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Transform your businesses in order to survive in a completely digitized and connected world driven by software innovation.
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built in the cloud
In my last post, I introduced the concept of pre-consumption as a new and unique phase of the Software Development Life Cycle (SDLC) - one that only occurs when you have a SOA infrastructure. What I want to do now is explore what this means. What is the impact of pre-consumption on developers that are building services or composite applications?
In this post, I'll take a look at what pre-consumption means to service providers.
For service providers, pre-consumption looks a lot like production. The difference is that, while your service may be in production, your consumers are still in development.
In the traditional SDLC, once you're in production the majority of problems that occur are operational problems - it crashes, it gets slow, it runs out of threads, etc. By comparison, there are relatively few functional problems (it did something other than what it was supposed to do). The reason is that you've gone through development and testing already, and have hopefully worked out all of the functional issues in these phases. Sure, the occasional functional issue slips through the cracks, but that's the exception not the rule unless you're talking about Vista.
Historically, once something is in production, operational issues were what mattered most.
With pre-consumption, though, the consumer is in development. What this means is that the service provider will have to deal with a large number of functional issues in production. Some of these will be real functional issues - you couldn't afford to test all of the permutations of ways the service might be used could you? Some will be the consumer not understanding the quirks of how the service behaves - despite the exceptionally thorough documentation you wrote for the service. Yes, you'll often hear the consumer saying, "I sent the right information in, but your service didn't work right," whether it did or not.
So, even though you might think your service is in-production, if you are really in pre-consumption, you need to focus on being able to diagnose functional problems. Dealing with operational problems will be secondary.
As a service provider, the other side effect you'll see is that because consumers will often have unique needs, to serve your consumers well you'll end up having to version your service a lot more often than you might be used to (when consumers and services are designed at the same time). So, this will put additional burden on your ability to manage versioning of your services. This becomes especially challenging as different consumers test or even run services against different versions.
SOA What? As a service provider, get ready to dramatically change your expectations of how you support your service once it's "in production".
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 © 2016, 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.