Enterprises in all industries continue to shift their IT spending away from on-premises software and towards cloud-native architectures that leverage the flexibility, scalability, time to value, security, accessibility, and overall ROI which is a hallmark of Software-as-a-Service (SaaS) based business model.
As a result, the market for SaaS software is expected to grow from $103B in 2020 to $145B by the end of 2022. With $42 billion in global spending up for grabs, it’s easy to see why many legacy, on-premise software companies and SaaS startups alike are sprinting to match the success market leaders like Salesforce, Adobe, Atlassian and Zendesk have experienced.
But in the race for cloud market share, I’m seeing organizations embrace the “12 factor methodology” of SaaS application development, which is one of three SaaS development mistakes that are appearing with increasing frequency as development timelines shrink and the pressure to deliver grows. Any one of these pitfalls can introduce fatal flaws into the SaaS product, potentially forcing a costly rework or even dooming it from the start.
Pitfall #1: Focusing only on low-hanging fruits
Leadership teams—along with application and product owners—have a bias towards action, and that bias can at times drive the development teams to focus on the more superficial aspects of software development that can be presented to management to show progress in update meetings.
This bias towards action isn’t wrong or misplaced—when you invest six months in a project, it’s normal to want to see some fruits of the team’s labors. But SaaS software development is incredibly complicated, especially in brownfield application development where the legacy code doesn’t simply shift to the cloud for instant results.
Instead of focusing on the difficult and complex challenges like modernizing the database, developers are tempted to work on the margins of the puzzle to get some quick wins and have something to show at the next update meeting.
Some examples of skin deep often include upgrading and updating front-end and back-end logic pieces, like writing a microservices or a serverless architecture or designing the compute capacity. Incremental modernization efforts like this may placate leadership teams and make for a more pleasant update meeting, but they can only deliver incremental benefits to users and the business.
Pitfall #2: Skipping brainstorming and discovery
Pressured to show tangible results as quickly as possible, development teams have begun limiting the amount of time spent during the brainstorming and discovery phases of the development project. The response is a natural one: you can’t begin showing results until you’re actually touching code, and you can’t start touching code until you’re out of the conference room and away from the whiteboards.
The temptation to stop talking and start doing is strong, but misplaced. This is particularly the case with brownfield projects where the temptation to wave the magic cloud wand over the legacy application and start collecting monthly revenue in perpetuity.
Limiting the brainstorming phase cuts short a narrow, valuable window of opportunity where your developers, product managers, business development teams, business architects, and other critical voices of the customer can unearth real paradigm-breaking insights. The kind of insights that result in a truly differentiated, revolutionary new SaaS product rather than an incrementally better version of an existing application or suite. This is especially the case with greenfield opportunities.
At the same time, limiting the discovery phase of a brownfield opportunity hinders your ability to ask the kinds of questions that can dramatically cut development time and resources and deliver a better SaaS product to market more quickly. Questions like:
- What existing backend services can we use?
- How existing application code can we/should we move to the configurations?
- Based on the market opportunity and need, are we talking about one product or many?
- If we’re looking at multiple products, what are the opportunities to benefit from concurrency?
- How do we take full advantage of the horizontal scaling capability cloud offers?
If these kinds of questions are coming up six months into your development, that’s a real problem, no matter how tight and high performing the code may be. Brainstorming and discovery are essential components of any successful product development cycle. Spend a few inexpensive hours up front to save yourself costly months down the road, then circle back regularly to ensure alignment when the target inevitably moves before launch.
Pitfall #3: Trying to address all 12 factors simultaneously
Much has been written and said about the “12-factor methodology” of SaaS application development, a doctrine that has been embraced globally as the focus on cloud-based applications has exploded over the last decade.
While following these 12 factors doesn’t guarantee product success in the marketplace, many developers today view the 12 factors as a checklist of sorts. The more boxes you check, the better your product will be.
In practice, however, conforming to all 12 factors can add time and expense to your project without delivering commensurate benefit. Not every application requires the highest and best maturity level for each factor, but a few are more essential than others, including:
- Codebase – As a best practice, we’re trying to follow a decomposition pattern, breaking the code down into the smallest possible size. That allows us to apply microservices per codebase, maximizing the value of cloud and modernization.
- Config – Keeping config separate from code is a must have, so that changes can be made to code and be tracked automatically without requiring constant manual updates through constant deployments. This way, when things change rapidly during development, it doesn’t impact the work being done by others.
- Backing service – Treating them as attached resources is critical when writing a stateless application with different versions. When the storage is persistent and treated as an attached resource, it can go away and come back with no risk of data loss and the resulting disruptions and negative customer impact.
- Environmental parity – Containerizing your environment helps ensure consistency with elements, entities and external services across different development and production environments. This streamlines the development process for all and expedites onboarding for new development teams too.
As the SaaS market continues to generate $20 billion in new revenue opportunities annually, the pressure to deliver new cloud-based software quickly will continue to increase. ISVs that resist the urge to act quickly and superficially in an effort to show fast results will deliver better, more innovative software.
The 12-factor methodology is a tested approach proven to deliver SaaS products that are cloud ready, scalable, and resilient, using automated processes and a consistent environment between development and production to deliver maximum value with minimum resources.
However, focusing on the four factors that are the most essential to the 12-factor development methodology will maximize the benefits of SaaS development without burdening the development teams unnecessarily.
To learn how Persistent Systems can put 30+ years of business acceleration and transformation experience to help you begin or accelerate your own product modernization journey, visit our Digital Transformation and Product Modernization web pages.
