GROWTH BLOG: Focus Versus Agility in Business, Product Management and Product Development
AKF Partners Logo Technology ConsultingScalability - We wrote the book on it ℠

Growth Blog

Scalability and Technology Consulting Advice for SaaS and Technology Companies

Migrating To The Cloud: Lift and Shift Versus Cloud Native

August 20, 2019  |  Posted By: Dave Berardi


If your company doesn’t utilize one of the big cloud providers for either IaaS or PaaS as part of product infrastructure, it’s only a matter of time. We often find our clients in situations where they are pressured to move quickly for benefit-realization to improve many aspects of their business.

Drivers of this trend that exist across our client base and the industry include:

  • The Need For Speed and Time To Market: The need to scale capacity quickly without waiting weeks or months for hardware procurement and provisioning in your own datacenter or colo.
  • Traditional On-Prem Software Dying by 1000 Cuts: Demand-side (buyer) forces are encouraging companies to get services and software out of data centers. Cloud-native SaaS competition is pressuring what’s left of the on-prem software providers.
  • Legacy Company Talent Challenges: The inability of the old economy companies to hire engineering talent to support on-prem software in house.

Several different approaches can be used for migration. We’ve seen many of them and there are two on opposite ends of the spectrum – Lift and Shift and Cloud-Native – that we want to unpack.


The Lift and Shift Approach:

What is it?

waiting for challenger launch - normalization of deviance

Put simply, this is when the same architecture, resources, and services from an on-prem or colo data center are moved up into a cloud provider. Often VMs from on-prem hosting centers are converted and dropped into reserved virtual compute instances. Tools such as AWS Connector for vCenter or GCP’s Velostrata, in theory, allow for an easy transition.

Pros

  • Fastest path to cloud
  • Same architecture and tech stack minimizes training need – infrastructure management does require knowledge of the console
  • Least costly in terms of planning, architecture changes, refactoring

Cons

  • Monolithic nature of the architecture can prove to be costly thru BYOL and compute requirements
  • Minimal use of native elasticity and resources create cost-inefficient use of compute, memory, and storage and may not perform as needed
  • Technical debt migrates with the product and cost could be magnified with additional problems and a shift to the pay for use model

While Lift and Shift seems to be the easiest path, you need to be aware of the strong potential for an increase in cost in the cloud. Running VMs in your own DC and colo masks the cost inefficiencies since they are all part of Capex for your compute, storage, and network. When you move to public cloud the provider will promise to be cheaper. But in the cloud you will pay for every reserved CPU that isn’t utilized, storage that isn’t used, and other idle resources. Further, your availability can only be as good as the provider’s uptime for a given Region and/or Availability Zone.


Cloud Native Approach:

What is it?

waiting for challenger launch - normalization of deviance

Cloud-Native approach ultimately allows for the use of a provider’s cloud services as long as there are requests and demand being created by product users. This approach almost always requires investment into splitting the monolith and moving to a services-separated architecture. In addition, it could require you to use native services in your provider of choice. Doing so lets you move from paying for provisioned infrastructure to consumption-based services with better cost-efficiency.

Pros

  • Less time needed to manage infrastructure and more time for features and experimentation
  • Easier to scale out using native services
  • Most cost-efficient

Cons

  • Slowest path to cloud
  • More discovery and training - this approach requires your teams to understand the current tech stack in order to recreate them in cloud. From a cloud perspective they must understand how the provider of choice works so that decisions can be made on native services.
  • Increased risk of vendor lock-in (eg. Building out event-driven services with rules inside of native serverless)

The Cloud Native path is a longer one, but provides several benefits that will yield more value over time. With this approach you must spend time determining how to split up your monolith and how to best leverage the right combination of Availability Zones, Regions, and use of native services depending on your Recovery Time Objective (RTO) and Recovery Point Objectives (RPO). We prefer to solve scalability and availability problems with systems and software architecture to avoid vendor lock-in. All of the trade-offs on such a journey must be understood.

We have helped several companies of various sizes move to the cloud going thru SaaS transformations and have engaged in reviewing proposed architectures. Contact us to see how we can help.

Subscribe to the AKF Newsletter

Contact Us

The Easiest and Hardest Jobs in Software Companies

July 31, 2019  |  Posted By: Marty Abbott

New Car Salesman

The Easiest Job

Hands down, the easiest job in any company that produces software for on-premise delivery is the sales job.

Everything is magically aligned to make this job “easy” on a relative basis.

  • The more a producing company promises, the more the purchasing company wants.
  • The more the customer wants, the larger the contract becomes.  If the software doesn’t do it today, the producing company adds in professional services fees to customize the software.
  • The more you promise, the higher the probability of closing a deal.

In many ways, being an on-premise software salesperson is very much like being a new car dealer.  The dealer (or software producer) has several new cars on the lot that the customer can just drive away in today.  If the customer wants something special, the dealer can very likely configure it and order it from the factory – the customer just needs to wait awhile.  These options cost a bit more and take a bit longer to produce. 

Leather seats?  Sure – we have that.  Different color?  We have 25 colors from which to choose.  Finally, if the customer’s desire is far afield from what the factory can fulfil (special paint effects, spoilers, ground effect lighting, etc.), the dealership either has an auto shop that can fulfil the request, or a relationship with an auto shop somewhere in town from which the dealer receives a referral fee. 

Sure, your software product still must compete well with the other providers in your space just as Chevy’s products must compete well with Ford, Dodge, Toyota, etc.  But assuming you have a viable product, meeting a customer’s needs is not very difficult (for the salesperson) and the more the customer wants the more the company (and the salesperson) makes!

That’s not to say that just anyone can be a salesperson or that the sales job is “easy” (remember – we used relative terms like easiest and easier).  We know that not all of us get excited about hitting the road every day, living on planes and in hotels, and putting a smile on in front of people we barely know. 

We’re just saying that on a comparative basis, it’s easier than most other jobs in the company (engineering, product management, finance, etc.) and a whole lot easier than the alternative job in software sales.

The Hardest Job


Kurt Russell in Used Cars (1980)

Kurt Russell, Used Cars (1980)


Contrast the on-premise software sales job with what is very likely the hardest job in the software industry – that of the Software as a Service (SaaS) salesperson.  The root of this difference in difficulty, lies within the principles necessary for SaaS to be successful – specifically building to market need instead of customer want

Whereas on-premise sales are bolstered by adding the entirety of a customer’s wants into a contract (thereby increasing the value of each contract), such a process creates bloated and unmaintainable SaaS solutions.  To be successful in a SaaS world, we need configuration over customization and homogeneous environments

To that end, successful SaaS salespeople have a job that’s very similar to that of a used car salesperson.  I know, the metaphor conjures up cheap, rumpled suits and people who wreak of desperation.  But consider the job for a minute – it is quite difficult.  The used car salesperson needs to converge customer wants into something that he or she has on the lot or there isn’t going to be a sale. 

There is no factory from which to order specific configurations.  The dealership isn’t likely to have an after-market shop for bespoke requests.  The salesperson must be a bit of a magician in somehow force fitting a laundry list of customer desires into some vehicle that’s sitting on the lot. 

I’ll say that again – the used car salesperson can only sell what’s on the lot.  This is similarly true with SaaS salespeople – they need to find a way to convince a customer that their wants are served by a product’s existing capabilities.

Mature SaaS products evolve into having a great deal of customer configurable items that allow for incredible extensibility.  But those configurations don’t typically exist in early stage companies.  Even more mature SaaS solutions implement APIs that allow for off-platform extensions of product capabilities. 

Does your customer want a unique workflow engine?  A mature solution allows for the current workflow to be turned off and for another workflow to be plugged into the system using APIs. 

Does your customer want to use a different order fulfillment solution?  A mature solution allows for the warehouse management component to be disabled and replaced via asynchronous stubs and APIs to another providers fulfillment services. Once API extensions are available, professional services teams can again begin to create revenue streams from customer wants.

The key point remains that sales teams in SaaS solutions cannot go “off script”. They must only sell what’s “on the truck” or “on the lot”.

Allowing SaaS sales teams to behave in the same fashion as on-premise sales teams will cause:

  • High levels of customer dissatisfaction when products can’t be delivered
  • High churn and slow time to market in the engineering organization
  • Incredible “whiplash” in product management (rapid change of priorities)
  • Soaring software maintenance costs for the company as revisions “in the wild” increase relative to other SaaS firms. 
  • High costs of goods sold as infrastructure costs rise to meet the needs of product skew and code complexity

All of these will combine to make the company, over time, under perform relative to competitors.  Ultimately the company’s SaaS solution will become bloated, noncompetitive and the company’s SaaS solution will fail.

This change in selling behavior is so significant that we often find on-premise sales organizations incapable of making the transition to the SaaS mentality and necessary way of selling.  Many companies with which we work go through a cycle of trying to retain their original sales force, seeing that the organization’s behaviors are inconsistent with need too late as product time to market slows and margins decline, and then replacing large portions of the sales team late in the game.


AKF Partners helps companies transition to a SaaS model and mindsetGive us a call – we can help!

Subscribe to the AKF Newsletter

Contact Us

Transforming to SaaS is not just a technology change

June 19, 2019  |  Posted By: Larry Steinberg


Transforming a traditional on-premise product and company to a SaaS model is currently in vogue and has many broad-reaching benefits for both producers and consumers of services. These benefits span financial, supportability, and consumption simplification. 

In order to achieve the SaaS benefits, your company must address the broad changes necessitated by SaaS and not just the product delivery and technology changes. You must consider the impact on employees, delivery, operations/security, professional services, go to market, and financial impacts.

Employee Transformation

The employee base is one key element of change – moving from a traditional ‘boxed’ software vendor to an ‘as a Service’ company changes not only the skill set but also the dynamics of the engagement with your customers. Traditionally staff has been accustomed to having an arms-length approach for the majority of customer interactions. This traditional process has consisted of a factory that’s building the software, bundling, and a small group (if any) who ‘touch’ the customer. As you move ‘to as a service’ based product, the onus on ensuring the solution is available 24x7 is on everyone within your SaaS company. Not only do you require the skillsets to ensure infrastructure and reliability – but also the support model can and should change.

Now that you are building SaaS solutions and deploy them into environments you control, the operations are much ‘closer’ to the engineers who are deploying builds. Version upgrades happen faster, defects will surface more rapidly, and engineers can build in monitoring to detect issues before or as your customers encounter them. Fixes can be provided much faster than in the past and strict separation of support and engineering organizations are no longer warranted. Escalations across organizations and separate repro steps can be collapsed. There is a significant cultural shift for your staff that has to be managed properly. It will not be natural for legacy staff to adopt a 24x7 mindset and newly minted SaaS engineers likely don’t have the industry or technology experience needed. Finding a balance of shifting culture, training, and new ‘blood’ into the organization is the best course of action.

Passion For Service Delivery

Having Services available 24x7 requires a real passion for service delivery as teams no longer have to wait for escalations from customers, now engineers control the product and operating environment. This means they can see availability and performance in real time. Staff should be proactive about identifying issues or abnormalities in the service. In order to do this the health and performance of what they built needs to be at the forefront of their everyday activities. This mindset is very different than the traditional onpremise software delivery model.

Security Implications

Shifting the operations from your customer environments to your own environments also has a security aspect. Operating the SaaS environment for customers shifts the liability from them to you. The security responsibilities expand to include protecting your customer data, hardening the environments, having a practiced plan of incident remediation, and rapid response to identified vulnerabilities in the environment or application.

Finance & Accounting

Finance and accounting are also impacted by this shift to SaaS - both on the spend/capitalization strategy as well as cost recovery models. The operational and security components are a large cost consideration which has been shifted from your customers to your organization and needs to be modeling into SaaS financials. Pricing and licensing shifts are also very common. Moving to a utility or consumption model is fairly mainstream but is generally new for the traditional product company and its customers. Traditional billing models with annual invoices might not fit with the new approach and systems + processes will need to be enhanced to handle. If you move to a utility-based model both the product and accounting teams need to partner on a solution to ensure you get paid appropriately by your customers.

Customer Service

Think through the impacts on your customer support team. Given the speed at which new releases and fixes become available the support team will need a new model to ensure they remain up to date as these delivery timeframes will be much more rapid than in the past and they must stay ahead of your customer base.

Your go to market strategies will most likely also need to be altered depending on the market and industry. To your benefit, as a SaaS company, you now have access to customer behavior and can utilize this data in order to approach opportunities within the customer base. Regarding migration, you’ll need a plan which ensures you are the best option amongst your competitors.

Most times at AKF we see companies who have only focused on product and technology changes when moving to SaaS but if the whole company doesn’t move in lockstep then progress will be limited.  You are only as strong as your weakest link.

We’ve helped companies of all sizes transition their technology – AND organization – from on-premises to the cloud through SaaS conversion. Give us a call – we can help!

 

Subscribe to the AKF Newsletter

Contact Us

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.

High level overview of state for application, connection and session state

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.


Desired State Outcomes - Application, Connection and Session

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 Cart - Approved State Example

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.

Debit Credit Approved State Example

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.

Workflow Manager Approved State Example

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

AKF Session and State Cube Model

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”.

X Axis

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. 

Y Axis

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).

Z 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.

Summary

The AKF State Cube serves two purposes:

  1. 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.
  2. 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

Contact Us

The AKF Difference

December 4, 2018  |  Posted By: Marty Abbott

akf difference

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

Contact Us

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 has 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:

Sales:

  • 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.

Finance:

  • Learn to speak ARR (annual recurring revenue).
  • Should look at alternative revenue schemes (seat vs. utility).
  • SaaS presents changes in revenue recognition. Be prepared.

Product:

  • 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.

Customer Support:

  • 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.

Security:

  • Better spin up this department in a hurry!

Professional Services:

  • 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.

Engineering:

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

Contact Us

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.

Need additional help?  Contact Us!

Subscribe to the AKF Newsletter

Contact Us

SaaS Risk and Value Shift

August 2, 2018  |  Posted By: Marty Abbott

Hand illustration of different risks
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.

Risk and Cost Shift Inherent to SaaS Transitions

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. 

Cost Models of Various Cloud Implementations

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.

Cloud Cost Models - Operating Expense and Cost of Goods Sold

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

Contact Us

The Phases of SaaS Grief

July 24, 2018  |  Posted By: Marty Abbott

frustrated guy at a computer Photo by Tim Gouw from Pexels
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.

Risk shift from on premise to SaaS products

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. 


Summary
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. 

Image Credit: Tim Gouw from Pexels

Subscribe to the AKF Newsletter

Contact Us

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.

Technology Adoption Life Cycle Adopter Characteristics

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

Factors Driving SaaS Adoption

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.

Factors Driving SaaS Adoption

Margins

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

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.

Factors Driving SaaS Adoption

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.

Factors Driving SaaS Adoption

Factor Outcomes

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.

Related Articles:

 

Subscribe to the AKF Newsletter

Contact Us

 1 2 > 

Categories:

Most Popular: