Tuesday, February 12, 2019
There is near-universal agreement that cloud computing is the future for enterprise IT. Our research at Computer Economics certainly indicates so. In just one year, our annual IT spending survey showed the percentage of IT organizations with 25% or fewer of their application systems in the cloud declined from 72% in 2017 to 61% in 2018. We expect a further decline this year.
Four Factors Favoring On-PremisesEven though the trend is strongly in the direction of cloud, are there situations where on-premises deployment is still justified? In a recent article, Joe McKendrick outlines four situations where staying on-premises may be preferable to cloud, at least for now. He writes:
To explore the issues of when staying on-premises versus cloud makes sense, I asked industry executives about any areas that were not suitable for cloud, and better left on-premises -- especially from the all-important data perspective. The security implications, as well as geographical presence requirements, are obvious. But there are also other facts that may make staying on-premises the most viable option.Joe goes on to outline four factors:
- Legacy entanglements: where the system is just one part of an integrated set of applications, especially where there are dependencies on certain database or platform versions. “Monolithic legacy applications” with custom system administration tools are another example.
- Cloud sticker shock: where data storage requirements are so great that cloud deployment is simply not economical.
- Security: where “some data cannot risk even a hint of exposure.”
- Need for speed: where large data sets are maintained for “real-time user data interaction, high-speed analytics, personalization, or recommendation.” Some IoT applications may fall in this category.
The Four Factors Not as Great as They Once WereWhile these four factors are worth considering in a cloud vs. on-premises decision, I find them to be less of a factor than they were even a few years ago.
There is one more factor in favor of on-premises systems: Where there are regulatory requirements that the organization demonstrate control over the production environment. This includes FDA-regulated companies where a system is used to support regulated processes, such as quality control in medical device or pharmaceutical manufacturing. Although it may be possible to meet the requirement in a multi-tenant cloud environment, many regulatory affairs professionals are more comfortable not fighting that battle. In such cases, it may justify an on-premises deployment or at least a single-tenant hosted deployment where control of the production environment can be more readily assured.
- The legacy system factor is certainly reasonable in some situations. To this I would add, staying on-premises may be justified when requirements for a new system can more easily be accommodated with an add-on to the legacy system. Be careful with this, however, as this can be a prescription for further entrenchment of the legacy system.
- In my view, cloud sticker shock is only a factor for a small percentage of cases, perhaps for very large data sets. Declining costs of cloud storage should lead to fewer instances where this is a legitimate objection. Often, IT leaders making a case for on-premises systems based on cost are not factoring in all costs, such as the cost of personnel to maintain and back up that on-premises storage.
- The security factor I find to be largely an excuse. Although business leaders often underestimate the impact of a potential security breach, they also tend to overestimate the capabilities of their own security staff members, processes, and technology. The level of security maintained by internal IT organizations is usually far less than what is achieved by cloud services providers. If one of the big three credit data providers (Experian) could not protect consumer data maintained on-premises, what makes you think that your security capabilities are greater?
- The need for speed, in some cases, may be a legitimate reason for keeping some systems on-premises. However, most enterprise applications do not have this requirement. Even manufacturing execution systems—systems with low latency requirements—have been successfully deployed by cloud applications providers, such as Plex. In other cases, local buffering of data may be possible to accommodate any latency between the local system and the cloud provider. In such cases, it may be better to make investments in high-speed data communications, with redundancy, rather than continue to maintain such systems in local data centers.
Cloud First the Best StrategyAs discussed, there are situations where a true on-premises systems may be legitimately justified, although the case is getting weaker year by year. Nevertheless, for most new systems, business leaders should be adopting a “cloud-first” strategy, even if "cloud only" is not practical for now. If there is a cloud solution that will meet business requirements, that should be the preferred path forward. The advantages of cloud systems, especially in terms of alleviating the burden of system upgrades, are too great to ignore. On the other hand, if no true cloud system meets business requirements, or there are other limiting considerations, an on-premises solution may be a legitimate option. But even then, we would prefer to see a hosted solution, in order to achieve some of the benefits of getting application systems out of on-premises data centers.
Wednesday, January 16, 2019
Although open source software now completely dominates some categories of software, this has not been true for enterprise applications, such as ERP or CRM. What is it about enterprise applications that makes them so resistant to open source as a business model?
My friend and fellow-analyst Holger Mueller has a good post on Why Open Source Has Won, and Will Keep Winning. Read the whole thing. In Holger's view, which I agree with, the battle between open source and propriety software is over, and open source won. In just a short fifteen years or so, it is hard to find any commercial software vendor attempting to build new platforms based on proprietary code. He writes:
Somewhere in the early 2000s, Oracle dropped its multi-year, 1000+ FTE effort of an application server… to use Apache going forward… that was my eye opener as a product developer. My eye opener as an analyst was in 2013, when IBM’s Danny Sabbah shared that IBM was basing its next generation PaaS, BlueMix, on CloudFoundry… so, when enterprise software giants cannot afford to out-innovate open source platforms, it was clear that open source war-winning. As of today, there is no 1000+ people engineering effort for platform software that has started (and made public) built inhouse and proprietary by any vendor. The largest inhouse projects that are happening now in enterprises, the NFV projects at the Telco’s, are all based on open source.Holger's observation is certainly true for software at the platform or infrastructure level of the technology stack. All the examples that Holger cites, and nearly any other that he could cite, are in these categories.
But what about enterprise business applications, such as ERP or CRM. One of the best examples is SugarCRM, but even there, it lags far behind the market leaders. Open source ERP is in even worse shape. Players such as Compiere (now owned by Consona), Adempiere (a fork of Compiere), Opentaps (an ERP and CRM system), xTuple (formerly, OpenMFG), and Odoo (formerly, OpenERP) barely move the needle in terms of market share. Where is the Linux of ERP?
Since the early 2000s, I have been hoping that open source would catch on as an alternative to the major enterprise apps vendors, such as SAP, Oracle, Microsoft, Infor, and others. I would like to see open source as a counterweight to the major vendors, putting more market power on the side of buyers.
So, why hasn't open source been more of a contender in enterprise applications? I can think of three factors, for a start.
Ironically, open source is very popular among enterprise application providers themselves. Software vendors, whether cloud or on-premises providers, love open source and many now build nearly all of their systems on it, because it scales economically. Yet, when they sell their own enterprise applications, the last thing they want to do is offer them as open source.
- Open source needs a large set of potential users. But enterprise applications do not have as broad a potential user base as infrastructure software. Although the ERP market is huge, when you break it down by specific industries, it is small compared to the market for, say, Linux.
- Enterprise apps require a large effort in marketing and sales. Buyers put great weight on name recognition. But open source projects do not generally show much interest in the sales and marketing side of a business. If a project is truly community-developed, who is interested in marketing it? As a result, very few people know what Odoo is, for example, let alone, how to acquire it.
- Open source is labor-intensive. It is great for organizations that have time but no money. My impression is that open source ERP adoption is somewhat more successful in some developing countries, where there are very smart people with good technical skills willing to spend the time to implement a low-cost or no-cost solution. Here in the U.S., such companies are rare. Most would rather write a check.
So, why hasn't open source been more successful for enterprise applications? Perhaps readers can come up with other reasons. Please leave a comment on this post, or tweet me (@fscavo), or email me (my email is in the right hand column).
Update, Jan. 18: My friend Josh Greenbaum has posted a lengthy response on his blog, here: Open Source, Enterprise Software, and Free Lumber. Please read the whole thing, as it is quite thoughtful.
Josh agrees that open source software (OSS) has been more successful for infrastructure components than for enterprise applications. But he goes off in a different direction to argue that it's not right for commercial software vendors to make money from their use of OSS. I have two basic disagreements with Josh on this point. First, most OSS licenses (GNU, for example) mandate that creation of software incorporating the OSS must be provided under the same OSS license. So commercial software providers go to great lengths to ensure that their developers do NOT incorporate OSS into their software products. Now, OSS providers CAN incorporate OSS in their own operations (e.g. use of Linux or MariaDB in their provision of cloud services), and they can include OSS as a supported platform.. In both cases they are not violating the terms of the OSS license.
My second disagreement is that Josh objects to OSS on what I consider to be more or less moral grounds, that it is wrong for others to make money from the free contributions of others (a "sucker's game," he calls it). Putting aside the fact that commercial software providers (think, IBM, Microsoft, Facebook, Google, and hundreds of others) are the largest contributors by far to OSS, no one is holding a gun to the head of any individual developer forcing him or her to work for free. If OSS contributors find it acceptable for others to make free use of their labors, who am I to say that it is wrong for others to do so? The fact that OSS has been wildly successful (at least for infrastructure-like components) tells us that there must be something in the economic model of open source that works to benefit both contributors and users of OSS.
Update, Jan 18: Some email correspondence from my friend Vinnie Mirchandani, led me to send this email reply, lightly edited here:
Yes, the large tech vendors, such as Google, Microsoft, IBM, etc., have benefited enormously from open source, but they also contribute enormously to open source projects, because it is in their best interest to do so. You know that IBM contributed key IP from its decades-old work in virtualization. Microsoft open sourced Visual Studios Code, and it is now one of the most widely-adopted development environment. Oracle, IBM, and others contribute to Linux because it ensures that it runs on and is optimized for their hardware. They all contribute because it is in their self interest to do so. Moreover, senior open source developers, especially those who have commit-privileges, are in high demand and are often hired by these same large tech companies. So the whole open source movement has become a virtuous ecosystem where everyone benefits.
Update, Jan 19: Over at Diginomica, Dennis Howlett riffs on our discussion in, Why you should take notice of the open source in enterprise suckers conundrum. On my question of why open source has not been more successful in enterprise applications, he points to the lack of real marketing and sales efforts. He writes:
I’d go one step further and as a nuanced view of Frank’s (2) element. In most cases, enterprise software is sold, it’s not bought. What I mean is that troupes of vendor reps, marketers and other hangers on line up to convince you about taking on one or other solution. In the open source world you are ‘buying’ not being sold. There is no real money for marketing and sales. You either take it (for free) and then work on it yourself, or you enlist the help of specialists who both understand your processes and the software code itself. And despite the early success of Salesforce as a cloud vendor from whom you bought applications at the departmental level on your credit card, the majority of enterprise deals are sold.
Thursday, January 10, 2019
If I can sign up for your cloud service without human interaction, why do you make me contact your billing department to cancel or downgrade my subscription?
This question came to mind after an experience I had this week dealing with a well-known SaaS provider this week. The provider, who will remain unnamed, is well-known in the market for "collaboration."
Although this provider serves many large companies, it is also a good choice for small work groups, which is how my consulting firm is using this service. There is a free trial version, which will convert to a paid subscription for a nominal per-user fee. As such, without interacting with a human being, you can sign up for a handful of users for an entry level service.
The experience this week started when our annual billing notice came in and I realized that we were paying for a level of service that was much greater than what we need. So, I looked at the provider's website to see how to downgrade our level of service.
The instructions I found read, in effect, "Contact our billing department."
Now, to the provider's credit, the billing department handled my request in a fairly efficient matter, although of course they wanted to know why I wanted to downgrade, had they done anything wrong, did I realize all the benefits I was receiving, etc., etc. I believe I needed to respond to two, perhaps three, emails in order to accomplish the downgrade.
So the question remains: Why require this extra step? If I can sign up via self-service, why can't I downgrade or cancel via self-service?
Labels: customer service
Monday, January 07, 2019
IT Salary Report for 2019, and there are some findings that are a bit counter-intuitive.
For example, in a time of low unemployment and a strong economy, you would think IT salaries would be strongly rising across the board. But that is not the case. Although across all IT jobs, salaries are rising at the median, for some job positions, the national average salaries are actually falling.
As we write in a Research Byte for the new report.
Another factor we are seeing is that the salaries of new hires are decreasing. This usually does not happen in a strong economy. However, many IT workers are migrating from high-cost-of-living cities to places such as Nevada, Idaho, Oregon, Colorado, North Carolina, and Florida, where they usually earn a lower salary but enjoy a much-lower cost of living. Many employers have also been moving their operations to these same low-cost areas. In terms of real dollars, salaries might not be increasing as quickly, but workers are still seeing benefits.In economic analysis, one of the mistakes people make is to fail to recognize the rational decisions that individuals and organizations make in response to incentives (or disincentives). There is no doubt that the cost of living--and the cost of doing business--in some parts of the U.S. have gotten ridiculous. Think of the San Francisco Bay Area, for example.
“National medians are useful for determining the general direction of the economy or hiring, however this year, more than ever, it is best to look at salaries at a regional level,” said Tom Dunlap, director of research for Computer Economics, based in Irvine, Calif. “As major cities vie to attract employers looking to take advantage of lower costs and new supplies of talent, salaries will be in flux.”
As housing prices, and office space lease rates go through the roof, what are the logical choices? For both individuals and companies, it is to relocate to cheaper metropolitan areas--whether it be across the Bay, or out of state to Nevada or Texas.
The option of remote work has made this choice much easier. Over the past decade, an increasing percentage of the IT workforce has been working remotely, whether telecommuting a few days a week, or moving out-of-state altogether.
It used to be that relocation meant turnover. Today, not as much so. For strong performers, employers are often willing to let them relocate and work remotely. The business keeps a strong performer, and the employee sees his or her salary go farther. Or, organizations may relocate to a more cost-effective location and allow many of their employees stay put.
Ultimately, salaries find their natural level, and that's what we think is going on right now for some IT positions.
The salary trends introduction to our IT salary report is available at no charge on our website. It also comes with a sample of our salary tables.
Friday, May 04, 2018
Uptake of Oracle’s cloud applications is great, but when it comes to Oracle really competing with Amazon or Microsoft as a platform for independent software vendors (ISVs), the story is different.
The absence of multitenant ISVs on OCI is not because of a lack of capabilities. Oracle’s flagship database, since v12c was released in 2013, has built-in multitenancy in the form of database containers, which allow multiple tenants to share a single Oracle database, with individual containers assigned to each tenant. This approach puts the multitenancy into the infrastructure layer, allowing developers to focus their efforts on application development, not on the mechanics of multitenancy.
Oracle’s lack of commercial SaaS providers building on OCI is about to change.
Read the rest of this post on the Strativa blog:
NetSuite on Oracle Cloud Infrastructure: What It Means for Customers
Friday, April 20, 2018
When we hear the term artificial intelligence (AI), most of us immediately think of the AI we encounter in our personal lives: web ads based on our search history, facial recognition on Facebook, or the interactive voice response systems of our banks or insurance companies. Or, maybe we think of personal digital assistants, such as Siri (Apple), Alexa (Amazon), or Cortana (Microsoft). In other words, we all use AI on a personal level, whether we call it AI or just expect it to be part of our everyday experience as consumers.
Just as social networking and smartphones took hold first in the consumer world and then moved into business, we can also expect artificial intelligence to begin to move into business applications in a natural way.
Today, nearly every large enterprise software vendor, and many of the smaller ones, are working to embed AI capabilities into the core of their business software. Here are examples from just three of them.
Read the rest of this post by Dee Long on the Strativa blog: AI Coming Soon to a Business System Near You
Wednesday, January 03, 2018
For example, with ERP implementations we see companies investing the time and energy to select the right system but spend no time at all to ensure that the people who have to use the system buy in to the decision.
Then they wonder why, when it is time to start the implementation, employees resist moving to the new system.
Why do business leaders too often neglect the people-side of change? It is usually because they think of change management as something intangible, something that they cannot control, measure, or track. They know how to develop a project plan for technical implementation of a new initiative (for example, an ERP system), but they don’t know how to develop a plan with tangible and practical steps to help people embrace the new system. They know how to manage projects, but not how to manage change.
Less Talk, More Action, NeededIt is not for lack of talk about change management. The same business leaders have shelves full of books about change management, cultural change, and leadership. But too much of what has been written about change management is theoretical. After reading the book, the leader still doesn’t know what to do in terms of practical steps to take care of the people-side of change.
A real change management program is not something soft or nebulous. After years of research and real-world experiences, change management professionals have developed many methods and tools that can make change management as tangible and practical as project management.
Read the rest of this post on the Strativa blog:
Change Management Doesn’t Have to Be a Game of Chance
Labels: change management
Wednesday, October 18, 2017
What is the difference between an RFI and an RFP? In our software selection consulting services, we develop an RFI near the beginning of the vendor evaluation process. The RFI includes a description of the client’s organization and the client’s project. It also includes a list of key requirements for the new system—not an exhaustive list, but essential functionality or processes that are distinctive for the client. Vendors are asked to respond as to their ability to satisfy those key requirements. Vendors are not asked for a cost proposal at this time. We typically make the RFI available to as many vendors as we think are qualified to respond, or to those that express an interest in responding—usually five or more.
An RFP, in contrast, is published near the end of the evaluation process, after each finalist vendor (typically 2-3) has conducted its demonstrations or other proof-of-concept. The vendors are asked to provide a cost proposal, along with their proposed license/subscription agreements and a high-level implementation proposal with costs and schedules. The vendors’ RFI responses are incorporated as an attachment, which they can revise based on what they’ve learned since they first responded to the RFI.
Read the rest of this post on the Strativa blog: In Vendor Evaluation, Don’t Shortcut the RFI Process
Friday, June 16, 2017
Developing an IT strategy for some organizations can be difficult because of the presence of a legacy system. Legacy systems that are old, out-of-date, and difficult to maintain are a huge obstacle to innovation. As a result, business leaders become increasingly frustrated by their inability to roll out new mobile apps, connect with customers, analyze business performance, or become a digital business.
In recent years, it has become popular to describe organizations with an out-of-date legacy system as being in “technical debt.” I would take this a step further. If an organization ignores the need to update the system for too long, it can lead to what I refer to as “technical bankruptcy.”
We can define technical bankruptcy as a situation where the organization cannot, or finds it exceedingly difficult to, pay off the technical debt. It does not mean that the organization is in financial bankruptcy but rather that its systems are broken or held together in a way that makes them extremely difficult to upgrade.
Significant Percentage of Organizations Are at Risk of Technical BankruptcyIn work with our clients at Strativa over the past several years, we have gained new insights into challenges facing organizations that have out-of-date legacy systems. We recently took the opportunity to combine those insights with survey data from our sister IT research firm, Computer Economics, to produce a new report, Avoiding Technical Bankruptcy in Legacy Systems. (Click the link to download the report free from the Strativa website.)
Figure 3 from the full report shows the magnitude of the problem as it applies to ERP systems. A small but significant percentage (7%) of organization have not upgraded their ERP systems for 10 or more years. These are likely to already be in technical bankruptcy. But the 13% of organizations that have not upgraded their systems in the five-to-nine-year time frame are in the danger zone: Technical debt is building, and if the organization does not undertake a major upgrade, it risks falling into technical bankruptcy.
Signs of Technical BankruptcyWhat are typical signs that a legacy system has reached the stage of technical bankruptcy? We found five characteristics:
In the full report, we explore the symptoms of technical bankruptcy and the devastating effects that it has on the organization. We continue by quantifying the scope of the problem specifically for ERP systems, using our research on the typical age, frequency of upgrades, and extent of modification of these systems.
- Extensive modifications, extensions, and interfaces.
- Poor understanding of the system by users and IT alike
- Direct involvement of IT personnel in business processes.
- Legacy system atrophy as shadow IT emerges.
- Upgrade or replacement hard to justify.
Most importantly, we conclude with recommendations on how to avoid technical bankruptcy and, for organizations that have reached this stage, strategies for getting out and staying out of technical bankruptcy going forward.
Download the full report, free from the Strativa website:
IT Strategies for Legacy Systems: Avoiding Technical Bankruptcy.
Bonus: Watch a Datamation's James McGuire in a video interview with me about the report.
Thursday, June 08, 2017
Why Is Manufacturing Cloud ERP Lagging Behind?Nevertheless, there is no cloud ERP provider the size of Salesforce or Workday, and there is certainly no cloud ERP provider for the manufacturing industry with that scale. NetSuite was founded in 1998, around the same time as Salesforce. But it only reached the $741 million revenue mark in 2015, before being acquired by Oracle. Claiming more than 30,000 companies, organizations, and subsidiaries in more than 100 countries as customers, it is by far the largest cloud ERP provider. Although it has done very well with professional services firms, software companies, and other services-related businesses, manufacturing companies form only a small part of that number. Plex Systems has a pure cloud ERP system for manufacturers dating from 2000 and has been rapidly growing over the past four or five years. But its customer count is under 600. After NetSuite and Plex, the number falls significantly: Cloud-only systems such as SAP’s Business ByDesign, Rootstock, and Kenandy, each have even fewer manufacturing customers.
To understand how great the market opportunity is for cloud ERP in manufacturing, consider that, according to the U.S. Census, there were about 63,000 manufacturing firms in the United States in 2014 with 20 or more employees, as shown in Figure 1. Considering that the estimated customer counts by vendor in the preceding paragraph include customers outside of the U.S., it is safe to say that manufacturing cloud ERP probably has less than 2% market share in the U.S. The market opportunity going forward, therefore, is enormous.
Read the rest of this post on the Strativa blog: Manufacturing Is a Huge Opportunity for Cloud ERP
Thursday, May 04, 2017
software selection consulting, clients often seek our advice on implementation partners. In fact, our experience over several decades tells us that the choice of an implementation team is as important, sometimes more important, than the choice of a new system.
In choosing an implementation consulting group, clients often start out thinking that it’s best to choose the vendor’s own professional services group. They think that no one can know the software as well as the vendor’s own personnel. They think that when problems arise, the vendor’s consultants will be in a better position to deal with the software vendor. They also think that there will be less finger-pointing: the consultants blaming the vendor, or the vendor blaming the consultants.
These considerations have merit. But there are other factors to consider, factors that may make an implementation partner, or even an independent consulting firm, a better choice.
Read the rest of this post on the Strativa blog:
Software Vendor Implementation Services Not Always Best Choice.
Thursday, February 09, 2017
One of the most interesting of these is Seattle-area-based Acumatica, founded in 2008—just yesterday in “ERP years.” Like many other ERP startups, it initially focused on services businesses but soon added distribution and CRM functionality to its horizontal capabilities. Its go-to-market strategy is 100% through value-added resellers (VARs), who can add their own industry-specific software on top of Acumatica. Its VAR strategy, in this respect, is similar to that of Microsoft Dynamics and Sage. In fact, many of the new VARs in Acumatica’s channel program have come from the Microsoft and Sage ecosystems.
Acumatica’s partner and customer conference in January gave us an opportunity to update our view of this emerging cloud ERP provider. We find that Acumatica is interesting because of three characteristics that are somewhat novel in the ERP world.
Continue reading on the Strativa blog: Three Things to Like about Acumatica
Monday, January 23, 2017
But small business doesn’t always mean simple business. Like larger companies, small and midsize businesses (SMBs) need to reach new markets, develop new products, satisfy customers, and control costs. The main difference is that SMBs need to do these things with fewer resources.
In recent years, however, software vendors have announced new products to address the challenges facing small businesses. This post outlines two of them.
Read the rest of this post by Strativa consultant Dee Long: New Customer-Facing Systems Extend the Reach of Small, Midsize Businesses
Tuesday, October 18, 2016
Human Capital Management (HCM) is turning out to be fertile ground for providers to develop use cases for data science. The recent HR Technology Conference in Chicago provided an excellent opportunity for us to learn about the offerings of six such providers.
At the same time, there are other interesting problems for data science to solve in HCM beyond the initial use cases.
Read the rest of this post on the Strativa blog: HCM Fertile Ground for Data Science.
Sunday, October 02, 2016
The personalized coupons we receive at checkout are generated by the grocer’s analysis of our purchase history. Likewise, the targeted ads we see on the web are based on ad brokers’ use of big data generated by our browsing history. Large health insurers use big data to target us with advice on managing our health and lowering costs of medication. And major political campaigns are getting good at using big data to target us based on our demographics.
Based on our experience as consumers, it is evident that the “big guys” know how to use big data. But what about small to midsize companies?
The good news is that business analytics and even big data are becoming more readily available to smaller businesses. This is the result of three big enablers.
Read the rest of this post by Strativa consultant Dee Long, on the Strativa blog.