Or – The Best Thing about the Rise of Cloud Computing (and it’s not what you think)

Overview

For years the big software “gorillas” – the big ERP and enterprise application vendors – have owned the software landscape. Software companies that took some of the landscape away were purchased by the gorillas, making them monolithic.

Software Gorilla

Buying these big apps costs manufacturers millions of dollars. Implementing them requires hiring a Big5 Consulting firm and the 9-12 month implementations cost more millions. In a year or two when the manufacturer wants to upgrade to the next release of the software, they need to call in the consulting firm and pay millions more.
 

Most IT organizations accept these costs as the necessary by-product of implementing and using application enterprise software.

The Agile Monkey – Azerity

At Azerity we proved that software can easily be built that is easy and quick to install, manages the configuration upgrades and data migration even for major releases. We did that by building our software with the entire life cycle in mind including installation and upgrades.

Why don’t other companies jump on the bandwagon? IT organizations haven’t demanded it and the software industry has, until now, no motivation to give up the millions charged for implementations and upgrades. This is wasted IT dollars that could be spent on real value items – research, manufacturing improvements, etc.

Enter the cloud. The cloud changes the paradigm. Releases must be quick and seamless. Customer configurations and data must migrate seamlessly. Can the gorillas adapt? Will the IT organizations begin demanding the same level of service regardless of cloud-based or on-premis?

Background

The big software “gorillas” have owned the software landscape for a decade.

The “gorillas” are the big enterprise application companies that have been buying all the littler companies to become big monolithic companies. To buy their products costs millions initially, the big consultants charged millions more for implementation and each upgrade is millions more or each release.

When a manufacturer buys one of these enterprise applications, typically they also hire a consulting firm – like Accenture, Deloitte, KPMG, etc. – to work with them during the implementation. They define their current business processes, their “to-be” business process with the new automation. They identify the “gaps” in the enterprise application that the consulting firm will need to fill with custom code. They design the way their screens should look, the user permissions on fields which are then coded in Java or XML to convert the bare out-of-the-box application to a usable system. This can take 9 months or more of a dedicated team from the manufacturer’s organizations, people who should be doing other jobs but now are on a “special projects team” to get the enterprise software installed. This implementation typically costs millions of dollars paid to the Services organization and more lost in the business worker’s time.

Now 2 years later the gorilla releases it’s next major release. The release includes database changes, screen and navigation changes, new features and functions. The manufacturer wants to take advantage of these new features. But they find out that to upgrade, their millions of dollars of custom code will need to be converted and upgraded. All of their database tables will need to be migrated to incorporate the new data fields and perhaps completely revised. Their XML screen changes will need to be touched, at a minimum, or re-done. The consultants must be called back in to design the changes. If new features are to be leveraged then new screens need to be designed. The cost of the upgrade is, again, many millions of dollars.

For years I’ve asked “Why?”

True Story of an ERP Software Upgrade

I worked for a few years as IT Technology Manager at Varian where we used one of the gorilla software vendor’s ERP software. We were preparing for an upgrade. The business side had done their months of review and code changes (and Varian installed a fairly “vanilla” version of the ERP software – as vanilla as possible). So we were ready for the production upgrade.

Rolling out the upgrade first meant upgrading every PC in the company to a newer operating system. That alone was a significant effort and in many cases involved hardware upgrades or new hardware altogether.

Then came the production software and database migration. My team ran the migration scripts over and over on the test systems, timing each step. Then converted the step times to what they could expect on the larger, more powerful (hence quicker) production system. They laid out the plan and rented a room in a hotel within a block of the facility. The notices went up on the screen that the system would be down over the weekend and at 6 PM Friday evening down they came. In a manufacturing company, taking MRP down over the weekend is a big deal. And it can’t go longer than the weekend without real dollar impacts to the manufacturing floor.

The hotel room was so that the system admin and DBA could take turns who would perform the next step. The alarm would go off at 1 AM and Michael jumped up, ran over to the computer center and pushed the button or performed the series of inputs needed to continue the migration process. He returned and at 3:15 AM the alarm woke Ken to do the next step. So on through Friday night, Saturday, Saturday night, Sunday and Sunday night. At 6:30 AM Monday morning both came in for the final production restore but to their dismay they saw a new error message – in German. Fortunately the International Manager was an early riser and showed up at 7 AM. German was his first language and he was able to translate. The system was up a 9 AM – 2 hours late but early enough to not severely impact manufacturing.

I thought “This is crazy! There has to be a better way.”

Azerity – A Different Kind of Enterprise App

A few years later I was responsible for the product design for an enterprise application system. We had some “rules” for our product:

1. Installation had to be quick and easy. Upgrades had to occur in less than 12 hours. That meant data scripts would be optimized, anything that could be done ahead-of-time would be carved out, etc.
2. Install size had to be minimized. This means if the developers us a library, only used components from that library would be shipped. (I’ve seen where this can make a difference between installing 1,000 files versus 24,000 files for the same production codeline which translates to software restarts taking a minute or 30 minutes. If each re-start takes 30 minutes, any issue takes users off-line for that amount of time).
3. New enhancements had to avoid (if humanly possible) making the customer change any of their interfaces or their business processes.
4. Data migration had to be part of the install for new releases. Not a separate step someone had to come in and do at midnight. As part of developing a new feature or function, developers would check in their migration scripts. Then when each developer checked out the software daily the scripts would run on their local systems; thus testing the migration script. Data migration then was seamless.
5. A GUI configurator was needed that would manage the XML screens and manage upgrades so changes needed by the manufacturer would be minimal.

The result was that although our product was as robust, large, mission critical as the gorilla software, ours was easy to install and to upgrade.

The downside was that we charged less for our product and our Services revenue was minimal. The big consultants had no interest in teaming with us because installs and upgrades brought them little revenue.

I said “Yea!” It means that our customers only pay for added value. The software gorilla’s customers are paying millions and millions every year for no added value.

It Drives Me Crazy!

It absolutely positively drives me crazy to see the software industry bilking customers millions and millions for unnecessary services. Think of what the US could do if manufacturers weren’t spending these millions fruitlessly. Think of the inventions, additional technical hires and real advancements this money could be used for instead of no added value services. And we wonder why the US is becoming a Sales and Service country and technology is going overseas!

Along comes the Cloud

Think about cloud computing. When companies offer apps in the cloud, they have thousands of users, each company in it’s own tenant instance with it’s own configurations and customizations modeling the way each does business. When a new release is distributed to the production servers, upgrades must be quick and seamless. They can’t have each company taking 9 months to test and migrate their data and configurations. Companies usually can’t access the database directly nor files on the cloud servers.

1. Installation has to be quick and easy.
2. Install size has to be minimized. (You don’t want hundreds of copies of 24,000 unused files)
3. New enhancements have to avoid making the customer change any of their interfaces or their business processes else when the software releases to production, issues will ensue.
4. Data migration had to be part of the install for new releases. The companies using the cloud software don’t have access or control of the database.
5. A GUI configurator is needed that would manage the XML screens and upgrades because the customers don’t have access to the files.

In other words, if a company wants to compete in the cloud, they need to learn how to build enterprise software without the unnecessary services component.

To me, the cloud will “elevate” the software industry and make it more customer and IT friendly. Enterprise App Vendors who are forced by their customers to move to the Cloud will now “have to” do the right thing. I think it’s great!