The History of Business Software Product Development
Historically, major releases from software vendors came out periodically with a new version maybe once a year or so (or when I worked in Microsoft Office it was every 3 years). The software release had to balance between delivering new functional capabilities and supporting changing IT requirements, security needs, scale and performance and so on. IT departments focused on carefully planning software release upgrades and installations.
New software products were evaluated in the context of existing software and how it would integrate. Users had to accommodate new software releases and upgrades — they had to try and (sometimes painfully) figure how to use the software for something useful. User interaction (UI) and user experience (UX) were low priorities.
In product development, issues or bugs relating to UI and UX were the lowest priority and first to be dropped from the engineering development work schedule. There was less concern about how users were going to use the product, as it was assumed that the software manual and documentation would explain all of that.
It could take many product releases and a patient customer and user base to achieve the level of functional richness and genuine user experience that was originally promised. Here’s how traditional product development looks like from an investment and priority perspective:
The overall cost of developing and delivering traditional business software is high. It demands a significant investment in people, time and building the product presence in the market. This is true whether you’re a Microsoft (where I led a team doing this), small company or a start-up.
Our Product Development Vision at River Logic
When thinking about developing and delivering our product roadmap at River Logic, we knew we wanted to avoid the traditional approach (the approach I described above). Instead, we wanted to focus on the following key application aspects:
- Outstanding User Experience
- A rich application experience
- Meaningful, valuable functionality
- Frequent, enhanced releases
We didn’t want to be investing in developing base software infrastructure and worrying about deployment into different and varied IT environments.
At the same time, we needed to bring forward our existing (traditional) software products as critical pieces of our roadmap.
The answer was to base our product roadmap on a cloud platform where we could utilize platform as service (PaaS) and infrastructure as a service (IaaS) to meet our goals for bringing together new application experiences with our existing products. There were a number of important aspects we needed to consider when thinking about what cloud service to select across the offerings from Microsoft, Amazon and Google etc:
Why We Chose to Build River Logic on Microsoft Azure
We needed a very strong, application-developer-orientated PaaS capability. The platform needed to have the ‘base building blocks’ to allow our engineers to rapidly compose our application experience together with the tooling and environments to be highly productive.
Microsoft Azure provided the ‘base building blocks’, tools, environments that our engineering team embraced. Azure PaaS also provides a lot of the background infrastructure management and the important connections to dev-ops, removing a lot of ancillary work from our team and allowing us to focus on the key application aspects.
Continuous Delivery and Deployment
To meet our customer experience goals, it was crucial for the cloud platform to support a high bar for delivery and deployment to enable high developer and development productivity. Azure provides an integrated environment (SDK) for developing, testing, and deploying cloud applications. The Azure SDK allows a choice of development languages and provides the following key capabilities including:
- Ability to develop on local machines and deploy to the cloud
- Support for rapid development and testing of the system (application) with rapid feedback
- Reduce the cost of code integration
- Enable performance, stress, scale testing of the application in the cloud
- Continuous delivery to provide the code (features) changes that can be deployed at any time
- Continuous deployment so that every update change that passes the automated tests can be deployed automatically
Using the continuous delivery and deployment approach supported by Azure means that release of new features and functions is a decision where we can put 100% focus on the customer experience.
Security is obviously a huge design concern when building a new application (product). Significant investment is needed to meet stringent requirements from all aspects of an application. Azure has been designed based on the Security Development Lifecycle (SDL) which originated in 2003 in Microsoft. SDL provides both application developers and Azure customers with the assurance of Azure security at its core including private data and PaaS services and. Microsoft has been early adopters of security and privacy standards including being the first cloud vendor to be:
- Approved by the European Union’s data protection authorities and the Article 29 Working Party
- Adopt the new international standard for cloud privacy, ISO 27018
Scale and Elasticity
For our application, we needed Azure to be able to scale reliably from small (10) to thousands of users and onwards. Compute resources and storage need to scale and perform elastically to meet changes in demand seamlessly — without any additional coding. Azure provides these level of resource and service configurations where we can scale our application based on usage, tenancy, performance demands in a highly efficient and cost effective approach.
Transforming Traditional Products to the Cloud
This is major area of importance for our roadmap. It shouldn’t be necessary to re-write existing products to move them to a cloud platform. A cloud platform needs to support a number of steps with regards existing products:
- Run existing products in the cloud using IaaS in a highly automated (elastic) approach
- Integrate existing products with new cloud applications
- Integrate environments for customer using the existing product (hybrid support)
- Integrate existing users and security models
Beyond the initial steps for cloud support, enable approaches including microservices architecture to transform our existing products so they can utilize distributed resources and infrastructure.
Azure: The Natural Choice
Azure ended as the natural choice for us across the choice of cloud platforms. It gives us the platform and approaches to integrate our existing products in to a comprehensive roadmap with our new applications experience. This is a critical capability.
Utilizing Azure cloud has shifted the focus and efforts of our engineering team. Now, the emphasis is on creating an outstanding user experience with the functionality that’s needed and massively reducing our development time spent on infrastructure requirements.
It is a sea change in product and application development which ultimately brings huge benefits to our customers and partners.