Great post last week by Brad Feld about the new era in application development that’s centered on “gluing” together building blocks of functionality through APIs and other integrations. This approach of integrating existing SaaS and PaaS services dramatically lowers the cost of building cloud applications by leveraging existing functionality whenever possible.
Pardon the commercial in today’s post, but I feel it’s important to share the Cloud Elements approach, as a new breed of application development consulting firm, that leads with integrating vs. developing. Our approach to building cloud applications is focused on: (1) integrating existing functionality; (2) gluing this functionality together into a workflow; and (3) only building custom functionality when a service is not available.
However, we go a step further by integrating to a service once and then reusing this integration as a building block, or “Element”, in all future projects requiring that service. Since it’s built once and reused its more reliable and faster to leverage in your application. We then support and maintain the integration to keep current with the service provider’s new releases. APIs can be complex and change over time and our focus is to build the integration once and turn it into a reusable “Element” that can be easily selected by a developer.
We also abstract the integration for each category of service, such as Email Services, so your application is not dependent upon a particular service provider. For example, by using our Email Element you can switch from Amazon’s Simple Email Service to SendGrid without changing a line of code in your application.
Building cloud applications is about leverage. It’s about leveraging existing PaaS and SaaS services whenever possible to reduce the time and cost to get your application to market. Our company is built around this principle from our methodology to our reusable Elements. In fact we’ve seen 30% – 50% reductions in the time and cost to build applications.
Has your team focused first on identifying the services you can glue together vs. building functionality that already exists?