Labeling an application as Mission Critical can actually be a contentious activity.
Ask any Line of Business for a listing of which apps are mission critical and it is highly likely that the answer will be “all of them”.
The diagram below highlights the danger of overprovisioning as a result of this activity:
My colleagues at EMC describe the scenario above as follows:
As expected typical decisions regarding application criticality are rarely holistic as each application owner is incented to put their suite of applications first. This presents real risk when trying to set investment strategy for the organizations goals, which often transcend a particular business division or application. The resulting data from a typical criticality assessment is siloed and myopic therefore it is unusable as a guide to focus on aligned application investment.
How then should a business holistically define mission criticality in terms of correct placement of truly mission critical apps onto the most appropriate tier of infrastructure?
In the long term, the answer will be found in what I have termed “Mathematical Management & Orchestration” in a previous blog post. The cloud orchestration layer (e.g. VMware) will continue to advance in its ability to mathematically model workloads and dynamically place (and migrate) the application onto the best combination of server, network, and storage.
In the short term, however, Mathematical M&O cannot solve mission-critical application classification in the here and now.
Adaptivity, however, can do that classification today. Adaptivity uses data-driven algorithms to mathematically (and accurately) perform application classification and identify the applications that truly are critical to the business. The classification is the first step in moving towards a truly accurate mapping of mission-critical applications onto the most mission-critical infrastructure:
As I’ve been discovering the business value of this approach (mapping the correct amount of infrastructure to the specific need of each application), I can’t help but wonder “how does it work”?
The answer, according to Sheppard Narkier (co-founder/Chief Scientist of Adaptivity and a pioneer in this field) is grounded in The Importance of Pattern-Based Thinking. Sheppard has published a related blog about why applications degrade.
I’ll spend some time in future posts discussing the centrality of Adaptivity’s approach in the ongoing relationship between apps and data, business and infrastructure. Thanks to Elliott Young for the graphical illustrations shown above.
Steve
Twitter: @SteveTodd
EMC Fellow
Is “Adaptivity” the ADM software EMC got from the nLayers acquisition? The biggest problem of the software (when I looked at it circa 2006-2007) was that they could not do packet inspection of traffic that goes over encrypted tunnels. Is that still the case?
Bala – Adaptivity is an acquisition from 2013 and is different from nLayers.
As an attorney, I am frequently asked this question: “Is blah, blah, blah illegal?” To which I have a standard response: “The question of whether a given activity is illegal is uninteresting. A more interesting question is: What bad thing happens to you when you do blah, blah, blah?”
The question of whether a given application is mission critical is similarly uninteresting. A more interesting question is: “What bad thing happens to the business if the application fails?” And another interesting question: “How can we protect the business from the bad consequence of the application failing?”
In my experience, this varies dramatically based upon the nature of the application. For example, the failure of a typical Oracle application will result in severe consequences to the business. This is because of the nature of the beast: Oracle is spectacularly expensive. Thus, any customer in his / her right mind would only store very important data in that environment. Typically, Oracle manages the primary business data of the enterprise for this reason. Thus, loss of even a single Oracle transaction (say the trading instructions of a customer of a stock broker) would result in hard, severe legal consequences.
In this context (i.e. a traditional 2nd platform application like Oracle), concepts like backup, clustering, and remote replication all make perfect sense, and EMC has exceptional products to supply those needs.
A 3rd platform application is typically very different. Take MongoDB, an application with which I am fairly familiar. Mongo will consistently tell you: “You are going to lose some data. Get over it!” Thus, Mongo is not used for any purpose where transactional consistency is required. Usually, the customer will implement Mongo for an intermediate stage, scratchpad type of function. Also, Mongo datastores are often astronomically large. (Petabytes are common.) It is simply not possible to back up something that big.
Further, Mongo implements sharding, a geographically dispersed form of redundant replication. For this reason, the loss of a single Mongo server is simply uninteresting. No consequences occur at all from this, other than possibly a minor, temporary performance blip.
For these reasons, clustering, backup and remote replication are not very interesting for a 3rd platform application like Mongo (although there is some variability in that).
Therein lies the challenge for a company like EMC, which has traditionally dominated in the mission-critical 2nd platform types of applications, similar to Oracle. But then again, EMC has a long and storied tradition of reinvention. I have no doubt that EMC will eventually become one of the dominant players in the 3rd platform