— ROELBOB
Category: Blogs
-
6 Key Considerations When Migrating to AWS
Every day, more and more organizations take the plunge and migrate to the Amazon Web Services public cloud. What they leave behind is the cumbersomeness of the traditional data center, but despite the cloud’s benefits in scalability, agility and efficiency, they discover a new set of challenges that need to be overcome.
Gartner estimates that more than 50 percent of enterprises will have adopted a hybrid cloud approach by 2017. Transitioning from a traditional on-premise IT infrastructures to a public cloud can be daunting, however, and success requires a different mindset and range of skills. This shift can be particularly challenging for traditional enterprises because they have a lot at stake. Here are the five main challenges in moving to the AWS cloud.
Cloud Finances
Different organizations have different financial approaches, and their choices of IT infrastructure reflect this fact. For some, the on-premise approach of making a large, upfront capital expenditure to purchase infrastructure and then capitalizing the investment over time may be the favorable option because they prefer to keep complete control over their IT environment. However, for others, a heavy initial expense is not ideal, so a cloud approach with only ongoing, operational costs is more fitting. This option may be particularly suitable for organizations with fluctuating needs on a monthly basis, as an on-premises data center will not offer them the flexibility they require.
Regardless of the approach, it is important to compare the respective costs before deciding which one is most suitable. The best option may be to combine both on-premise and cloud to create a hybrid cloud environment. This will allow for steady workloads to be kept onsite while bursts in demand can be processed by an on-demand, public cloud.
Security, Availability
The idea of handing over all of your data to a public cloud provider can be a daunting because of the obvious security and availability concerns. However, public cloud providers must adhere to strict compliance protocols and can implement and maintain much higher security levels than on-premise installations because they have more available resources.
In fact, enterprises have avoided migration to the cloud for a long time due to security concerns. However, this is slowly changing, as IT leaders now realize that running on the public cloud actually can bring the advantage of greater security because AWS has industry-compliant cloud infrastructure (HIPAA and PCI-DSS standards, for example).
Nonetheless, AWS customers must understand their responsibility in protecting user data and implementing a service level agreement (SLA). For more information, take a look at the AWS “sharing the responsibility” model.
Rehost (Lift and Shift) vs. Rebuild (Re-architect)
Migration to the cloud requires some amount of preparation before in-house applications can be moved. Gartner describes five different methods of application migration, and two of them are specifically relevant when discussing IaaS—rehosting and rebuilding.
Rehosting (also known as the “lift-and-shift” approach) involves taking an application and re-deploying it to a different hardware environment without making changes to the application’s architecture. Although this is a quick-fix solution that will have your application up and running on the cloud quickly, rehosted applications probably will not be able to utilize the main advantages of the cloud (such as horizontal scalability) because they were built on top of custom vertically integrated hardware. Rehosting allows organizations to get away from high on-premises infrastructure costs, but the approach is suited mainly to applications with easily defined patterns.
Resource-intensive apps (such as those used for image rendering or big data analysis) are more suited to the rebuild (or “re-architect”) approach, in which the original code is scrapped and replaced with new code. These types of applications naturally rely on commodity hardware and have the ability to scale, so keeping them in closed, on-premise silos could mean you end up with performance issues and high costs.
Rebuilding is naturally a time-consuming and costly process. The solution, therefore, lies somewhere between the two approaches, with the main deciding factors being cost and security of the workloads.
Get it Right from the Start
At the beginning of the process, be careful in selecting which apps or services you move to the cloud. If the first few are successful, that will set the tone for the whole migration. If some of the early projects fail, enthusiasm for the migration will dwindle and make it more difficult to complete.
Be smart by choosing projects that are most likely to be successful, such as non-critical applications or services that can be migrated easily. Make sure your environment is transparent from the start by using modern monitoring and logging systems that can collect large amounts of log data and then parse it to find events and provide insightful information.
In addition, knowing your cloud environment will significantly increase your success rate. Don’t get too ambitious and try to do it all at once. Follow each small success with another, and your team will ensure a smooth migration.
Beware of Staff Apprehension
Any dramatic change within an IT environment will face staff apprehension. You might expect the shift to be met with resistance from corporate management, but the real doubts will come from your IT team. After working with on-premise infrastructure for years, administrators will not welcome any changes they think could jeopardize their jobs. Help your team embrace this shift by making sure they receive suitable training to prepare them for a new set of challenges.
Log Analysis and Metric Collection
Organizations moving to AWS suddenly find themselves managing a highly scalable and highly dynamic environment that requires a new type of log analytics and metric collection. The need for centralization of data is crucial in dynamic environments because often you find yourself trying to troubleshoot a problem on servers that no longer exist.
During the most recent re:Invent, AWS CTO Werner Vogels emphasized the need for centralized log collection as necessary for success in AWS migration:
IT organizations suddenly gain access to thousands of servers running more applications than ever that also wind up generating more log files than most IT organizations can possibly cope with. … In order to be successful in the cloud, IT organizations need to relentlessly measure how both systems and applications are performing. The problem is that log collection and processing is painful.
All of the individual components Vogels described each have their own outputs of important log data that need to be analyzed. To ensure a successful AWS migration, logs from your applications, infrastructure and S3 Access buckets—and much more—all must be monitored to ensure all of the parts of your new AWS environment are operating in a way that is secure, highly available and scalable. (To help IT organizations, we have published a free e-book on AWS log analytics with the open source ELK Stack.)
AWS: A Final Note
AWS is the preferable public (IaaS) cloud choice for enterprises today, and it looks set to stay this way. To achieve a successful transition during a migration of workloads and products to AWS, the process needs to be carefully planned and implemented in a step-by-step fashion that will prove the benefits of the move to all of the stakeholders.
-
InterConnect 2016: Culture Matters
The recent IBM InterConnect 2016 focused on plenty of tools and technologies, from cloud/SaaS solutions to containers and automation, but there was another popular topic of conversation heard in the halls—the culture of organizations. The basic premise of these conversations was that unless you get the culture right, all the technology in the world won’t get an organization to where it needs to be to compete in the ongoing digital transformation.
At Nationwide, we have developed a foundational DevOps model that has two main pillars built on top of Gene Kim’s “The Three Ways” and lean and agile principles.
While there are initiatives to implement the DevOps-related practices such as continuous integration using Jenkins, continuous delivery using TaskTop and UrbanCode and version control everything using GIT, how does one influence culture? Because clearly if the culture is not correct, technology solutions will not be enough to reach the goals of DevOps in terms of reducing lead time and enabling the business areas to be more responsive to market needs.
Trust: The Foundation of Culture
A key component of what underpins culture is trust. This was emphasized in a blog written by Lee Reid last year titled, “The Simple Math of DevOps.”
So how does one build trust? Here are 13 behaviors that build trust from Steven Covey:
Colin Powell, in a video on the Essence of Leadership, talks in a powerful way about this, saying that one way to build trust is to “Do what you say and say what you do.” He also stresses that successful leaders are those who provide selfless service to their teams.
I don’t claim to have any magical formula to build trust, but clearly an organization’s transformational success must include a focus on culture and trust. Without this, the true promise of DevOps won’t be realized.
You can read more about my session, “Achieving continuous visibility across the DevOps Lifecycle” at InterConnect 2016.
About the Author| Carmen DeArdo
Carmen DeArdo is technology director at Nationwide Insurance. An ardent advocate of DevOps and a leading speaker in the DevOps and technology related events, Carmen is responsible for driving continuous delivery utilizing DevOps, lean and agile techniques across mobile, distributed and mainframe and other technologies. -
Trick Question: What is DevOps?
DevOps suffers from the lack of a clearly defined definition. A Google search displays results that state that DevOps is empathy, culture or a movement. There are also derivations of DevOps, such as ChatOps and HugOps.
A lot of speakers mention DEVOPS but no-one seemed to have a widely agreed definition of what DEVOPS actually means.
— Stephen Booth (@stephenbooth_uk) November 19, 2015
Proposed Definition of DevOps: “Getting more done with fewer meetings.”
— DevOps Research (@devopsresearch) October 12, 2015
The real head-scratchers are the number of job postings for DevOps engineers and the number of certifications for DevOps popping up all over the web. The job title “software engineer” is contentious within the technology community, so the job title “DevOps engineer” is just begging to take pointless debates to a new level.
How, then, do you create a curriculum and certification course that has any significant value on an unclear subject?
For a methodology that has an emphasis on people, empathy and communications, it falls woefully short of heeding its own advice and values. On any given day, you can see the meaning debated on blog posts and tweets.
My Understanding of DevOps and Why it Exists
DevOps is an extension of the agile methodology that is hyperfocused on bringing customers extraordinary value without compromising creativity (development) or stability (operations). DevOps is from the two merged worlds of development and operations—operations in this context include all aspects of IT such as system administration, maintenance, etc.
Creation and stability are naturally at odds with each other. The ripple effect is a good way to explain how these two concepts have friction. Stability wants to keep the pond from becoming turbulent and causing harm. Creation leads to change, which can act as a random rock thrown into the water and sending ripples throughout the whole pond, leading to undesired side effects that cause harm to the whole ecosystem.
DevOps seeks to leverage the momentum of controlled ripples to bring about effective change without causing enough turbulence to impact the whole pond negatively.
The natural friction between these two needs often drives a wedge between development and operations. Operations worry that a product update may include broken functionality that customers have come to depend on, and developers worry that sorely needed new features may not make it to customers because of an operation’s resistance to change.
Instead of taking polarizing positions, DevOps is focused on blending those two positions into a force that effectively provides value to the customer without compromising the creativity and stability that a product or service needs to compete in an ever-evolving world.
Why is a Clear, Singular Meaning Needed?
The understanding of a meaning is an important part of sending a message.
If an unclear word is used to send a message, the word risks becoming noise and the message risks becoming uninterpreted or misinterpreted.
Without a clear, singular meaning, you risk losing the message that you want people to hear. In technology, I see messages get drowned in noise all the time.
In communications theory, noise is anything that interferes with understanding. Noise is more than just the sounds of static, loud music or machinery. Creating noise can be simple as using obscure words to explain a topic or providing an unclear definition that muddles the comprehension of a given subject.
DevOps suffers from too much noise that increases people’s uncertainty of the word. After reading a few posts on DevOps, each one with its declaration of the essence of DevOps, people can get confused by what the word means. DevOps is empathy! DevOps is culture! DevOps is a movement!
Because of noise, DevOps seems to stand for multiple ideas plus agile operations without setting any prioritization or definitive context. Okay, so which is it? Is it one of those or is it all of them? Which idea is the most important? Furthermore, these ideas can cause friction, as not everyone shares the same view on these topics. DevOps is supposed to reduce friction between naturally opposing groups within a business, not create more of it.
Remove the Barriers
Another aspect of noise is using words that are a barrier to understanding a given definition.
DevOps is the practice of operations and development engineers participating together in the entire service life cycle, from design through the development process to production support.
People from a non-technical background or outside the world of agile and development may have a difficult time understanding a definition like that. When I read something like this, all is hear in my head is same sound the teacher in Peanuts makes: “Blah, blah blah, blah.”
If you want people to remember something, make it easy to understand and memorable.
Appeal to All Personality Styles
In marketing, you’re taught to write to appeal to four personality styles: driver, analytical, expressive and amiable. Getting people to work together in the workplace also requires appealing to these four personality types.
There is a need for a single definition of DevOps that appeals to the four personality styles—or, at the very least, refrains from being a barrier to entry. If a person needs to persuade someone who has a driver personality, but the definition includes language that invokes an automatic “no,” that puts people who want to use DevOps at a disadvantage.
Give people every advantage you can for them to adopt DevOps.
It’s Time for a Definition for DevOps
At a time when the DevOps role is becoming increasingly important for businesses, it is crucial that a globally recognized definition be created to reduce uncertainty. It’s hypocritical to introduce a word that touches upon the importance of communication and then expect people to take it seriously when the definition constantly changes.
It’s time that we have a singular definition for DevOps so people can use it for the hiring process or certifications without the risk of the message being lost or co-opted into something it is not.
About the Author/Michael Herndon
Michael is the head of DevOps at Solovis, creator of badmishka.co, and all around mischievous nerdy guy. He is writing on behalf of Packt Publishing. -
Changing the Culture of Metrics Analysis
You could say the development and operations teams gave birth to the idea of DevOps, as it is believed the chief benefits are garnered in those two functional disciplines. Because of this, metrics nearly always are conducted from the points of view of cost reduction, speed and efficiency. This makes perfect sense when business treats IT (and IT sees itself) as a service- or cost-based organization. But what if DevOps has a few more characteristics that could actually change that culture? What if, for the first time, DevOps could enable IT to become a real partner with the business organization it serves?
To make this happen, business and IT must begin to share attainable goals. Imagine the impact of a highly functioning, enterprise-class DevOps service within IT; upon the time to market of products and services the business is looking to launch. A proven, consistent ability of IT to deliver on time or ahead of schedule (i.e., reliability) then begins to change the dynamics of what marketing proposes and delivers. Time then becomes a valid metric to consider when looking at customer adoption rates. DevOps usually does not directly impact initial market demand, but the impact of delivering new services or features months or years ahead of previous projections can dramatically impact time to market. For example, if your business is able to change its billing model or billing methods six months to a year ahead of every one of your competitors, what impact might that have on market adoption? At that point DevOps becomes a key business differentiator, until the rest of the universe has it.
Consider an additional impact of a highly functioning DevOps service on feature delivery or the feature road maps themselves. The implementation of DevOps inherently delivers smaller units of change on a higher frequency, reducing risk and allowing iteration and alteration of future plans based on the real-time feedback of change success. Marketing focus groups may provide an original road map, but the impact of DevOps can be integrated back into those same focus groups. Instead of imagining what might be possible, DevOps allows delivery of what is possible to see, feel, touch and prompt further imagination. The net impact is an increase to the pace and depth of innovation itself. You know what your customers really want, and you can give it to them quicker. What kind of impact does that have on the reputation of your business if it becomes a market leader because of this? Or what happens when a large organization is then able to deliver with the speed, agility and flexibility of a small firm?
Cost Reduction vs. Revenue Generation
Now consider the value of cost-reduction metrics compared with revenue-generation metrics. It is easy enough to determine that the pre-DevOps delivery cycle might have been 12 weeks per feature as an example, or that each build took six hours to complete and now post-DevOps takes only 12 minutes to run. Metrics like these will begin to show an increase in productivity by existing development staff—or, maintaining the same feature delivery rate, a reduction in the number of personnel needed to achieve them. Similarly, it is easy to show a reduced number of trouble tickets post-DevOps, and a concurrent reduction in the average time to resolve each ticket. DevOps then has enabled the CIO to continue to take arbitrary budget cuts demanded by the business each year. This is not partnership—over time this is a recipe for the reduction, pace and quality of innovation (the smartest people leave first during layoffs; they don’t need to stay).
However, even significant cost-reduction metrics pale in comparison to revenue-generation metrics. As an alternative, imagine what the net growth in customers of a given product might be, over a six-month period of time, because a desired feature set was delivered early? And what if it is two to three years before your competitors can implement the same high-functioning DevOps services you already have in place today? If a business makes $2 per-widget profit and captures 20 percent additional market share over six months, equating to “x” million new customers … well, you begin to get the idea. All of the sudden IT is no longer viewed as a cost center by business; it is viewed as a revenue-enabler. The immediate business response is, “If I allocated more budget into the types of staff facilitating DevOps services (running the gamut from coding to operations to marketing), could I gain even faster delivery rates or deeper feature sets or more market share by pioneering what has never been pioneered?”
The two main reasons this realization hardly ever occurs in business today are that 1.) IT has failed at delivering on promises so often it has trained the business to believe it “cannot” deliver on time or on budget; and 2.) few businesses conduct accurate time-to-market metrics measuring the delta of what additional “time” does to the equation, largely because they never had to. DevOps provides the catalyst to begin to re-examine both of these phenomenon.
But it goes deeper than that. Changing the culture of innovation, in which I am eager to test new ideas faster, means I need more ideas all the time. The competitive advantage our nation, our businesses and our careers have always benefited from is our ability to create and innovate. Other nations around the world, or other organizations your company competes with, may be able to do repetitive tasks faster or more efficiently. But rarely do worker-drones create or produce a wealth of ideas. But if we begin to focus on the long-term impact of fostering innovation in our own country, and in our companies, we will remain perpetually out front. The goal of DevOps is not merely efficiency, it is also to spark the imagination. When our focus and our metrics reflect this, we all win.
If you would like to continue a conversation on how to create and implement a highly functioning enterprise class DevOps service, feel free to contact me.
-
In DevOps, Standardize to Minimize Architectural Debt
I recently reading a great Q&A with the Etsy CTO John Allspaw over on The New Stack, which contained some nuggets of good advice that increasingly are important as we continue the journey toward DevOps adoption. Of particular note were statements on the introduction of “new” things to solve problems. In a nutshell, Allspaw reinforced the importance of standardization as a means to reduce architectural debt.
If you aren’t familiar with the concept of architectural debt, it’s similar to technical debt, in which choices made today incur longer term investments of time and money when future changes are introduced. If you settle on a caching solution such as Redis, for example, there are technical and architectural implications. You can’t simply switch out Redis for memcached later without significant changes to both code and the infrastructure.
Even your choice of load balancer today implies architectural debt because of the growing inclusion of scalability as part of the application infrastructure itself. The result is integration with automation and orchestration systems that are not easily changed later on if you decide you want a different solution. The style of service registry you choose is an architectural decision that impacts clients, servers and systems across the microservices architecture. Switching from client-side to server-side will later be costly.
That’s architectural debt.
Allspaw noted the need to not reinvent the wheel when possible, and instead encourage the collaborative aspects of DevOps as a means to avoid reinventing the wheel and potentially increasing the architectural debt load on the organization.
This is not a new concept. There’s a reason enterprises in particular proudly proclaim themselves “Java shops” or “Microsoft shops” and primarily require development in one or perhaps two languages, but no more. Maintainability is a component of technical debt, just as middleware decisions are a component of architectural debt.
So as we continue to see wider DevOps adoption, it’s important that we carefully consider the impact of our choices in terms of the automation, orchestration and integration required to implement continuous delivery and deployment. Once you’ve invested time and energy (and probably budget, too) in Puppet or Chef, VMware or Cisco, OpenStack or SaltStack, you’re going to find an unavoidable amount of technical and architectural debt in development as well as production across infrastructure and networking teams.
Each of these systems, solutions and frameworks comes with its own components. It isn’t just a language, it’s a comprehensive system with management and repositories and agents and reporting components. All of these impose certain architectural requirements on organizations, from needing certain software running to prescriptive details on networking that must be enforced, lest the system break down.
We’re already starting to see that fragmentation in enterprises that are engaged in automation and orchestration efforts. When asked the number of automation frameworks (Cisco, VMware, Python, OpenStack, Chef, Puppet, etc…) in use, one-third today reported using three or more.
That’s not necessarily “bad,” as it could be indicative of standardization across silos (networking wants to use Cisco, infrastructure is already on VMware, and Python is being used to cobble it together by ops), but it also could be an early sign of the kind of fragmentation that causes exponential growth in technical and architectural debt.
Certainly there is room for experimentation in these early days, but it behooves us to maintain a watchful eye on the use of frameworks and systems and languages we employ for automation and orchestration to ensure we don’t end up buried in technical and architectural debt.
Standardization, even loosely enforced, can help minimize the impact of that debt before it spirals out of control.
-
DevOps and Agility for Multi-Speed IT
Let’s step back for a moment and look at the IT world a bit differently from the traditional technology-centric lens through which most of us IT peeps tend to look at things. Line of business (LOBs) need us, the IT organizations, to deliver capabilities to their customers and users that deliver business value. They also rely on these systems to provide feedback on how customers and users are consuming the business capabilities and deriving value; how they are interacting the business systems; and what capabilities and features they need to get better value. The LOBs are asking the IT organizations to deliver these capabilities with:
- Velocity
- Agility
- Innovation
- Cost Management
IT organizations, in most cases, are not designed for velocity, agility or innovation. They are large organizations hindered in their ability to deliver these by legacy systems, myriad practices and tools, overbearing governance and compliance regimes, archaic and siloed organizational structures and cultural inertia. This lack of ability of the IT organizations to deliver agility, velocity and innovation in some cases even results in LOBs creating their own “Shadow IT” organizations to deliver their IT needs.
Finding Velocity, Agility and Innovation
The solution of late has been to undergo a DevOps transformation that enables IT organizations to adopt the necessary practices, automation tools and organizational and cultural change to deliver with velocity and agility, and become innovative by being able to deliver rapid experimentation. The origins of DevOps lie in Lean IT, and adopting DevOps is really applying Lean principles to help achieve agility, velocity and innovation.
DevOps does so by making organizations that are delivering IT systems and software more efficient and lean. Organizations that have adopted DevOps are able to:
- Get ideas out to production faster
- Have users/user surrogates use them
- Get rapid feedback
Using this feedback the organizations can improve three things:
- Applications delivered
- The infrastructure delivered
- The process by which IT systems and software are delivered
However, large organizations have been struggling to achieve the results promised by DevOps and achieved by the poster children of DevOps, with whom the movement started. For every Netflix and Etsy out there, there is a large, complex, organization that has been struggling with simply where to start. They may be able to achieve success in some parts of their IT organization—with small, innovative ‘two pizza’ teams working on isolated projects—but not at enterprise scale. They struggle with how to achieve even the results of DevOps adoption they see in their own successful teams, at scale. The organizational and cultural inertia appears to be too difficult to overcome.
The major reason of this inability to achieve at scale is the persistent struggle in all large organizations between the desire to innovate, and the need for stability. This push-and-pull exists in all organizations—even an innovative startup feels it. The Dev teams are focused on creating innovation thru rapid change and experimentation, and the Ops teams are focused on creating stability and continuity. DevOps addresses this existential struggle by adopting a series of practices that drive cultural change, automation and process adoption that allow these Dev and Ops teams to work toward common goals and balance their needs. Even in large organizations, this can be achieved on small teams that are able to circumvent the legacy organizational structures and practices and figure out how to get all the stakeholders working toward common goals. That is why this works great on small, strategic projects that have well-defined goals and timelines and can “fly below the radar” of corporate governance enforcers. As we move to larger projects with large, potentially distributed teams, spread across different groups and corporate “fiefdoms,” adoption struggles and often fails.
The Rise of Multi-Speed IT
One fact these large organizations need to recognize is that they really must have two modes of delivering IT: one focused on innovation (and velocity and agility) and the other focused on optimization (stability and continuity, with agility and velocity). This view is being referred to in the industry as “bi-modal IT” and is actually more of a continuum than a clear-cut two modes model. Hence, the term is evolving now to “multi-speed IT.” However, classifying the continuum into two broad categories based on the business intents of innovation or optimization serves the purpose of determining how to adopt DevOps very well.
Multi-Speed ITOne interesting way to look at these two modes is to classify them as:
- The ‘Industrialized Core’ that delivers core business capabilities—things that keep the business going, and the primary business intent is optimization
- The ‘Innovation Edge’ where experimentation happens and new systems get identified and developed; in other words, the primary business intent is innovation
Innovation vs. OptimizationThe goal of the Innovation Edge is to allow for rapid experimentation, development of minimum viable products (MVP), rapid delivery and fast failure. The goal of the Industrialized Core, on the other hand, is to be lean and efficient and deliver business capabilities in an optimized, predictable, stable and secure manner, with the ability to scale as needed. Note: Eventually systems from the Innovation Edge will need to be “industrialized” once they start serving a core business function. This is a continuum from innovation to optimization.
The Industrialized Core itself needs to be continuously incrementally industrialized to provide the stability and reliability needed, while getting leaner and more efficient, at scale. The core needs to get to optimization, with agility and velocity, as it delivers the core systems, again at scale. The core, too, needs to adopt DevOps and agile development practices, even for legacy systems, including those on the mainframe. This Industrialized Core is, after all, what keeps the business going and delivers the ongoing business value as the Innovation Edge seeks out new and disruptive business capabilities and avenues to deliver them.
However, they both need different DevOps approaches and platforms delivering Agility, Velocity and Innovation at different levels.
These two systems to deliver business capabilities are, in reality, joined at the hip. The systems delivered on the Innovation Edge are dependent on the services provided by the Industrialized Core to deliver the innovations they are developing. The Industrialized Core, on the other hand, consumes most of the budget in typical large organizations, and needs to be optimized to free resources for innovation.
Consider a typical mobile application (say, mobile banking). To deliver that application, there is a team charged with developing the mobile front end. These kind of applications are developed and delivered in the Innovation Edge. Does all of the data and business logic sit on your mobile phone when you use that application? Of course not. Most likely, the business logic and certainly the data are components of the application that are delivered by pre-existing systems or services in the Industrialized Core. So, the mobile application is hybrid, comprised of components running in both places. To deliver even some experimental features of this mobile app, the company needs to release a hybrid or composite application, delivering components delivered by both the Innovation Edge and the Industrialized Core.
During the Dev/Test cycle, these two modes of application delivery must be as decoupled as possible, so the development schedules and cycles of one does not drag the other, to prevent the Core from becoming a drag on the Innovation. Creating an API ecosystem is thus essential to decouple the Industrialized Core from the Innovation Edge. The Core provides the business services consumed by the innovative applications being delivered by the Innovation Edge as APIs. A key benefit of developing this API-based architecture is that these APIs potentially can be monetized to third-party partners, generating a revenue source at the same time.
It is important to note that the architectural and process needs for adopting DevOps in both of these modes are different in many ways. Their needs and how they deliver applications and services differ as they are serving different business goals. In my next post, I will start delving into these architectural and process needs for adopting DevOps for both the Innovation Edge and for the Industrialized Core, which allow the Innovative Edge to allow for experimentation and innovation, and for the Industrialized Core become more optimized.
Watch this discussion between industry practitioners as to how they have adopted DevOps in a multi-speed IT model: the challenges faced, successes achieved and lessons learned.
About the Author/ Sanjeev Sharma
Sanjeev Sharma, CTO and Distinguished Engineer – DevOps Technical Sales and Adoption, IBM Cloud Unit, is a 20-year veteran of the software industry with expertise in DevOps, Mobile Development and UX, Lean and Agile Transformation, Application Lifecycle Management and Software Supply Chains. He is a DevOps Thought Leader at IBM and speaks regularly at conferences. He has written several papers and is the author of the DevOps for Dummies book.
-
Building a Business Case for DevOps
You can get your DevOps vehicle as fast and fine-tuned as you like, but until you provide an effective business case to the board it will remain in the garage. To get the thumbs up, you have to prove your model is efficient and makes financial sense for the company as a whole.
Do You Need to Make a Business Case for DevOps?
Coherent business cases are needed for companies at various different stages of their DevOps journey, not just those at the very beginning. Ask yourself which one of these scenarios best suits your current situation:
- You/your CIO know(s) the company needs to become more agile, but you don’t know how to quantify the benefits.
- Your teams have started to implement DevOps practices locally and can see the benefits, but you don’t know how to quantify the success to sell it to management.
- Your organization sees the success of DevOps pilots, but need to justify the investment to bring DevOps to an enterprise scale.
DevOps can represent a huge shakeup of the IT department that must be justified clearly and logically. The risk must be outweighed by the projected financial gain. Crucially, this needs to be quantified in language that finance department can relate to. It is referred to as the hurdle rate: the necessary annual or total return of a project to compensate for the risk.
What Should the Business Case Contain?
- Executive briefing
- Recommendations
- Required decisions
- Business drivers
- Scope
- Assumptions
- Analysis
- NPV (Net Present Value)
- Strategic options
Hallmarks of a Successful DevOps Business Case
Agility
This is the main benefit of DevOps: the ability to deliver applications faster and allow for frequent changes and adoptions all the way into production. But how do we measure and quantify the benefits of agility?
Time Value of Money
The time value of money expresses the fact that money today is worth more than money tomorrow. The more you have to invest early (instead of over time) and the longer it takes to receive the return, the lower the present value of your investment.
The number you receive when calculating the present value of an investment (benefits minus costs) is called NPV (Net Present Value). It tells you what your future investment is worth today.
With agile and DevOps you are able to develop an application and deliver it to your end user in small chunks rather than in big ones; thus, you will improve the NPV (Net Present Value) of your project even if the total amount of investment and output are the same.
Delivering software continuously rather than yearly creates benefits in the same way as receiving interest on your savings account every day rather than just once a year.
The precise time value of money depends on the average cost of capital a company has to bear. For example, a large, publicly traded company has a lower cost of capital than a small, privately owned one. Your finance department will know it.
Cost of Waste
A second aspect, which speaks for agility in a quantifiable manner, is the reduction of waste.
Functionality delivered using non-agile software engineering practices may be irrelevant or outdated once it reaches the end user because of the time gap and mismatches in requirements and expectations. The cost of such waste can be reduced drastically by using DevOps.
Calculate the benefit of waste reduction using available statistics on the average percentage of functionality used without changes in your applications. It may pay off to assess this number for the last two or three releases delivered.
Take into consideration:
- Total cost of development and delivery of these releases.
- Relative efforts of different functionalities delivered by release.
- Cost of change requests that arrived during and after the release date.
- End-user survey on the need and usability of these functionalities.
Combine the benefit of waste reduction and of frequent delivery and add them as positive future cash flows to your calculation.
You also need to calculate the forecasted costs of your DevOps initiative. Consider:
- Investment in build, test, deploy and provisioning and related operating expenses.
- Investment in IT infrastructure.
- Investment to complement skills in development and operations teams.
- Investment in organizational changes.
- Operating expenses for all above.
- Extra cost of non-automated activities in test, release and deploy due to increased release velocity.
As part of your strategic options in the business case, balance your investments in automation with investments in more resources for build, test and deploy for given agility scenarios. The higher the release velocity, the more build, test and deploy activities are required. The more automation, the less of these activities must be done manually. Visualize in diagrams how the investment in more automation starts to pay off with increasing release velocity.
Finally, sum up positive and negative cash flows and use your company’s hurdle rate to calculate your NPV.
About the Author/Michael Schmidt
Michael Schmidt heads DevOps Practice at Automic, a management and technology advisory service established to help Automic customers to prepare for and transform their organizations toward DevOps. Michael spent his carrier as consultant, entrepreneur and in several product-related leadership positions. He has a passion for building lean IT organizations. Michael holds a joint MBA from New York University, London School of Economics and HEC Paris and a Master of Computing Science.