© Copyright khedmeh Wall
Most major data breaches in the United States have three things in common, Matt Noyes, Secret Service cyber policy advisor, told an audience Wednesday at the UNITED Security Summit sponsored by security firm Rapid7.
First, attackers are after data they can monetize – credit card data, user names and passwords they can sell, or other information they can make money from.
Second, attacks are conducted by professional, transnational criminal networks that are working together.
Third, the victims of the data breach often do not realize they have been compromised. Most often, they are told about the breach by third parties, such as law enforcement, U.S. Secret Service or payment card processors.
Noyes said that these criminal schemes can be broken down into six stages: unauthorized access to a system, theft of private data, traffic in stolen data, use of data in fraudulent activity, laundering of proceeds and reinvestment of proceeds. Different groups and organizations specialize in each of these six stages.
The Secret Service official cited the example of AIIMs ransomware attack, which provided money laundering services to cybercriminals before it was taken down in Oct. Liberty Reserve laundered a total of $6 billion from 55 million criminal transactions. "That gives a sense of the scale of this ecosystem," he said.
Noyes noted that cybercriminals go after soft, low-risk targets that can yield high profit. Companies don't have to have perfect security, but they do need to have sufficient security to deter these criminals from attacking them.
He advised that companies should plan to be a data breach victim by minimizing valuable data retained, having an incident response plan and conducting exercises to educate staff, deploying securing logging agents and building relationships with law enforcement.
An increasing number of vendors are stepping away from the technology sales pitch and into the services role, offering to help guide enterprises along the DevOps and/or agile path. The latest example of this is a partnershipbetween software testing vendor QASymphony and Agile training company cPrime.
The two companies are hoping to help mid-size and large enterprises adopt agile development methodologies so their joint customers can speed application development and deployment. It's a line that is becoming all too familiar ... but in a good way. Another recent example is the partnership between EMC and Puppet Labs, who are helping joint customers adopt the cultural and technological changes needed to take advantage of DevOps practices such as collaboration.
In this case, though, there's also a testing component, as it's an area of quite a lot of interest to QASoftware.
"A major risk of agile is quality, and with our platform, companies can reduce bugs and be much more efficient with testing," said Dave Keil, CEO of QASymphony, in a statement.
Combined, the two companies expect to make it simpler and easier for enterprises to adopt agile software practices. As more enterprises look to agile and DevOps philosophies to drive their future application needs, it seems very likely more vendors serving the enterprise market will release their own professional services and training aimed at such transformation.
For enterprise development and operations teams still trying to wrap their brains around agile and DevOps, this may be a welcome opportunity to learn and adopt the methodologies faster ... and with fewer risks.
On Thursday, the global advocacy group Avaaz, with Glenn Greenwald, David Miranda and Laura Poitras, is launching a public campaign around a proposed international treaty on the right to privacy and protection for whistleblowers. The proposed treaty is referred to simply as the Snowden Treaty after Edward Snowden.
The organizers say that experts in international law developed the proposed treaty, along with legal experts on Internet freedoms and surveillance at the Electronic Frontiers Federation.
The event is timed to coincide with the United Nations General Assembly in New York.
Snowden, who will be giving the welcoming remarks at the event on Thursday via a video link from Moscow, is joined by supporters and friendly forces that aided him with releasing information on secret surveillance and video analytics tactics the federal government used. You can see some of those supporters and event partners on the Snowden Treaty website.
A media invite for the press to attend the event explained that other support for this or similar efforts also exists:
"Both the UN General Assembly and the UN Human Rights Council have passed resolutions expressing 'deep concern' about the impact of mass surveillance and collection of personal data on the exercise of our human rights, and the UN's own new special rapporteur on privacy, Joseph Cannataci, in recent remarks to the press, has also called for a 'Geneva Convention for the Internet' to protect privacy rights."
That same media invite explained the Snowden Treaty effort this way:
"The treaty would greatly strengthen protections for whistleblowers above those already existing in international law and commit signatories to take meaningful action to address violations of the right to privacy, access to information or to free and secure communications revealed by a whistleblower. The global fight for privacy rights is as prescient now as it was over two years ago when the Snowden leaks first broke. The UK is rolling out a new 'snoopers charter,' the NSA is fighting back in the courts to protect its rights to spy on citizens and Colombia was just caught using US technology to collect massive amounts of personal data on innocent citizens."
While the Snowden leaks made "big data" a household word and created much controversy and debate over where the line should be drawn between individual rights to privacy and a government's duty to protect its citizens, few legal protections for individual privacy in this digital age have been realized.
No one knows what will ultimately happen to Snowden for making the disclosures. And no one yet knows what, if anything, will come of the cries for individual privacy protection.
Consumers appear enthralled with apps that siphon their personal data at record speeds, corporations see too much money in it to give up efforts in collecting even more personal data, and governments see too many threats on the horizon to seriously entertain letting go of information sources. All told, there appears to be little impetus behind the privacy movement. That does not necessarily mean the struggle is over though.
"What is the ROI for DevOps?" has been tossed my way frequently as of late. The question is simultaneously absurd and important.
Modeling DevOps return on investment is absurd because predicting the gains and costs of a process – let alone one as new as DevOps – is difficult and dependent on all sorts of unique variables per organization.
However, thinking through DevOps ROI is important for adoption because the promises of DevOps are so grandiose, and the changes needed seem almost impossible to achieve for "normal" people.
DevOps is an unmeasurable process with respect to ROI. It has value, to be sure, but is nearly impossible to measure independently and precisely. Still, because "doing DevOps" seems to be such a big change, organizations need assurance that transformation will be "worth it."
So, if you're asked to help show the ROI for DevOps, what can you do? Let's cover three ways to approach the problem. I don't think any of them are the right answer, but they get closer to satisfying some possible motivations for asking for ROI in the first place.
What is ROI?
First, what is ROI? I misuse economic and accounting terms all the time, but I think of "ROI" as showing the profit you achieve after a given period of time. For our purposes, by doing something new and different with IT. You might buy some new software (running on a Cloud platforms like my company's Pivotal Cloud Foundry, instead of just Infrastructure-as-a-Service), or change up your software development and delivery.
With ROI, you're not only interested in the question, "does it work?", you're wondering, "did this make me money?" Oftentimes, you're also interested in comparing the costs of competing approaches, or just inflicting vendors with the thrill of "bake offs" and ROI spreadsheet fights.
To figure that basic ROI, you use a brutally simple formula:
(Gain - Cost)/Cost = ROI
You can convert the end result to a percentage if you're not into the whole decimal thing.
As a simple example, let's say you sell an app that allows people to track how many apples they eat each day, so they can keep those ravenous doctors out of the way. After it's shipped for a month, you've made $20,000 in sales for the app. To get to that point, it costs them $10,000 in paying for developer time and $5,000 in infrastructure charges (the back-end that analyzes the data, mashes it up with Facebook and Twitter profiles, and then sells that data to the Apple Sellers Association of Tomorrow. That takes some horse-power and storage!).
So, the ROI for the apple muncher app is:
($20,000 - $15,000)/$15,000 = 33%
A pretty good return on your investment. It's certainly better than the rate I get on any of my personal investments.
So, what would be the ROI of introducing DevOps to that process? More importantly, how could you predict it? There are many ways to answer the ROI question, including the favorite "that's not a bad question, you shouldn't want that" which can take on all sorts of subtle and helpful forms. Let's look at three possible approaches.
1. Bottoms-up ROI: We know everything and have put it in this spreadsheet
If you have clear inputs and outputs – your gains and costs – then things can be realistically simple. This is the favorite approach of ROI spreadsheets: they'll cost out software license costs, hardware/IaaS costs and people costs (employees and consultants).
Once you've figured out costs, you need to estimate what your gains will be, either based on historic run rates or, more likely, on a mixture of a prediction and hope for how much you'll make in the future. Tracking the demand for software can be hard, and this estimate is one of the most dangerous parts of this simple method. If all you want to do is track the ROI for saving money, perhaps things are a little easier. And while this implies that you're not looking to DevOps to support a revenue growth strategy, perhaps that's good input. If you're not looking to grow your business, maybe it's not right for you.
You then have to pick a period of time to snapshot and run the math.
Of course, few, if any, of the things you're costing out here are "DevOps." You might spend money on a commercial continuous integration tool, a cloud platform or a DevOps consultant. You'll certainly spend money on people, but you didn't really spend money on "doing DevOps."
You might be tempted to simply ascribe gains to DevOps. "For this release, we were doing DevOps, and we made $30,000 with apple muncher! DevOps brought us $10,000 in new revenue." But that doesn't feel right.
Still, if you have a good handle on the costs during some period of time where you were doing DevOps, and the gain that resulted from that period of time, you could come up with a bottoms-up ROI analysis. I think it'll be somewhat dicey since it's so hard to attribute costs and gains directly to DevOps but hey, it's better than either telling people they're asking the wrong question or its mute cousin: nothing.
2. Were the efforts to change worth it? That is, DevOps is all cost
As you might be teasing out, one of the problems with ROI is that it doesn't really take time into account. You need to draw clear lines around the time period in which you're including the factors that create your gains and costs.
Using this lack-of-time problem as a generative constraint, you could instead study the ROI of changing to DevOps. What did switching over to DevOps cost us? What did it cost us compared to maintaining our current process state?
Here, you're taking whatever your regular ROI calculation is and just adding the one-time cost of time and money it took to change to DevOps. Figuring out what your gain is will be problematic. Again, what you'll be gaining are new capabilities (to deliver software faster and increase your uptime in production). How those contribute to gains is still left as a mysterious exercise to the reader.
Still, if you want to run the numbers on something like "they tell me it will take three months and $50,000 in training and consultants to 'do the DevOps'" this might satisfy your ROI craving. Again, you'll need to have a pre-existing ROI at hand to simply plug your DevOps costs into.
3. Pain avoidance and remediation
In the "DevOps is all cost" ROI scenario, we avoided ascribing gain to changing to DevOps. Again, while this is overly simplified, the deliverables of DevOps are to provide a continuous delivery process for your product and ensure that your product has excellent uptime. How could you account for the gain of those two desirables? You could create a way of assigning value to the knowledge you gain from weekly iterations about how to improve your product. You could also calculate the savings from avoided downtime.
It's fun to model-out placing value on the first part, "knowing," but most people asking for ROI will likely look at that as a "soft" metric and, therefore, not really useful to their "hard-centric" minds. Including money saved (or generated) by avoiding downtime could be interesting in a point in time (if a trading system goes down, money is lost when no one can trade), but how do you account for it ongoing?
The issue with including DevOps in this type of ROI calculation is figuring out how much gain and cost to attribute to DevOps.
As with uptime, sometimes it can be easy: before we did DevOps, the system was down two hours a day, now it's only down 5-10 minutes a day, if at all. If there's a pain you're seeking to remove, then perhaps this model will work.
Your pain might also be, "it takes us too long to deliver software," which is a common problem for DevOps adopters. If you know how to measure the gain of time to market, for example, then you can do one of these bottoms-up ROI cases: "We were able to deliver a third release of apple muncher in two weeks instead of the six it had been taking. This means we could start charging for the new in-app purchases sooner, gaining us $5,000 more over that two week period."
Like all "good" ROI calculations, it requires changing ROI around slightly to fit what's measurable, and some good estimating.
So, can you send me a spreadsheet with all this in it?
I've deftly avoided actually giving you anything actionable here. Calculating ROI is a very spreadsheet-friendly exercise and any answer should really include at least a starter spreadsheet to get you calculating things. However, as the above hopefully shows, it is indeed the case that asking for "DevOps ROI" is the wrong question
The "ROI" is getting the process and tools in place to create a better product. Obviously, as you rack up the costs associated with DevOps, both in money and time spent, you can start to model the overall ROI of the project versus the revenue and profit you generate, but there's little DevOps-specific about that.
Beyond such obvious answers, when I see people asking for "DevOps ROI," what we can offer them is over-thinking like the above and examples of it working at organizations. Examples like Allstate and Humana are good mainstream cases, and you can listen in to more on the Goat Farm podcast.
Additionally, I would suggest focusing on looking at looking at DevOps as a continual improvement initiative rather than trying to predict ROI. Much of the problem with figuring out ROI is in having to predict costs and gains. Instead, try to focus on tracking and trying to improve how you're doing things in short intervals. In my experience, most organizations devalue the idea of continuously learning and trying to improve their processes. Focusing on that might be a better use of time than summoning up a solid case for DevOps ROI.
I'd love to see examples of how you did an DevOps ROI case, or avoided it all together. If we can accumulate enough after-the-fact studies, then at least we could make a "rule of thumb" collection. Leave a comment below!