The AKF Partners Session State Cube
March 19, 2019 | Posted By: Marty Abbott
Tim Berners-Lee and his colleagues at CERN, the IETF and the W3C consortium all understood the value of being stateless when they developed the Hyper Text Transfer Protocol. Stateless systems are more resilient to multiple failure types, as no transaction needs to have information regarding the previous transaction. It’s as if each transaction is the first (and last) of its type.
First let’s quickly review three different types of state. This overview is meant to be broad and shallow. Certain state types (such as the notion of View state in .Net development) are not covered.
The Penalty (or Cost) of State
State costs us in multiple ways. State unique to a user interaction, or session state, requires memory. The larger the state, the more memory requirement, the higher cost of the server and the greater the number of servers we need. As the cost of goods sold increase, margins decrease. Further, that state either needs to be replicated for high availability, and additional cost, or we face a cost of user dissatisfaction with discrete component and ultimately session failures.
When application state is maintained, the cost of failure is high as we either need to pay the price of replication for that state or we lose it, negatively impacting customer experience. As memory associated with application state increases, so does the memory requirement and associated costs of the server upon which it runs. At high scale, that means more servers, greater costs, and lower gross margins. In many cases, we simply have no choice but to allow application state. Interpreters and java virtual machines need memory. Most applications also require information regarding their overall transactions distinct from those of users. As such, our goal here is not to eliminate application state but rather minimize it where possible.
When connection state is maintained, cost increases as more servers are required to service the same number of requests. Failures become more common as the failure probability increases with the duration of any connection over distance.
Our ideal outcome is to eliminate session state, minimize application state and eliminate connection state.
But What if I Really, Really, Really Need State?
Our experience is that simply saying “No” once or twice will force an engineer to find an innovative way to eliminate state. Another interesting approach is to challenge an engineer with a statement like “Huh, I heard the engineers at XYZ company figured out how to do this…”. Engineers hate to feel like another engineer is better than them…
We also recognize however that the complete elimination of state isn’t possible. Here are three examples (not meant to be all inclusive) of when we believe the principle of stateless systems should be violated:
Shopping carts need state to work. Information regarding a past transaction - (add_to_cart) for instance needs to be held somewhere prior to check_out. Given that we need state, now it’s just a question of where to store it. Cookies are good places. Distributed object caches are another location. Passing it through the URL in HTTP GET methods is a third. A final solution is to store it in a database.
No sane person wants to wrap debits and credits across distributed servers in a single, two-phase commit transaction. Banks have had a solution for this for years – the eventual consistent account transaction. Using a tiny workflow or state machine, debit in one transaction and eventually (ideally quickly) subsequently credit in a second transaction. That brings us to the notion of workflow and state machines in general.
What good is a state machine if it can’t maintain state? Whether application state or session state, the notion of state is critical to the success of each solution. Workflow systems are a very specific implementation of a state machine and as such require state. The trick with these is simply to ensure that the memory used for state is “just enough”. Govern against ever increasing session or application state size.
This brings us to the newest cube model in the AKF model repository:
The Session State Cube
The AKF State Cube is useful both for thinking through how to achieve the best possible state posture, and for evaluating how well we are doing against an aspiration goal (top right corner) of “Stateless”.
The X axis describes size of state. It moves from very large (XL) state size to the ideal position of zero size, or “No State”. Very large state size suffers from higher cost, higher impact upon failure, and higher probability of failure.
The Y axis describes the degree of distribution of state. The worst position, lower left, is where state is a singleton. While we prefer not to have state, having only one copy of it leaves us open to large – and difficult to recover from – failures and dissatisfied customers. Imagine nearly completing your taxes only to have a crash wipe out all of your work! Ughh!
Progressing vertically along the Y axis, the singleton state object in the lower left is replicated into N copies of that state for high availability. While resolving the recovery and failure issues, performing replication is costly both in extra memory and network transit. This is an option we hope to avoid for cost reasons.
Following replication are several methods of distribution in increasing order of value. Segmenting the data by some value “N” has increasing value as N increases. When N is 2, a failure of state impacts 50% of our customers. When N is 100, only 1% of our customers suffer from a state failure. Ideally, state is also “rebuildable” if we have properly scattered state segments by a shard key – allowing customers to only have to re-complete a portion of their past work.
Finally, of course, we hope to have “no state” (think of this as division by infinite segmentation approaching zero on this axis).
The Z Axis describes where we position state “physically”.
The worst location is “on the same server as the application”. While necessary for application state, placing session data on a server co-resident with the application using it doubles the impact of a failure upon application fault. There are better places to locate state, and better solutions than your application to maintain it.
A costly, but better solution from an impact perspective is to place state within your favorite database. To keep costs low, this could be an opensource SQL or NoSQL database. But remember to replicate it for high availability.
A less costly solution is to place state in an object cache, off server from the application. Ideally this cache is distributed per the Y axis.
The least costly solution is to have the client (browser or mobile app) maintain state. Use a cookie, pass the state through a GET method, etc.
Finally, of course the best solution is that it is kept “nowhere” because we have no state.
The AKF State Cube serves two purposes:
- Prescriptive: It helps to guide your team to the aspirational goal of “stateless”. Where stateless isn’t possible, choose the X, Y and Z axis closest to the notion of no state to achieve a low cost, highly available solution for your minimized state needs.
- Descriptive: The model helps you evaluate numerically, how you are performing with respect to stateless initiatives on a per application/service basis. Use the guide on the right side of the model to evaluate component state on a scale of 1 to 10.
AKF Partners helps companies develop world class, low cost of operations, fast time to market, stateless solutions every day. Give us a call! We can help!
Subscribe to the AKF Newsletter
The AKF Difference
December 4, 2018 | Posted By: Marty Abbott
During the last 12 years, many prospective clients have asked us some variation of the following questions: “What makes you different?”, “Why should we consider hiring you?”, or “How are you differentiated as a firm?”.
The answer has many components. Sometimes our answers are clear indications that we are NOT the right firm for you. Here are the reasons you should, or should not, hire AKF Partners:
Operators and Executives – Not Consultants
Most technology consulting firms are largely comprised of employees who have only been consultants or have only run consulting companies. We’ve been in your shoes as engineers, managers and executives. We make decisions and provide advice based on practical experience with living with the decisions we’ve made in the past.
Engineers – Not Technicians
Educational institutions haven’t graduated enough engineers to keep up with demand within the United States for at least forty years. To make up for the delta between supply and demand, technical training services have sprung up throughout the US to teach people technical skills in a handful of weeks or months. These technicians understand how to put building blocks together, but they are not especially skilled in how to architect highly available, low latency, low cost to develop and operate solutions.
The largest technology consulting companies are built around programs that hire employees with non-technical college degrees. These companies then teach these employees internally using “boot camps” – creating their own technicians.
Our company is comprised almost entirely of “engineers”; employees with highly technical backgrounds who understand both how and why the “building blocks” work as well as how to put those blocks together.
Product – Not “IT”
Most technology consulting firms are comprised of consultants who have a deep understanding of employee-facing “Information Technology” solutions. These companies are great at helping you implement packaged software solutions or SaaS solutions such as Enterprise Resource Management systems, Customer Relationship Management Systems and the like. Put bluntly, these companies help you with solutions that you see as a cost center in your business. While we’ve helped some partners who refuse to use anyone else with these systems, it’s not our focus and not where we consider ourselves to be differentiated.
Very few firms have experience building complex product (revenue generating) services and platforms online. Products (not IT) represent nearly all of AKF’s work and most of AKF’s collective experience as engineers, managers and executives within companies. If you want back-office IT consulting help focused on employee productivity there are likely better firms with which you can work. If you are building a product, you do not want to hire the firms that specialize in back office IT work.
Business First – Not Technology First
Products only exist to further the needs of customers and through that relationship, further the needs of the business. We take a business-first approach in all our engagements, seeking to answer the questions of: Can we help a way to build it faster, better, or cheaper? Can we find ways to make it respond to customers faster, be more highly available or be more scalable? We are technology agnostic and believe that of the several “right” solutions for a company, a small handful will emerge displaying comparatively low cost, fast time to market, appropriate availability, scalability, appropriate quality, and low cost of operations.
Cure the Disease – Don’t Just Treat the Symptoms
Most consulting firms will gladly help you with your technology needs but stop short of solving the underlying causes creating your needs: the skill, focus, processes, or organizational construction of your product team. The reason for this is obvious, most consulting companies are betting that if the causes aren’t fixed, you will need them back again in the future.
At AKF Partners, we approach things differently. We believe that we have failed if we haven’t helped you solve the reasons why you called us in the first place. To that end, we try to find the source of any problem you may have. Whether that be missing skillsets, the need for additional leadership, organization related work impediments, or processes that stand in the way of your success – we will bring these causes to your attention in a clear and concise manner. Moreover, we will help you understand how to fix them. If necessary, we will stay until they are fixed.
We recognize that in taking the above approach, you may not need us back. Our hope is that you will instead refer us to other clients in the future.
Are We “Right” for You?
That’s a question for you, not for us, to answer. We don’t employ sales people who help “close deals” or “shape demand”. We won’t pressure you into making a decision or hound you with multiple calls. We want to work with clients who “want” us to partner with them – partners with whom we can join forces to create an even better product solution.
Subscribe to the AKF Newsletter
Migrating from a legacy product to a SaaS service? Don't make these mistakes!!
September 4, 2018 | Posted By: Dave Swenson
AKF has been kept quite busy over the last decade helping companies move from an on-premise product to a SaaS service - often one of the most difficult transitions a company can face. We have found that the following are the top mistakes made during that migration.
With apologies to David Letterman…
The Top 5 SaaS Migration Mistakes
5. Treat Your SaaS Migration Only as a Marketing Exercise
Wall Street values SaaS companies significantly higher than traditional software companies, typically double the revenue multiples. A key reason for this is the improved margins the economies of scale true SaaS companies gain. If you are primarily addressing your customer’s desires to move their IT infrastructure out of their shop, an ASP model hosted in the cloud is fine. However, if your investors or Wall Street are viewing you as a SaaS company, ASP gross margins will not be accepted. A SaaS company is expected to produce in excess of 80% gross margin, whereas an ASP model typically caps out at around 60 or 70%.
How to Avoid?
Make a decision up front on what you want your gross and operating margins to be. This decision will guide how you sell your product (e.g.: highest margins require no code-level customizations), how you architect your systems (multi-tenancy provides greater economies of scale), and even how you release (you, not your customers, control release timing and frequencies). A note of warning: without SaaS margins, you will likely face pricing pressure from an existing or entrant competitor who achieved SaaS margins.
4. Tack the word ‘cloud’ on to your existing on-prem product and host it
Often a direct result of the above mistake, this is an ASP (Application Service Provider) model, not a SaaS one. While this exercise might be useful in exploring some hosting aspects, it won’t truly inform you about what your product and organization needs to become in order to successfully migrate to SaaS. It will result in nowhere near the gross and operating margins true SaaS provides, and your Board and Wall Street expect to see. As discussed in The Many Meanings of Cloud, the danger of tacking the word “Cloud” onto your product offering is that your company will start believing you are a “Contender”, and will stop pushing for true SaaS.
How to Avoid?
Again, if an ASP model is ‘good enough’, fine - just don’t label or market yourselves as SaaS. If you start the SaaS journey with an ASP model, make sure all within your company recognize your ASP implementation is a dead-end, a short-term solution, and that the real endpoint is a true SaaS offering.
3. Target Your Existing Customer Base
Many companies are so focused upon their existing customer base that they forget about entire markets that might be better suited for SaaS. The mistaken perception is
“We need to take customers along with us”,
when in fact, the SaaS reality is
“We need to use the Technology Adoption Lifecycle, compete with ourselves and address a different or smaller customer base first”.
How to Avoid?
Ignore your current customers and find early adopters to target, even if your top customers are pushing you to move to SaaS. A move to true SaaS from your on-premise product almost always requires significant architectural changes. Putting your entire product and code base through these changes will take time.
Instead, apply the Crossing the Chasm Bowling Alley strategy to grow your SaaS offering into your current customer base rather than fork-lifting your current solution in an ASP fashion into the cloud…
Carve out key slices of functionality from your product that can provide value in a standalone fashion, and find early adopters to help shake out your new offering. Even if you are in a ‘laggard’ industry (banking, healthcare, education, insurance), you will find early adopters within your targeted customer base. Seek them out; they will likely be far better partners in your SaaS migration than your existing ones.
2. Ignore Risk Shifts
It may come as a surprise to some within your company to find out how much risk your customers bear in order to host and use your product on-premise. These risks include security, availability, capacity, scalability, and disaster recovery. They also include costs such as software licensing that have been passed through to your customers, but are now yours, part of your operating margins.
How to Avoid?
Many of these “-ilities” are likely to be new disciplines that now must be instilled in your company, some by hiring key individuals (e.g.: a CISO), some through additional focus and rigor during your PDLC. Part of the process of rearchitecting for SaaS includes ensuring you have adequate scalability, are designed with availability in mind, and a production topology that enables disaster recovery. Where vertical scalability might be acceptable in your on-prem world (“just buy a bigger machine”), you now need to ensure you have horizontal scalability, ideally in an elastic form. The cost of proprietary software (e.g.: database licenses) is now yours to carry, and a shift to open source software can significantly improve your margins. These “-ilities” are also known as non-functional requirements (NFRs), and need to be considered with at least as much weight as your functional requirements during your backlog planning and prioritization.
And now, the biggest mistake we see made in SaaS migrations…
1. Underestimate Inertia
Inertia is a powerful force. Over the years spent building up your on-premise capabilities, you’ve almost certainly developed tremendous inertia - defined for our purposes as “a tendency to do nothing or remain unchanged”. In order to achieve true SaaS, in order to satisfy your investors and reach SaaS-like multiples, nearly every part of your company needs to act differently.
How to Avoid?
First, ensure your entire company is ready to embrace change. For many companies, the move to SaaS is the only answer to an existential threat that a known (or unknown competitor) presents, one who is listening to your customers say “Get this IT stuff out of my shop!”. Examples of SaaS disruptors include:
- Salesforce destroying Siebel
- ServiceNow vs. Remedy
- Workday taking on Oracle/Peoplesoft
Is there a disruptor waiting to take over your business?
Many companies choose to disrupt themselves, and after switching to SaaS, drive their stock price through the roof. Look at Adobe’s stock price once they fully embraced (or made their customers embrace) SaaS over packaged software.
Regardless of how you position the importance of SaaS to your employees, there will still be some that are stuck by inertia in the on-prem ways. Either relegate them to stay with the on-prem effort, or ‘weed’ them out.
Once you’ve got some built up momentum and desire within your company to make the move to SaaS, make a concerted examination department-by-department to determine how they will need to change. All involved need to recognize the risk shifts as mentioned, and associated required mindsets. While you likely have excellent, seasoned on-prem employees, do you have enough SaaS experience across each team? The SaaS migration should in no way be treated solely as an engineering exercise.
It always comes as a shock how many departments need to break out of their existing inertia, and act differently. Some examples:
- Can no longer promise code customizations.
- Need to address cloud security concerns.
- Must ensure existing customers know they can no longer dictate when releases occur.
- Learn to speak ARR (annual recurring revenue).
- Should look at alternative revenue schemes (seat vs. utility).
- SaaS presents changes in revenue recognition. Be prepared.
- Should focus in iterative releases that enable product discovery.
- Must learn to balance the NFRs/”-ilities” along with new features.
- Need to consider alternative customers and markets for your new SaaS offering.
- Will likely need to become continually engaged in the PDLC process, in order to stay abreast of releases occurring at far greater frequency than old.
- Must develop (along with engineering) incident management processes that deal with multiple customers simultaneously having issues.
- Better spin up this department in a hurry!
- As no code-level customizations should be happening, you might end up reducing this team, focusing them more on integrations with your customers’ IT or 3rd party products.
Hmm, so much change for this department. Where to start? Start by bringing AKF on board to examine your SaaS migration effort. Here is where we can help you the most.
Subscribe to the AKF Newsletter
Open Source Software as a malware “on ramp”
August 21, 2018 | Posted By: Larry Steinberg
Open Source Software (OSS) is an efficient means to building out solutions rapidly with high quality. You utilize crowdsourced design, development and validation to conveniently speed your engineering. OSS also fosters a sense of sharing and building together - across company boundaries or in one’s free time.
So just pull a library down off the web, build your project, and your company is ready to go. Or is that the best approach? What could be in this library you’re including in your solution which might not be wanted? This code will be running in critical environments - like your SaaS servers, internal systems, or on customer systems. Convenience comes at a price and there are some well known situations of hacks embedded in popular open source libraries.
What is the best approach to getting the benefits of OSS and maintaining the integrity of your solution?
Good practices are a necessity to ensure a high level of security. Just like when you utilize OSS and then test functionality, scale, and load - you should be validating against vulnerabilities. Pre-production vulnerability and penetration testing is a good start. Also, utilize good internal process and reviews. Keep the process simple to maintain speed but establish internal accountability and vigilance on code that’s entering your environment. You are practicing good coding techniques already with reviews and/or peer coding - build an equivalency with OSS.
Always utilize known good repositories and validate the project sponsors. Perform diligence on the committers just like you would for your own employees. You likely perform some type of background check on your employees before making an offer - whether going to a third party or simply looking them up on linkedin and asking around. OSS committers have the same risk to your company - why not do the same for them? Understandably, you probably wouldn’t do this for a third party purchased solution, but your contract or expectation is that the company is already doing this and abiding by minimum security standards. That may not be true for your OSS solutions, and as such your responsibility for validation is at least slightly higher. There are plenty of projects coming from reputable sources that you can rely on.
Ensure that your path to production is only coming from artifacts which have been built on internal sources which were either developed or reviewed by your team. Also, be intentional about OSS library upgrades, this should planned and part of the process.
OSS is highly leveraged in today’s software solutions and provides many benefits. Be diligent in your approach to ensure you only see the upside of open source.
5 Focuses for a Better Security Culture
3 Practices Your Security Program Needs
Security Considerations for Technical Due Diligence
Subscribe to the AKF Newsletter
SaaS Risk and Value Shift
August 2, 2018 | Posted By: Marty Abbott
The movement to SaaS specifically, and more broadly “Anything” (X) as a Service (XaaS) is driven by demand side (buyer) forces. In early cases within any industry, the buyer seeks competitive advantage over competitors. The move to SaaS allows the buyer to focus on core competencies, increasing investments in the areas that create true differentiation. Why spend payroll on an IT staff to support ERP solutions, mail solutions, CRM solutions, etc when that same payroll could otherwise be spent on engineers to build product differentiating features or enlarge a sales staff to generate more revenue?
As time moves on and as the technology adoption lifecycle advances, the remaining buyers for any product feel they have no choice; the talent and capabilities to run a compelling solution for the company simply do not exist. As such, the late majority and laggard adopters are almost “forced” into renting a service over purchasing software.
Whether for competitive reasons, as in the case of early adopters through the early majority, or for lack of alternatives as in the case of late majority and laggards, the movement to SaaS and XaaS represents a shift in risk as compared to the existing purchased product options. This shift in risk is very much like the shift that happens between purchasing and leasing a home.
Renting a home or an apartment is almost always more expensive than owning the same dwelling. The reason for this should be clear: the person owning the property expects to make a profit beyond the costs of carrying a mortgage and performing upkeep on the property over the life of the owner’s investment. There are special “inversion” cases where renting is less expensive, such as in a low rental demand market, but these cases tend to reset the market ownership prices (house prices fall) as rents no longer cover mortgages or ownership does not make sense.
Conversely, ownership is almost always less expensive than renting or leasing. But owners take on more risk: the risk of maintenance activities; the risk of market prices; the risk and costs associated with remodeling to make the property attractive, etc.
The matrix below helps put the shift described above into context.
A customer who “owns” an on-premise solution also “owns” a great deal of risk for all of the components necessary to achieve their desired outcomes: equipment, security, power, licenses, the “-ilities” (like availability), disaster recovery, release management, and monitoring of the solution. The primary components of this risk include fluctuation in asset valuation, useful life of the asset, and most importantly – the risk that they do not have the right skills to maximize the value creation predicated on these components.
A customer who “rents” a SaaS solution transfers most of these risks to a provider who specializes in the solution and therefore should be better able to manage the risk and optimize outcomes. In exchange, the customer typically pays a risk premium relative to ownership. However, given that the provider can likely operate the solution more cost effectively, especially if it is a multi-tenant solution, the risk premium may be small. Indeed, in extreme cases where the company can eliminate headcount, say after eliminating all on-premise solutions, the lessee may experience an overall reduction in cost.
But what about the provider of the service? After all, the “old world” of simply slinging code and allowing customers to take all the risk was mighty appealing; the provider enjoyed low costs of goods sold (and high gross margins) and revenue streams associated with both licensing and customization. The provider expects to achieve higher revenue from the risk premium charged for services. The provider also expects overall margins through greater efficiencies in running solutions with significant demand concentration at scale. The risk premium more than compensates the provider for the increased cost of goods sold relative to the on-premise business. Overall, the provider assumes risk for greater value creation. Both the customer and the provider win.
Architecture and product financial decisions are key to achieving the margins above.
Gross margins are directly correlated with the level of tenancy of any XaaS provider (Y axis). As such, while we want to avoid “all tenancy” for availability reasons, we desire a high level of tenancy to maximize equipment utilization and increase gross margins. Other drivers of gross margins include the level of demand upon shared components and the level of automation on all components – the latter driving down cost of labor.
The X axis of the chart above shows the operating expense associated with various business models. Multi-tenant XaaS offerings collapse the number of “releases supported in the wild” – reducing the operating expense (and increasing gross margins) associated with managing a code base.
Another way of viewing this is to look at the relative costs of software maintenance and administration costs for various business models.
Plotted in the “low COGS” (X axis), “low Maintenance quadrant of the figure above is “True XaaS”. Few versions of a release reduce our cost to maintain a code base, and high equipment utilization and automation reduces our cost to provision a service.
In the upper right and unattractive quadrant is the ASP (Application Service Provider) model, where we have less control over equipment utilization (it is typically provisioned for individual customers) and less control over defining the number of releases.
Hosting a solution on-premise to the customer may reduce our maintenance fees, if we are successful in reducing releases, but significantly increases our costs. This is different than the on-premise model (upper left) in which the customer bears the cost of equipment but for which we have a high number of releases to maintain. The XaaS solution is clearly beneficial overall to maximize margins.
AKF Partners helps companies transition on-premise, licensed software products to SaaS and XaaS solutions. Let us help you on your journey.
Subscribe to the AKF Newsletter
The Phases of SaaS Grief
July 24, 2018 | Posted By: Marty Abbott
Over a decade of helping on-premise and licensed software companies through the transition to “Something as a Service” – whether that be Software (SaaS), Platform (PaaS), Infrastructure (IaaS), or Analytics (AaaS) – has given us a rather unique perspective on the various phases through which these companies transition. Very often we find ourselves in the position of a counselor, helping them recognize their current phase and making recommendations to deal with the cultural and operational roadblocks inherent to that phase.
While rather macabre, the phases somewhat resemble those of grieving after the loss of a loved one. The similarities make some sense here, as very often we work with companies who have had a very successful on-premise and/or licensed software business; they dominated their respective markets and “genetically” evolved to be the “alphas” in their respective areas. The relationship is strong, and their past successes have been very compelling. Why would we expect anything other than grieving?
But to continue to evolve, succeed, and survive in light of secular forces these companies must let their loved one (the past business) go and move on with a new and different life. To be successful, this life will require new behaviors that are often diametrically opposed to those that made the company successful in their past life.
It’s important to note that, unlike the grieving process with a loved one, these phases need not all be completed. The most successful companies, through pure willpower of the management team, power through each of these quickly and even bypass some of them to accelerate to the healing phase. The most important thing to note here is that you absolutely can move quickly – but it requires decisive action on the part of the executive team.
Phase 1: Denial This phase is characterized by the licensed/on-premise software provider completely denying a need to move to an “X” (something) as a Service (XaaS, e.g. SaaS, PaaS) model.
Commonly heard quotes inside the company:
• “Our customers will never move to a SaaS model.”
• “Our customers are concerned about security. IaaS, SaaS and PaaS simply aren’t an option.”
• “Our industry won’t move to a Cloud model – they are too concerned about ownership of their data.”
• “To serve this market, a solution needs to be flexible and customizable. Proprietary customer processes are a competitive advantage in this space – and our solution needs to map exactly to them.”
Reinforcing this misconceived belief is an executive team, a sales force, and a professional services team trapped in a prison of cognitive biases. Hypothesis myopia and asymmetric attention (both forms of confirmation bias) lead to psychological myopia. In our experience, companies with a predisposed bias will latch on to anything any customer says that supports the notion that XaaS just won’t work. These companies discard any evidence, such as pesky little startups picking up small deals, as aberrant data points.
The inherent lack of paranoia blinds the company to the smaller companies starting to nibble away at the portions of the market that the successful company’s products do not serve well. Think Seibel in the early days of Salesforce. The company’s product is too expensive and too complex to adequately serve the smaller companies beneath them. The cost of sales is simply too high, and the sales cycle too long to address the needs of the companies adopting XaaS solutions. In this phase, the company isn’t yet subject to the Innovator’s Dilemma as the blinders will not let them see it.
Ignorance is bliss…for awhile…
How to Avoid or Limit This Phase
Successful executive teams identify denial early and simply shut it down. They establish a clear vision and timeline to move to the delivery of a product as a service. As with any successful change initiative, the executive team creates, as a minimum:
1) The compelling reason and need for change. This visionary element describes the financial and operational benefits in clear terms that everyone can understand. It is the “pulling” force necessary to motivate people through difficult times.
2) A sense of fear for not making the change. This fear becomes the “stick” to the compelling “carrot” above. Often given the secular forces, this fear is quite simply the slow demise of the company.
3) A “villain” or competitor. As is the case in nearly any athletic competition, where people perform better when they have a competitor of equivalent caliber (vs say running against a clock), so do companies perform better when competing against someone else.
4) A “no excuses” cultural element. Everyone on the team is either committed to the result, or they get removed from the team. There is no room for passive-aggressive behavior, or behaviors inconsistent with the desired outcome. People clinging to the past simply prolong or doom the change initiative. Fast success, and even survival, requires that everyone be committed.
Phase 2: Reluctant but Only Partial Acceptance
This phase typically starts when a new executive, or sometimes a new and prominent product manager, is brought into the company. This person understands at least some of – and potentially all of – the demand side forces “pulling” XaaS across the curve of adoption, and notices the competition from below. Many times, the Innovator’s Dilemma keeps the company from attempting to go after the lower level competitors.
Commonly heard quotes inside the company:
• “Those guys (referring to the upstarts) don’t understand the complexities of our primary market – the large enterprise.”
• “There’s a place for those products in the SMB and SME space – but ‘real’ companies want the security of being on-premise.”
• “Sure, there are some companies entertaining SaaS, but it represents a tiny portion of our existing market.”
• “We are not diluting our margins by going down market.”
The company embarks upon taking all their on-premise solutions and hosting them, nearly exactly as implemented on-premise, as a “service”.
Many of the company’s existing customers aren’t yet ready to migrate to XaaS, but discussions are happening inside customer companies to move several solutions off-premise including email, CRM and ERP. These customers see the possibility of moving everything – they are just uncertain as to when.
How to Avoid or Limit This Phase
The answer for how to speed through or skip this phase is not significantly different than that of the prior phase. Vision, fear of death, a compelling adversary, and a “no excuses” culture are all necessary components.
Secular forces drive customers to seek a shift of risk. This shift is analogous to why one would rent instead of owning a home. The customer no longer wants the hassle of maintenance, nor are they truly qualified to perform that maintenance. They are willing to accept some potential increase in costs as capex shifts to opex, to relieve themselves of the burden of specializing in an area for which they are ill-equipped.
If not performed during the Denial phase, now is the time to remove executives who display behaviors inconsistent with the new desired SaaS Principles
Phase 3: Pretending to Have an Answer
The pretending phase starts with the company implementing essentially an on-premise solution as a “SaaS” solution. With small modifications, it is exactly what was shipped to customers before but presented online and with a recurring revenue subscription model. We often like to call this the “ASP” or “Application Service Provider” model. While the revenue model of the company shifts for a small portion of its revenue to recurring services fees, the solution itself has not changed much. In fact, for older client-server products Citrix or the like is often deployed to allow the solution to be hosted.
The product soon displays clear faults including lower than desired availability, higher than necessary cost of operations, higher than expected operating expenses, and lower margins than competitors overall. Often the company will successfully hide these “SaaS” results as a majority of their income from operations still come from on-premise solutions.
The company will often use nebulous terms like “Cloud” when describing the service offering to steer clear of direct comparisons with other “born SaaS” or “true SaaS” solutions. Sometimes, in extreme cases, the company will lie to itself about what they’ve accomplished, and it will almost always direct the conversation to topics seen as differentiating in the on-premise world rather than address SaaS Principles.
Commonly heard quotes inside the company:
• “Our ‘Cloud’ solution is world class – it’s the Mercedes of all solutions in the space with more features and functionality than any other solution.”
• “The smaller guys don’t have a chance. Look at how long it will take them to reach feature parity. The major players in the industry simply won’t wait for that.”
• “We are the Burger King of SaaS providers – you can still have it your way. And we know you need it your way.”
Meanwhile, customers are starting to look at true SaaS solutions. They tire of availability problems, response time issues, the customization necessary to get the solution to work in a suitable fashion and the lack of configurability. The lead time to implementation is still too long.
Sales people continue to sell the product the same way; promising whatever a customer wants to get a sale. Engineers still develop the same way, using the same principles that made the company successful on-premise and completely ignorant of the principles necessary to be successful in the SaaS world.
How to Avoid or Limit This Phase
It’s not completely a bad thing to launch, as a first step, a “hosted” version of a company’s licensed product. But the company must understand internally that it is only an interim step.
In addition to the visionary and behavioral components of the previous phases, the company now must accept and be planning for a smaller functionality solution that will be more likely adopted by “innovators” and “early majority” companies. The concept of MVP relative to the Technology Adoption Lifecycle is important here.
Further, the company must be aggressively weeding product, sales, and technology executives who lack the behaviors or skills to be successful and seeding the team with people who have “done this before”. Sales teams must act similarly to used car sales people in that they can only sell “what is on the lot” that will fit customer “need”, as compared to new car sales people who can promise options and colors from the factory (“It will take more time”) that more precisely fit a customer’s “want”.
Phase 4: Fear
The company loses its first major deal or two to a rival product that appears to be truly SaaS and abides by SaaS Principles. They realize that their ASP product simply isn’t going to cut it, and Sales people are finally “getting” that the solution they have simply won’t work. The question is: Is the company too late? The answer depends on how long it took the company to get to this position. A true SaaS solution is at the very least months away and potentially years away. If the company moves initially right to the “Fear” stage and properly understands the concepts behind the TALC, they have a chance.
Commonly heard quotes inside the company:
• “We’re screwed unless we get this thing re-architected in order to properly compete in the XaaS space.”
• “Stop behaving like we used to – stop promising customizations. That’s not who we are anymore.”
• “The new product needs to do everything the old product did.” [Incorrect and prone to failing]
• “Think smaller, and faster. Think some of today’s customers – not all of them – for the first release. Understand MVP is relative to the TALC.” [Correct and will help drive success]
How to Avoid or Limit This Phase
This is the most easily avoided phase. With proper planning and execution in prior phases, a company can completely skip the fear stage.
When companies find themselves here, its typically because they have not addressed the talents and approach of their sales, product, and engineering teams. Sales behaviors must change to only sell what’s “on the car lot”. Engineers must understand how to build the “-ilities” into products from day 1. Product managers must switch to identifying market need, rather than fulfilling customer want. Executives must now run an entirely different company.
Final Phase: Healing or Marginalization
Companies successful enough to achieve this phase do so only through launching a true XaaS product – one that abides by XaaS principles built and run by executives, managers and individual contributors who truly understand or are completely wedded to learning what it means to be successful in the XaaS world.
The phases of grief are common among many of our customers. But unlike grieving for a loved one, they are not necessary. Quick progression, or better yet avoidance, of these phases can be accomplished by:
1) Establishing a clear and compelling vision based on market and secular force analysis, and an understanding of the technology adoption lifecycle. As with any vision, it should not only explain the reason for change, but the positive long-term financial impact of change.
2) Ensuring that everyone understands the cost of failure, helping to instill some small level in fear that should help drive cultural change.
3) Ensuring that a known villain or competitor exists, against which we are competing to help boost performance and speed of transition.
4) Aggressively addressing the cultural and behavioral changes necessary to be successful. Anyone who is not committed and displaying the appropriate changes in behavior needs to be weeded from the garden.
This shift often results in a significant portion of the company departing – sometimes willingly and sometimes forcefully. Some people don’t want to change and can find other companies (for a while) where their skills and behaviors are relevant. Some people have the desire, but may not be capable of changing in the time necessary to be successful.
Subscribe to the AKF Newsletter
Factors Driving SaaS and XaaS Adoption
July 12, 2018 | Posted By: Marty Abbott
XaaS (e.g. SaaS, PaaS) mass-market adoption is largely a demand-side “pull” of a product through the Technology Adoption Lifecycle (TALC). One of the best books describing this phenomenon is the book that made the TALC truly accessible to business executives in technology companies, Crossing the Chasm.
An interesting side note here is that Crossing the Chasm was originally published in 1991. While many people associate the TALC with Geoffrey Moore, it’s actual origin is Everett Rogers’ research on the diffusion of innovations. Rogers’ initial research focused on the adoption of hybrid corn seed by rural farmers. Rogers and team expanded upon and generalized the research between 1957 and 1962 when he released his book Diffusion of Innovations. While the 1962 book was a critical success, I find it interesting that it took nearly 30 years to bring the work to most technology business executives.
Several forces combine to incent companies within each phase of the TALC to consider, and ultimately adopt, XaaS solutions. Progressing from left to right through the TALC, companies within each phase are decreasingly less aware of these forces and increasingly more resistant to them until the forces are overwhelming for that segment or phase. Innovators, therefore, are the most aware of emerging forces, seek to use them for competitive advantage and as a result are least resistant to them. Laggards are least aware (think heads in the sand) and most resistant to change, desiring status quo over differentiation.
While the list below is incomplete, it has a high degree of occurrence across industries and products. Our experience is that even when they are experienced in isolation (without other demand side XaaS forces), they are sufficient to pull new XaaS products across the TALC.
Demand Side Forces
Talent Forces: Opportunity, Supply and Demand
The first two forces represent the talent available to the traditional internally focused corporate IT organization. The rise of XaaS offerings and the equity compensation opportunities inherent to them has been a vacuum sucking what little great talent exists within corporate IT. This first force really serves to add insult to injury to the second force: the initial low supply of talented engineers available in the US.
Think about this: Per-capita (normalized for population growth) US graduates for engineers within the US has remained relatively constant since 1945. While there has been absolute growth, until very recently that growth has slightly underperformed relative to the growth in population. Contrast this with the fact that college graduation rates in 2012 were higher than high school graduation rates in 1940. Add in that most engineering fields were at or near economic full employment during the great recession and we have a clear indication that we simply do not produce enough engineers for our needs. The same is true on a global level.
This constrained supply has led to alternative means of educating programmers, systems administrators, database administrators and data analysts. “Boot Camps”, or short courses meant to help teach people basic skills to contribute to the product and IT workforces, have sprung up around the nation to help fulfill this need. Once trained, the people fulfill many lower level needs in the product and IT space, but they are not typically equivalent to engineers with undergraduate degrees.
Constrained supply, growing demand and a clear differentiation in employment for engineers working in product organizations compared to IT organizations means that IT groups simply aren’t going to get great talent. Without great talent, there can be no great development or operations teams to create or run solutions. As such, the talent forces alone mandate that many IT teams look to outsource as much as they can: everything from infrastructure to the platforms that help make employees more efficient.
Core vs. Context
Why would a company spend time or capital on running third party solutions or developing bespoke solutions unless those activities result in competitive differentiation? Doing so is a waste of precious time and focus. Companies simply can’t waste time running email servers, or building CRM solutions and soon will find themselves not spending time on anything that doesn’t directly lend itself to competitive advantage.
Put simply, anytime a company can’t maximize profit margins through keeping in-house systems highly utilized, they should (and will) seek to outsource the workload to an IaaS provider. Why purchase a server to do work 8 hours a day and sit idle 16? Why purchase a server capable of handling peak period of 10 minutes of traffic, when a server one fifth its size is all that’s needed for the remainder of the day?
Part of staying competitive is focusing on profit maximization to invest those profits in other, higher return opportunities. Companies that don’t at least leverage Infrastructure as a Service to optimize their costs of operations and costs of goods sold (if doing so results in lowered COGS) are arguably violating their fiduciary responsibility.
Risk is the probability that an event occurs, multiplied by the impact of that event should it occur. Companies that specialize in providing a service, whether it be infrastructure as a service or software as a service typically have better skills and more experience in providing that service than other companies. This means that they can both reduce the probability of occurrence and likely the impact of the occurrence should it happen. Anytime such a risk shift is possible, where company A can shift its risk of operating component B to a company C specializing in managing that risk at an affordable price, it should be taken. The XaaS movement provides many such opportunities.
Time to Market
One of the most significant reasons why companies choose either SaaS or IaaS solutions is the time to market benefit that their usage provides. In the SaaS world, it’s faster and easier to launch a solution that provides compelling business efficiencies than purchasing, implementing and running that system in-house. In the IaaS world, infrastructure on demand is possible and companies need not wait for onerous lead times associated with ordering and provisioning equipment.
Focus on Returns
Most projects, including packaged software purchased and implemented on site are delivered late and fail to produce the returns on which the purchase was predicated. Further, these projects are “hard to kill”, with millions invested and long depreciation cycles; companies are financially motivated to “ride” their investments to the bitter end in the hopes of minimizing the loss. In the extreme, XaaS solutions offer a simple way to flee a sinking ship: leave. Because the solution is leased, you can (obviously with some work) switch to a competing provider. Capital is freed up in the company for higher return investments associated with revenue rather than costs.
The outcomes of these factors is clear. In virtually every industry, and for nearly every product, companies will move from on-premise or built-in-house solutions to XaaS solutions. CEOs, COOs, CTOs and CIOs will all seek to “Get this stuff out of my shop!”
Companies that believe it will never happen in their industry are simply kidding themselves and completely ignoring the outcomes predicted within the technology adoption life-cycle. Every company needs to focus on fewer, higher value things. Every company should outsource risky operational activities if there is a better manager of that risk than them. Every company is obligated to seek better margins and greater profitability – even those companies in the not for profit sector need to maximize the benefit of every donated dollar. Every company seeks opportunities to bring their value to market faster. And finally, few companies can find the great talent in today’s market necessary to be successful in their corporate IT and product operations endeavors.
If you produce on-premise, licensed software products and have not yet considered the movement to a SaaS solution, you need to do so now. Failing to do so could mean the demise of your company.
We are experts in helping companies migrate products to the XaaS model. Contact us - we would love to help you.
Subscribe to the AKF Newsletter
SaaS Principles Part 2
June 29, 2018 | Posted By: Marty Abbott
Following our first article on the conflict between licensed products and SaaS solutions, we now present a necessary (but not always sufficient) list of SaaS operating principles. These principles are important whether one is building a new XaaS (PaaS, SaaS, IaaS) solution, or migrating to an XaaS solution from an on-premise, licensed product.
These principles are developed from the perspective of the product and engineering organization, but with business value (e.g. margins) in mind. They do not address the financial or other business operations needs within a SaaS product company.
1. Build to Market Need – Not Customer Want
Reason: Smaller product (less bloat). Lower Cost of Goods (COGS). Lower R&D cost.
Customer “wants” now help inform and validate professional product management analysis as to what true market “need” is for a product. Products are based on the minimum viable product concept and iterated through a scientific method of developing a hypothesis, testing that hypothesis, correcting where necessary and expanding it when appropriate. Sales teams need to learn to sell “the cars that are on the lot”, not sell something that is not available. Smaller, less bloated, and more configurable products are cheaper to operate, and less costly to maintain.
2. Build “-ilities” First
Reason: Availability, Customer Retention, and high Revenue Retention.
Availability, scalability, reliability, and nearly always on “utility” are now a must have, as the risk of failure moves from the customer in the on-premise world to the service provider. No longer can product managers ignore what was once known as NFRs or “Non-Functional Requirements”. The solution must always meet, as a bare minimum, the availability and response times necessary to be successful while scaling in a multi-tenant way under hopefully (significant) demand.
3. Design to be Monitored
Reason: Availability, Customer Retention, and high Revenue Retention.
Sometimes considered part of the “ilities” to achieve specifically high availability, we call this one out specifically as engineers must completely change behavior. Like the notion of test driven development, this principle requires that engineers think about how to log and create data to validate that the solution works as expected before starting development. Gone are the days of closing a defect as “working as designed” – we now promote solutions to production that can easily validate usage and value creation and we concern ourselves only with “Does it work as expected for customer benefit?”
4. Design for Easy and Efficient Operations – Automate Always
Reason: Lower COGS. Availability.
Everything we do to develop product and deliver a customer experience needs to be enabled through automation: environment creation, product releases, system analysis, database upgrades, etc. Whether this happens within a traditional operations team, a DevOps group, or product engineering, automation is part of our “whole product” and “ships” with our service solution upgrades.
5. Design for Low Cost of Operations
Reason: Lower COGS.
Automation helps us lower the cost of operations, but we must also be cognizant of infrastructure related costs. How do we limit network utilization overall, such that we can lower our costs associated with transit fees? How do we use less memory footprint and fewer compute cycles to perform the same activity, such that we can reduce server infrastructure related costs? What do we really need to keep in terms of data to reduce storage related costs? Few if any of these things are our concerns on-premise, but they all affect gross margin when we run a SaaS business.
6. Engage Developers in Incident Resolution and Post Mortems
Reason: Faster Time to Resolution. Availability. Better Learning Processes.
On premise companies value developer time because new feature creation trumps everything else. SaaS companies know that restoring services is more important than anything else. Further, developers must understand and “feel” customer pain. There is no better motivation for ensuring that problems do not recur, and that we create a learning organization, than ensuring engineers understand the pain and cost of failure.
7. Configuration over Customization
Reason: Smaller Product. Lower COGS. Lower R&D Cost. Higher Quality.
One “core”, lots of configuration, no customization is the mantra of every great SaaS company. This principle enables others, and aids in creating a smaller code base with lower development costs and lower costs of operations. Lower cyclomatic complexity means higher quality, lower cost of future augmentation, and lower overall maintenance costs.
8. Create and Maintain a Homogeneous Environment
Reason: Lower COGS.
Just as the software that enables our product should not be unique per customer, similarly the infrastructure and configuration of our infrastructure should not be unique per customer. Everyone orders off the menu, and the chef does not create something special for you. The menu offers opportunities for configurations – sometimes at costs (e.g. bacon on your burger) but you cannot substitute if the menu does not indicate it (e.g. no chicken breast).
9. Publish One Single Release for All Customers
Reason: Decreased COGS. Decreased R&D Cost (low cost of maintenance).
The licensed software world is lousy with a large engineering burden associated with supporting multiple releases. The SaaS world attempts to increase operating margins by significantly decreasing, ideally to one, the number of versions supported for any product.
10. Evolve Your Services, Don’t Revolutionize Them
Reason: Easier Upgrades. Availability. Lower COGS.
No customer wants downtime associated with an upgrade. The notion is just ridiculous. How often does your utility company take your service offline (power for instance) because they need to perform an “upgrade”? Infrequently (nearly never) at best – and if/when they do it is a giant pain for all customers. Our upgrades need to be simple and small, capable of being reversed, and “boil the frog” as the rather morbid saying goes. No more large upgrades with significant changes to data models requiring hours of downtime and months of preparation on the part of a customer.
11. Provide Frequent Updates
Reason: Smaller product (less bloat). Lower COGS. Lower R&D cost. Faster Time to Market (TTM).
Pursuant to the evolutionary principle above, updates need to happen frequently. These two principles are really virtuous (or if not performed properly, vicious) when related to each other. Doing small upgrades, as solutions are ready to ship, means that customers (and our company) benefit from the value the upgrades engender sooner. Further, small upgrades mean incremental (evolutionary) changes. Faster value, smaller impact. It cures all ills and is both a dessert topping and floor wax.
12. Hire and Promote Experienced SaaS Talent
Reason: Ability to Achieve Goals and SaaS Principles.
Running SaaS businesses, and developing SaaS products require different skills, knowledge and behaviors than licensed, on premise products. While many of these can be learned or trained, attempting to be successful in the XaaS world without ensuring that you have the right knowledge, skills, and abilities on the team early on is equivalent to assuming that all athletes can play all sports. Assembling a football team out of basketball players is unlikely to land you in the Super Bowl.
13. Restrict Access
Reason: Lower Risk. Higher Availability.
Licensed product engineers rarely have access to customer production environments. But in our new world, its easy to grant it and in many ways it can be beneficial. Unfortunately, unfettered access increases the risk of security breaches. As such, we both need to restrict access to production environments and ensure that the engineering team has access to appropriate trouble shooting data outside of the production environment to ensure rapid problem and incident resolution.
14. Implement Multi-Tenancy
Reason: Lower COGS.
Solutions should be multi-tenant to enable better resource utilization, but never all-tenant to ensure that we have proper fault isolation and appropriate availability.
How is your SasS product performing? Need a checkup? We can help
Need help with your SaaS migration?
Subscribe to the AKF Newsletter
SaaS Principles Part 1 - The Conflict between Licensed Software and SaaS
June 22, 2018 | Posted By: Marty Abbott
Photo Credit: www.icomputerdenver.com
Attempting to migrate on-premise, licensed products to a recurring revenue SaaS (XaaS) solution is perhaps one of the most difficult things a company can do. As Dave Swenson writes in SaaS Migration Challenges, changes are often necessary to the fabric of the company, including the company culture and mindset.
In many cases, the principles that make a company successful in the on-premise, packaged software model are insurmountable barriers to success in XaaS. As an example of the difficulty of this transition, consider one group of opposing principles endemic to SaaS transition: building to customer want (licensed model) versus building to market need (SaaS model). For years, on-premise providers were successful by filling their product backlog with customer requests (or “wants”). When requests were specific to a single customer and didn’t appear to be extensible to a broader base, a revenue stream associated with professional services was created. Professional services, or a system integrator, would make modifications to source code creating a unique “version” for that customer. This approach led to bloated products, oftentimes with a single customer using less than 30% of a product’s capabilities. Moreover, release “skew” developed, increasing the cost of maintenance of multiple releases in “the wild”.
Contrast this with a product approach that attempts to “discover” the intersection of true market need. Product backlogs are built primarily on thorough market analysis coupled with experimentation. Customer asks (or “wants”) help inform prioritization, but are not the primary driver of product backlog. Sales organizations focus on selling the existing product rather than driving it, and the role of professional product managers emerge. This notion of “want” vs. “need” is critical to the success of a company’s transformation.
The difficulty of such a journey from “want” in the licensed product world to “need” in the XaaS world should be clear to everyone. If the difficulty is high in a transition, imagine the stressful forces a company must endure to live in both worlds for an extended period of time. Sales organizations that build upon selling a customer “whatever they desire” often revolt at being relegated to selling only what exists. Product management organizations that previously acted like “business analysts” taking requirements, now need to perform real market analysis, understand discovery and experimentation and get “closer to the market”. How does one build a company that can be successful in both worlds at once? Difficult indeed given the chasm between one approach and the other.
The figures below indicate a handful of the most common opposing forces as examples of how companies need to “reinvent themselves” and think differently to be successful as a XaaS provider.
Purchase versus Lease
At the root of many of the differences between Licensed/On-Premise products (or licensed products that are hosted in ASP-like models) and true XaaS products is the notion of what the customer expects with the sales transaction. In the licensed model, customers want outcomes but understand they are purchasing software. The customer understands that much of the risk of running the software including the “ilities” like availability and scalability are borne by the customer.
In the SaaS world, the customer mindset is that of leasing outcomes. Comparatively low switching costs (compared to on-premise) allows the customer to more easily move should they not achieve their desired outcomes. As such, service providers must move closer to the customer and better understand, in real time, customer expectations and the product’s performance to those expectations.
To highlight this difference, consider the difference between renting a home and owning a home. In most markets, the total cost of rent against the combination of amortized home values over an equivalent period and the residual (resale value) of the home indicates that renting is more expensive. But a majority of the risk of renting exists with the leasor including home maintenance, risk associated with loss to catastrophe, etc. The same is true with SaaS compared to owning a product: SaaS requires the service provider to take on significantly greater risk compared to selling a product to a customer.
Want versus Need
Henry Ford perhaps said it best when he said, “If I’d asked customers what they want, they would have told me a faster horse.” Steve Jobs agreed with Ford, indicating that people don’t know what they want until you show it to them. Here Steve is referring to true “need” vs. a stated customer “want”. Licensed products often start with customer wants. Sales teams garner desires, and either force them into product backlogs or sell modifications through professional services. Because the customer purchases the software, the company isn’t as incented as the SaaS model to ensure that the customer gets value from that which they purchased. The product development lifecycle, regardless of how it is represented to the customer, is almost always in fact waterfall.
XaaS companies attempt to “find” (aka discover) market need. Product managers analyze markets, establish goals, create hypotheses to achieve these goals, and co-create solutions to test these hypotheses with their engineering teams. What a customer may indicate as a “want” may help inform prioritization of the backlog especially if there is an intersection in customer desired outcomes.
Operations Afterthought versus Designed for Efficient Operations
In the on-premise world, the customer is responsible for the cost of operations and the effective and efficient operations of any solution. Considerations such as monitoring for early fault and incident detection are at best after thoughts in the world of on-premise software development, giving rise to an industry specializing in after market monitoring. The reasoning behind this approach is clear – time spent producing efficient solutions that can be easily maintained takes away from new feature development and new revenue associated with those features.
In the SaaS world, we are responsible for our own cost of operations and therefore building products that operate efficiently with low cost of goods sold is important to achieving high gross margins and profit margins. Furthermore, as we are responsible for all the “ilities” (described below), we must design our solutions to be monitored in real time to detect errors, faults, problems and incidents.
Revolutionary versus Evolutionary
Put simply, on-premise models rely on “fork-lift” major product upgrades that often take significant effort, downtime and customer expense to implement. The latter is often seen as a bonus to the provider of software, as upgrades can become an additional revenue stream for professional services both in assisting with the upgrade and re-implementing customizations lost during the upgrade.
XaaS products simply can’t afford the downtime, or cost associated with revolutionary implementations. As such data models and functionality evolve quickly but iteratively with the capability to completely roll back or “undo” both schema modifications and functionality additions.
Many Releases versus Single Release
Because on-premise companies can rarely force patch or release adoption across their installed base (they typically have no access to these environments), the number of releases they support may be in the 100s or even 1000s. This release skew increases operating expenses as a large portion of engineering may be spent supporting problems across a very large number of releases.
SaaS companies recognize that release skew increases the cost of development, and as such, force most customers into a single (or no more than 3) releases. Companies that fail in this principle face on-premise-like operating margins as engineering budgets increase to support releases.
Customization Equals Revenue versus Customization Equals Cost of Operations
On premise companies see customization as a valuable revenue stream, often at the expense of increased engineering budgets to support the maintenance of these customizations and the distractions they cause.
SaaS companies abhor customization and favor configuration, leading to higher quality products and better overall customer experiences.
Features First versus “-ilities” First
While all of the XaaS principles are important, one of the most difficult to grasp for our on-premise clients is the notion that the “-ilities” (sometimes called NFRs or Non Functional Requirements in waterfall development) like availability, scalability, reliability, etc are now the most important feature within their products. It pains me to even call them a feature, as they are the “table stakes” (the ante, the price we pay) for the game in which we participate.
License/on-premise companies can punt on the “-ilities” because the customer is accountable for running the solution and bears a good portion of the risk. Availability impacts like hardware failures are ultimately the responsibility of the customer. The decision to pay for high availability represented through infrastructure is also the responsibility of the customer.
These “-ilities” steal time from engineering teams – and appropriately so – to ensure the quality of the service provided. Feature production is still important – it’s just second in line behind ensuring that the solution is available for value creation.
Developers Protected versus Developers Front-Lines
Because feature production is highly correlated with revenue in the licensed software model, companies often protect developer time with multiple layers of support. When customers have outages, companies attempt to resolve them with lower cost support personnel before stealing development time from critical projects. Licensed product companies can get away with this because when there is a failure at a customer site a comparatively small portion of revenue and customer base is at risk.
In the XaaS model, multiple customers are likely impacted with any outage due to increased tenancy. And because we believe that availability is one of the most important features, we must respond with the resources necessary to resolve an incident as quickly as possible.
This is yet another sticking point with companies making the SaaS transition: sometimes significant portions of engineering organizations do not want to be on call. Those people simply have no role in a utility company-like model where “dial tone” is essential.
Part 2 describes a set SaaS principles derived from the conflict inherent to a migration from licensed products to the XaaS model.
The move from on-premise, licensed software revenue models to XaaS models is difficult. Many of the principles that make an on-premise company successful are diametrically opposed to success in SaaS. The longer a company must operate in both models, the more likely the culture, mindset and fabric of the company will be stretched. Many successful companies decide to operate the two businesses separately, to ensure that one culture is not influenced negatively by the other.
AKF Partners has aided a number of companies in their journey from on-premise to SaaS. Read more about our SaaS migration services.
Subscribe to the AKF Newsletter
June 11, 2018 | Posted By: Marty Abbott
Of the many SaaS operating principles, perhaps one of the most misunderstood is the principle of tenancy.
Most people have a definition in their mind for the term “multi-tenant”. Unfortunately, because the term has so many valid interpretations its usage can sometimes be confusing. Does multi-tenant refer to the physical or logical implementation of our product? What does multi-tenant mean when it comes to an implementation in a database?
This article first covers the goals of increasing tenancy within solutions, then delves into the various meanings of tenancy.
Multi-Tenant (Multitenant) Solutions and Cost
One of the primary reasons why companies that present products as a service strive for higher levels of tenancy is the cost reduction it affords the company in presenting a service. With multiple customers sharing applications and infrastructure, system utilization goes up: We get more value production out of each server that we use, or alternatively we get greater asset utilization. Because most companies view the cost of serving customers as a “Cost of Goods Sold’, multitenant solutions have better gross margins than single-tenant solutions. The X Axis of the figure below shows the effect of increasing tenancy on the cost of goods sold on a per customer basis:
Interestingly, multitenant solutions often “force” another SaaS principle to be true: No more than 1 to 3 versions of software for the entire customer base. This is especially true if the database is shared at a logical (row-level) basis (more on that later). Lowering the number of versions of the product, decreases the operating expense necessary to maintain multiple versions and therefore also increases operating margins.
Single Tenant, Multi-Tenant and All-Tenant
An important point to keep in mind is that “tenancy” occurs along a spectrum moving from single-tenant to all-tenant. Multitenant is any solution where the number of tenants from a physical or logical perspective is greater than one, including all-tenant implementations. As tenancy increases, so does Cost of Goods Sold (COGS from the above figure) decrease and Gross Margins increase.
The problem with All-Tenant solutions, while attractive from a cost perspective, is that they create a single failure domain [insert https://akfpartners.com/growth-blog/fault-isolation], thereby decreasing overall availability. When something goes poorly with our product, everything is off line. For that reason, we differentiate between solutions that enable multi-tenancy for cost reasons and all-tenant solutions.
The Many Meanings and Implementations of Tenancy
Multitenant solutions can be implemented in many ways and at many tiers.
Physical and Logical
Physical multi-tenancy is having multiple customers share a number of servers. This helps increase the overall utilization of these servers and therefore reduce costs of goods sold. Customers need not share the application for a solution to be physically multitenant. One could, for instance, run a webserver, application server or database per customer. Many customers with concerns over data separation and privacy are fine with physical multitenancy as long as their data is logically separated.
Logical multi-tenancy is having data share the same application. The same webserver instances, application server instances and database is used for any customer. The situation becomes a bit murkier however when it comes to databases.
Different relational databases use different terms for similar implementations. A SQLServer database, for instance, looks very much like an Oracle Schema. Within databases, a solution can be logically multitenant by either implementing tenancy in a table (we call that row level multitenancy) or within a schema/database (we call that schema multitenancy). In either case, a single instance of the relational database management system or software (RDBMS) is used, while customer transactions are separated by a customer id inside a table, or by database/schema id if separated as such.
While physical multitenancy provides cost benefits, logical multitenancy often provides significantly greater cost benefits. Because applications are shared, we need less system overhead to run an application for each customer and thusly can get even greater throughput and efficiencies out of our physical or virtualized servers.
Depth of Multi-Tenancy
The diagram below helps to illustrate that every layer in our service architecture has an impact to multi-tenancy. We can be physically or logically multi-tenant at the network layer, the web server layer, the application layer and the persistence or database layer.
The deeper into the stack our tenancy goes, the greater the beneficial impact (cost savings) to costs of goods sold and the higher our gross margins.
The AKF Multi-Tenant Cube
To further the understanding of tenancy, we introduce the AKF Multi-Tenant Cube.
The X axis describes the “mode’ of tenancy, moving from shared nothing, to physical, to logical. As we progress from sharing nothing to sharing everything, utilization goes up and cost of goods sold goes down.
The Y axis describes the depth of tenancy from shared nothing, through network, web, app and finally persistence or database tier. Again, as the depth of tenancy increase, so do Gross Margins.
The Z axis describes the degree of tenancy, or the number of tenants. Higher levels of tenancy decrease costs of goods sold, but architecturally we never want a failure domain that encompasses all tenants.
When running a XaaS (SaaS, etc) business, we are best off implementing logical multitenancy through every layer of our architecture. While we want tenancy to be high per instance, we also do not want all tenants to be in a single implementation.
AKF Partners helps companies of all sizes achieve their availability, time to market, scalability, cost and business goals.
Subscribe to the AKF Newsletter
1 2 >