Category Archives: SaaS

Dogbert Translates Cloud-Consultanese

Check out today’s Dilbert strip. With the help of Dogbert and the Pointy Haired Boss, Scott Adams cuts right to the heart of the cloud craziness that has overtaken us.

Simply put:

Dogbert (the consultant) … Blah Blah Cloud. Blah Blah Cloud. …
Pointy-Haired Boss It’s as if you’re a technologist and a philosopher all in one!
Dogbert (the consultant) Blah Blah Platform.

That’s exactly what I hear when people start blabbing about “The Cloud”. That’s exactly what any smart technology person hears when people start blabbing about the cloud. And I say this with confidence because even Larry doesn’t know what the cloud is. (What the Hell is Cloud Computing?) He’s one of the smartest technology guys out there … and if he doesn’t know what it is, how can your average technology genius know what it is?

The reality, and please say this aloud three times, is that THERE IS NO CLOUD. (THERE IS NO CLOUD. THERE IS NO CLOUD.) It is a myth perpetuated by sales people and consultants who don’t have anything new to sell, but who know that if they speak the truth, they won’t sell anything … so they go around talking about this mythical magical cloud in a wonderful and confusing manner until they get some of the more dimwitted middle managers with a budget to bite. Then these dimwitted middle managers start perpetuating the myth because they know that if there isn’t enough hype for the technology they just overspent on, they won’t be able to justify their decision, and they’ll look bad. Then everyone else starts playing follow the leader because they don’t realize that it wasn’t Organization X that bought “the cloud”, but some dimwitted middle manager with a silver tongue and a charming smile. And then we have another technology craze around technology that doesn’t exist.

If someone is selling you “cloud technology”, then, if you’re lucky, what they are really selling you is a multi-tenanted hosted SaaS solution with open APIs that allow you to upload, manage, transfer, and download your data at your convenience and to manage how much processing is done when. (Something you should have been able to do since day one, but couldn’t with most multi-tenant SaaS providers that knew that only way to lock you in was to lock-in your data.) That’s it. Multi-tenant SaaS with open APIs that interoperate with an open standard so that you can, if you wish, suck your data out of one “cloud” instance and spit it into another “cloud” instance that uses the same API. If you’re really lucky, it might also have some good graphical management software that you can access through your browser (instead of undocumented command line RPC calls that take expensive coders weeks of time to figure out).

If you’re unlucky, it’s a traditional hosted ASP provider that has implemented the basics of an API that, through a lot of sweat and manpower in the offshore development centres, lets them fake a multi-tenant SaaS solution if you don’t look under the hood (as the best these providers can really pull off is single-tenant SaaS).

And since multi-tenant SaaS and open APIs have been around for years, it’s not new, it’s not magic, and it’s definitely not a new fluffy magic box.

Don’t get me wrong. I am a huge fan of multi-tenant SaaS (done right) and have promoted such technology for years. But I am sick and tired of this marketing BS. It’s a cloud all right — a cloud of smug produced by conceited marketing types. (If you don’t know what a smug cloud is, Trey Parker and Matt Stone produced a South Park episode that explains it quite well. If you are in the US, you can find video clips on the South Park Studios site. Warning: TV-14 to TV-MA, possibly NSFW)

Share This on Linked In

Finally An Article That Demonstrates That The Cloud Is Filled With Hail!

StorefrontBacktalk recently ran a great article on how “it’s not so soft in the cloud after all”. On December 5th, the web site of U.K. grocery giant Tesco ground to a halt after a surge of customers tried to take advantage of a new loyalty-card promotion. This was AFTER Tesco had announced that Akamai would be offloading 90% of the load to make sure nothing would go wrong.

And, of course, once the site went down, the call centre got overloaded too. And what happened when the failure was investigated? Akamai blamed the failure on a part of the Tesco site that was not being supported by Akamai’s cloud services, passing the buck.

And if all transactions eventually have to pass through, or be recorded in your systems, the bottleneck will still be there and all the cloud will do is accelerate your failure.

That’s why I’ve warned you again and again and again that the cloud is not a fluffy magic box.

Share This on Linked In

It’s Not Risk Management If You Just Trade One Risk for Another!

Especially if the second risk is just as risky, or, even worse, more risky than the first.

After reading a number of articles that claim IT Outsourcing reduces cost AND risk, including this recent piece over on Global Services on “Operational Risk, IT, and Outsourcing”, I am getting nervous about the mad dash to the cloud that these articles are directly or indirectly promoting.

While SaaS is often the best choice for many SMEs and large scale industries without a lot of technical know-how, it’s not always the best choice, and some systems are a lot safer to outsource than others. It’s one thing to outsource an ERP/MRP, especially if you don’t store your bank account access information in the ERP/MRP, but another thing to outsource user account management if such management contains credit card information and/or detailed financial profiles that are sufficient for an average criminal to commit identify fraud in his sleep. In the first case, just about any SaaS provider will do. In the latter, you need one who not only hosts in a secure data centre, but understands security and built security (and encryption) into the application (and database) from the ground up — especially if they are hosting in a shared data centre that uses a true multi-tenant architecture. Otherwise, a hacker could break in through a weakness in the application layer, dump the database, and get unencrypted credit card numbers, bank account numbers, SINs, etc. if the application wasn’t designed right from the bottom up. This could be financially devastating to you and your customers (who, for starters, would never buy from you again and who would probably take you to court).

The requirements for outsourcing and maintaining financial systems are much greater than for Supply Chain and Inventory Management. So what if they get your inventory database. Unless you’re storing nuclear material, who cares if they know for sure that you have 250 outdated PCs, 100 rolls of steel, and a warehouse full of binders. If they were doing a competitive intelligence project and really wanted to know that much about you, they’d check one of the import/export trade data monitoring services (or just watch what went in and out of your warehouse from across the street) and know it anyway.

Before you outsource financial systems, you have to be sure that the provider and the hosted application is at least as secure as the applications and environment you’d build in house, or the outsourcing effort will come at the expense of increased risk. And if risk increases, the decrease in cost may be inconsequential.

And if you don’t have the technical savvy to make a fully informed decision, bring in a consultant who has that knowledge. Trust me when I say it will be one of the best investments you ever make.

Share This on Linked In

Is MDM A Pipe Dream for the Average Organization?

With few exceptions, the most notable one being Oracle (which is the only IT organization I know of that eats its own premium dog food and never varies from the menu), MDM (Master Data Management) is a bigger myth in the modern enterprise than the Lost City of Atlantis (which never existed, by the way, and if you did your research you’d know it was a fictional metropolis introduced by Plato so that Socrates would have something to say). It’s been a problem ever since the first enterprise used one system for accounting and a second system for inventory, and it has only worsened over time. And now that we’re cloud-crazy, it’s only going to get even worse.

Instead of having data residing in dozens of databases accessed by dozens and dozens of applications in your server room, you’ll now have data residing in dozens of internal databases and in dozens of external databases on half a dozen different clouds, which is physically distributing and replicating these database instances over a few dozen instances for fault tolerance and reliability. Your data is now everywhere and nowhere at the same time. It’s more global than you are. And thanks to dynamic routing (and IP hacking and spoofing), it’s seamlessly crossing borders that you can’t. How can you ever hope to get a handle on it?

Well, according to this recent article in Information Week, you can start by following “three guidelines for implementing MDM”. These guidelines are a good way to wrap your mind around the problem, but they don’t really solve it.

Consider the guidelines:

  • Primary business drivers determine the methods of use.
    Well, duh! This should be the case for every system you use, not just MDM. If there is no business need, why do you have a system? Considering that all systems require hardware, software, and technical resources to maintain them, it’s just dumb to have systems you don’t need.
  • Data volatility determines the implementation styles.
    This is fairly obvious too. If you have a database that only updates once a week, and your MDM approach is to dump replicate all of your data in all of your disparate databases into one central database for MDM-driven BI, then you’re only going to have to update the central database once a week. If you have a database that updates every second, then you’ll need to grab updated data as often as you need it for analysis.
  • Scope determines the number of domains.
    This was the only really useful guideline. MDM doesn’t always mean centralizing all of the data into one central repository accessed through one domain. MDM is about gathering all of the related and relevant data into one schema, which may or may not be in one database, that permits the analyses the organization needs to run.

And now we get to the heart of the problem. Where and how should the data be stored, and how should it be accessed for the analytics that the MDM system is to support. (There’s no need for MDM if you’re not doing analytics!)

To this end, the article suggests you look at three types of MDM — Collaborative (CMDM), Operational (OMDM), and Analytical (AMDM) — and three styles — registry, coexistence, and transaction — but the first doesn’t solve the problem at all (as it just helps you figure out what you need to include under MDM, not how you represent it) and the second only deals with what data is managed and how often it is refreshed.

The fundamental problem is that of architecture — what is the schema, where is the data stored, and how is it federated? And what do you do if some of the data is not accessible when you need it? If you have terabytes of data distributed between internal databases and external clouds, then to centralize it you will need terabytes of storage and some big internet pipes to handle the petabytes of data that will need to be sent back and forth over the course of a year to keep the central data store up to date. So centralization is not the answer in this scenario. You need to keep the data in its home location and simply access what you need when you need it. But if an application is down, or inaccessible because of a temporary internet-related failure, the data won’t be accessible. So what do you do? Do you run the analysis without that data? Do you use the most recently cached data? Do you estimate the missing data based on time-series projections? Do you run a partial analysis, return a partial report, queue the remainder of the request and then run the remaining analysis when the data source becomes available again? Until you can answer these questions, architect a distributed, fault-tolerant, robust MDM solution, and implement it — which is where even the best organizations tend to fail and give up before the effort is complete — you don’t have MDM.

So is MDM a pipe dream for the average organization? Or will next generation technology deliver us a solution. It’s an important question, because you’ll never have true BI (Business Intelligence) if your data is out of control.

Share This on Linked In

For Real Value, You Must Own the TCO

CRM Buyer just published one of the best articles I’ve ever stumbled across. In TCO, ROI, and the Difference Between Price and Cost, the author makes a point that is overlooked far too often by far too many buyers when they are shopping for new supply chain solutions:

      Customers must be sure that THEY own the definition and calculation of TCO and don’t allow the vendor to drive the agenda.
      

As the author clearly states, vendors will try to manipulate and obfuscate the true TCO of their solution and it will be different for each installation. Plus some of the costs, like risk and opportunity, are nebulous and hard to define. Vendors will try to make other vendors’ solutions look risky when, in fact, for you they might be less risky.

That’s why, on multiple occasions, I’ve tried to lay out the true, long term, costs of supply management solutions, as I did in this post in Uncovering the True Cost of On-Premise Sourcing & Procurement Software, in this post The Total Cost of Ownership Equation in a Green Economy, and this post on Know Your Software TCO & TVM, for example. The true, long term, cost is always more than you think and much more than the vendor will let on. It’s like the car example given in the article. If you’re going to sell after five years, the total cost is the price plus five years of maintenance and repairs (and insurance and gas) minus the expected selling price, and when everything is factored in, a more expensive car that costs more but retains its value might be worth more than a cheap car that loses the majority of its value and costs four times as much to maintain.

Before you make a decision, you have to determine the total cost of each solution over the intended lifetime. Only then you can decide if the solution with the greater (annualized) cost truly brings more value. If a solution costs 20% more but increases productivity by 40% or decreases risks by 30%, it might be worth it. However, if a solution costs 100% more but brings no additional value of any kind, it’s not worth a second look. And this is not something you will know until you slice through the vendor obfuscation and normalize the costs, which is something you can only truly do if you own the calculation.