devopsy.kinsta.cloud

Tag: CIO

CIOs Must Fight for Relevance in Face of Tech Storms

The past two decades have seen their share of technological disruption – retail, books, music, newspapers, and traditional data centers by – virtualization and cloud computing. With the impact of cloud computing and mobile BYOD trends on traditional IT departments, there has been an ongoing discussion in recent years about whether or not CIOs and IT leaders are still, or will remain, strategically relevant to the enterprise.

All considered, it’s not an unreasonable question. In many ways, it’s as if traditional IT systems and data centers have been thrown into maintenance mode, while investments pour into cloud, mobile, social media, and data analytics. It’s not just that the importance of the physical data center itself is changing, or that applications are increasingly subscription services rather than bits running on-premises, it’s that increasingly CIOs and IT leaders are left out of the IT buying decisions.

Some of this is showing up in spending trends. According to the Gartner Worldwide IT Spending Forecast, global IT spending will hit $3.5 trillion this year. That’s a top line 5.5% decline from last year. Most of that downward move, however, is attributed to US dollar currency fluctuations, rather than real demand disintegration. In constant currency, global IT spending in 2015 is projected by Gartner to grow at 2.5%. Gartner also expects communications services to be the largest IT spending segment this year, and global mobile phone shipments remain strong.

In the first quarter of 2015, according to IDC, cloud infrastructure sales increased more than 25%, annually, to almost $6.3 billion. During that time, public cloud spending rose to $3.9 billion, up 25.5%, while private cloud sales rose 24.4% to $4.2 billion.

That growth far outdoes that of the broad enterprise software market. Gartner expects enterprise budgets for data center systems in local spending to remain stable for the year, with users expected to extend life cycles and defer replacements to counter price increases related to the strong US dollar. Enterprise software also will decline 1.2 percent this year, but much of that also can be attributed to the strong dollar as well as SaaS revenue being subscription-based.

While a lot of this stagnant to reduced IT spending this year can be attributed to less expensive cloud services, lower CAPEX associated with SaaS pricing, much of it can be attributed to technology spending shifting from centralized IT departments to other segments of the business, such as marketing and human resources. Even more individual users and business managers can choose cloud services for personal productivity software and small workgroups, all of which generally flies under IT radar.

Despite all of these trends having been underway for a number of years now, many organizations still haven’t been able to adapt. It seems not too long ago that IT reigned supreme over every device, server, and data connection in the enterprise. They approved who used what where, and what was production. They dictated where data were stored and how they were secured. And anyone who wanted to use anything information technology-related had to go through the IT department. Those days are gone.

What all of this is certainly doing is changing the dynamic between the “business” and IT. Many of these cloud services bought outside the control of IT run unmanaged, and the result is that IT doesn’t see what users are doing and what they need, so they can’t add value this way to their enterprise users.

This lack of transparency into what technology users are actually using to get work done actually increases the complexity of systems and obfuscates IT from being able to do everything it needs to do to keep relevance. There’s no long-term technology strategy; there’s no panoramic view into all of changes in how people are using new technologies to understand IT opportunities that perhaps are being missed; and lastly there’s no way to enforce security and compliance policies.

What all of this means for IT leaders is that it’s up to them to remain relevant in the years ahead. They’re going to have to find ways to provide value to their internal customers, whether that’s by helping them to build solutions on their own or enhancing apps and services that internal business managers chose themselves. They must help them to find the best external services for their need and create the most friction-free, cost-effective, efficient solutions that optimize end user experiences as well as corporate data. Today, it’s more about end user experience than it is large databases, applications, and ERP rollouts. It’s more about cultivating data than centralizing everything into monolithic databases. And it’s more about helping orchestrate users with mobile, social, and cloud than it is storage and data centers.

It’s about maintaining relevancy in the technological storms that are pounding IT departments today. In the upcoming months, we are going to run periodic stories and Q&As that aim to show business leaders exactly what they need to know to ride through the disruption.

December 2, 2015
Five often expressed obstacles to enterprise IT innovation

Business leaders know, for their business to succeed in the years ahead, that their IT and developer teams need to innovate. But surveys show that too often the IT teams may not be able to deliver the innovative value that the business seeks. Have a look out our recent Q&A, The IT mandate: Be a catalyst of business innovation for some more insight on the IT and business innovation gap. The fact is that technology and developer teams can’t do it on their own, they need to operate in an environment that enables innovation. In speaking with CIOs, developers, and others close to the process of creating value with IT a number of obstacles continuously surface. And these obstacles are holding their development efforts back.

These obstacles include the tight collaboration with development and operations teams, the failure to actually embrace Shadow IT for what it actually is, staying stuck in single mode IT, and oversights in how they are developing mobile applications.

Here they are:

Obstacle Number 1: They don’t effectively unleash the power of their developers. DevOps teams are known to grind through technical debt and when they manage to hit on all cylinders they also have very short application backlogs. One way to keep such app backlogs short is to focus on the Minimum Viable Product (MVP). Because the MVP is an application that is, initially, focused only on what it takes to get the job done, and no less or more, developers don’t get bogged down overdeveloping apps that won’t get used. To be clear, MVP doesn’t mean shoddy app, rather it means the minimum app to be productive at the task. With this Spartan approach, development teams can invest no more than is needed into an app, release it into production and see how enthusiastically (or not) it is embraced by the user base. This enables development teams to push apps forward with as little risk and investment as necessary. And then either dig deeper into that app, or move on to another.

What does that have to do with innovation? Plenty if you consider the amount of time saved from over-developing applications that wont be used and investing that time and effort elsewhere, perhaps apps that will provide value to the organization.

Obstacle Number 2: They don’t embrace shadow IT. Rather than embrace Shadow IT, many organizations shun the notion of users choosing the tools and technology they need to get their job done. But end users and employees are turning to cloud services and bringing their own devices because these are the devices and services that they know they enjoy to use and they can use to effectively do their jobs. That makes for more productive and happier workers. Certainly not just any old rogue service and device can be used, but the enterprise can watch and vet the services that are safe or find ways to make them safe. A good place to look for this is the Cloud Security Alliance’s Security Guidance for Critical Areas of Mobile Computing.

Obstacle Number 3: They don’t bimodal. By not embracing two-speed or bimodal IT, enterprises have a harder time allotting resources to strategic development and IT efforts. In bimodal IT there are two modes, one mode is focused on quickly delivering the applications the enterprise most needs to compete and be effective while the other mode is focused on the infrastructure services and API development and management.

A good overview on bimodal IT can be found here in our post Bimodal IT and Remodeling Traditional IT for Greater Agility.

Obstacle Number 4: There exists an average to poor business to technology interface in the organization. In too many organizations there is a lot of collaboration within the technology groups, such as operations and developers, but not enough interfacing with the business teams. For better outcomes, there needs to be tighter collaboration between DevOps and the business through continuous feedback on current and future objectives. This way DevOps teams know what the business priorities are and can develop to them more effectively.

Obstacle number 5: They aren’t focused on the context within mobile moments. The world of IT has gone mobile and will someday go wearable. This is more than just a mere form factor trade; it is creating a profound change in the way we interact with our apps. When we sit down to work on a laptop, we are usually settling in for a nice stretch of work time. However, when it comes to phones and wearables, we are usually working in short instances. We are sending a text, answering one email, or capturing one or two new data points about a client for entry into the CRM app. Developers need to focus on providing users apps that work in the same way too. That is they need to develop apps that provide users the data they need based on short device interactions and hopefully context of what they’re doing. If the user were at a clients’ office, for instance, and the rep launces the CRM app, it’d be ideal if that customer profile launched by default with the app. If the user is involved in a certain workflow, other items that are commonly taken care of at the same time would also ideally be suggested.

While these obstacles may sound simple, they can be quite transformative to the way your business-technology teams will develop, collaborate with the business, and hopefully provide more innovative services.

October 15, 2015
Leveraging DevOps to Expose The Entire IT Iceberg

On September 16th I attended and spoke at a CIO Magazine event in Chicago. These are some of the best events to attend as the audience is typically CIO or senior IT leadership. One of the speakers on the day, Martha Heller, Author of “The CIO Paradox”, presenting on new competencies for the modern CIO, presented a very eye-opening perspective on limitations moving IT forward into a digital age.

Anyone who has worked in IT for any length of time, or even watched the British comedy show, “The IT Crowd,” probably has some concept of what it means to work in IT. But never have I seen it so explicitly spelled out from an executive level as Mrs. Heller does in her talks relating the brutal reality as expressed by one of her clients. I present the excerpt here from her talk:

“Do not under any circumstances expect applause or a raise when you have dismantled the iceberg. Since no one in the business sees the iceberg and no one understands the iceberg is real and that it is ours they cannot understand what used to be under the water looks and behaves completely differently. Business leaders will understand cost, headcount, throughput and all of the new capabilities that run on top of iceberg. These are the likely places for applause. Expecting recognition and compensation for what you do below the water line is not advised; do not fight that battle. Praise for what happens under the water line only comes from industry peers.”

Clearly the iceberg is IT itself and the waterline represents the separation between what the business can see and touch, e.g. user interfaces, accessibility of data, application performance and IT support, and all the stuff that enables the aforementioned that sits below the water line. If advice by counsel, such as Mrs. Heller, to CIOs is not to expect recognition or compensation for making what happens below the water line work optimally, then it will be very difficult for CIOs to engage and keep personnel that excel in this capacity.

To be clear, I’m not saying that Mrs. Heller is telling her clients not to pay attention. She is merely reiterating the paradox that all CIOs must confront as they inherit and deal with the ever growing mess below the water line caused by acquisitions, aging systems, disruptive technologies, aging labor pools leaving the work force, and workers going to companies where they receive better pay and recognition by because they focus on providing below the water line management services, etc.

The industry has been telling CIOs for at least three years now that they need to pay attention to what is occurring with DevOps. Yet, many still view DevOps as a deep below the water line activity focused on development and system administration. What they are ignoring is that DevOps may very well be the answer to this paradox that Mrs. Heller puts forth. Leveraging DevOps is not only advisable, but necessary for these leaders to succeed.

DevOps has the ability to help lower the water line with the business. As Mrs. Heller reiterates, the business understands costs, headcount, throughput and all the new capabilities that run on top of the iceberg. We have concrete evidence that companies that adopt DevOps philosophies and institute continuous delivery capabilities are able to respond to business changes more rapidly and are more profitable than businesses that are hindered in these areas. DevOps typically increases the level of transparency between IT and the business giving them greater input into direction and providing them a wider perspective for how what is below the water line today impacts the very attributes the business cares about.

Increased automation associated with continuous delivery opens up greater opportunity for self-service, which again moves more of what is below the water line today to above the water line. Self-service provides more touch points for the business to directly control their own agenda and direction leveraging IT resources. Indeed, there are additional ways that DevOps can help to lower the water line that for readability I will not go into here.

Mrs. Heller’s point that attempting to battle the business to gain recognition for what happens below the water line is a losing battle that will tear at the credibility of the CIO that chooses to engage in this battle. However, if CIOs cannot hire and retain the best talent, their ability to stop the iceberg from growing below the water line will continue to diminish. Their only hope is get the water line to drop and expose more of the iceberg. The more of the iceberg that gets exposed the more opportunity the CIO has to obtain recognition and compensation for his/her team.

So, Mr./Mrs. CIO, is DevOps important to you now?

September 28, 2015
What CIOs need to know about building deployment quality

Application Release Automation, or ARA, is the process of packaging and deploying applications (or updates to applications) in an automated, repeatable and consistent way.

In today’s market landscape software has become a major differentiator for many businesses, across all industries and verticals. In a world of apps, Internet of Things and customers’ expectations to be always connected, – just about every company is now becoming a software company. Software development is now critical to the success of your product, and its delivery process needs to be fine-tuned and streamlined to ensure that you get quality software in the hands of your end users as quickly as possible.

To understand how ARA can help you achieve higher quality software releases (which contribute to your bottom line), you must first understand the challenges you might face if your business is still using manual deployments, or other archaic methods. If that’s your case, though, you’re not alone: a survey we ran last year found that over 75 percent of deployments are still done manually, despite the many problems with this model, which is extremely brittle and error prone. This creates not only many failed deployments, but loss of hundreds of men hours trying to troubleshoot those failures. This is certainly painful in the mission critical production environment, but carries great cost long before we reach production. Even in the lower environments (such as testing or pre-production), 66 percent of respondents report its very time consuming just to troubleshoot why the failure occurred. As we promote code to be deployed in production- the stakes are higher. Costs of failed deployments, delayed releases and loss of men hours are exponentially aggravated when you add possible fines on top of that, cost of SLAs violations, customer churn, and loss of business. There’s no question the implications of failed deployments put a major dent in your bottom line, and with some companies – failed deployments have literally put them out of business.

A prime example of how a failed release can have huge impacts on a business is the case of Knight Capital. Knight Capital WAS a financial firm. In August of 2012, they manually pushed out a new release to their software when the markets were down over the weekend. Monday morning came and when the market opened, their new software kicked in. The results were disastrous. They accumulated (extremely quickly and erroneously) a $9 billion [H1] position in the market – represented by the movement of 397 million stocks in just 45 minutes. Two hours later, when Knight was still chasing the culprit in their release process and trying to rollback to a previous version of the software, the New York Stock Exchange said, “We’re done waiting for you,” cut their hardline to the market and Knight couldn’t make any trades.

The effects were disastrous and swift. Knight Capital endured a pre-tax loss of $440 million. Within weeks, Knight Capital was sold for pennies on the dollar – a failed release literally killed the company. While this is certainly a worst-case scenario, it is a great example of how it is necessary to understand that once you start talking about production environments, there is a lot of regulatory and best practices that have to be followed or big problems can occur.

Why are manual deployments so problematic?

First of all, manual deployments are error prone because each deployment has to be done by an actual human. Even the most veteran of developers or ops engineers make mistakes, and when you start talking in the hundreds (or thousands) of deployments, across complex stacks and configurations, an error is almost inevitable. While no system can fully-eliminate the potential for an issue, you can imagine that in a deployment process where many of the steps are automated – and therefore consistent across releases – your chances of an error are reduced dramatically.

With manual deployments, it’s also difficult to achieve true, fine-grained, visibility and auditability into the entire deployment process of all the application’s components and their corresponding infrastructure or configuration. Once a deployment is pushed live, the only person who really knows how, exactly, the update was promoted from Testing to Production is the individual (or individuals) who performed the release. And as good as they might be in keeping notes, they’ll never be as comprehensive, or bulletproof, as an automated log that track every single component in the multi-stages deployment process.

Manual deployments also are not adept at negotiating what is called the “Delivery Gap.” Essentially the delivery gap is the chasm that exists between three different factions of the software team. On one side there is the development team, which has a bunch of tools and practices they like to use. On the other side is Operations, which has their own set of tools and methods/requirements. Then, finally, there is the infrastructure, which spans across both Development and Operations and places requirements on both parties. So you have essentially three different players, using different tools, with difference practices and requirements, and negotiating between them is a tricky and difficult process. Ensuring there’s no configuration drift between infrastructure or app components across the different team, and ensuring consistency in deployment processes has proven difficult for humans to perform, particularly as each process includes hundreds – if not more – of artifacts, configuration files, dependencies and deployment requirements. For an automated process, however, consistency and repeatability are the default state.

So now that we’ve established the pitfalls of manual deployment practices, let’s talk about how Application Release Automation can solve some of these issues and support higher quality software releases.

We’ll start with the aforementioned “delivery gap.” Application Release Automation is a DevOps solution that bridges the gap between the Development teams and Operations teams. It does so by creating a solution that encompasses Continuous Integration, Configuration Management and Deployment practices that respect infrastructure, as well as operation’s needs and regulatory requirements. It achieves this because you can build these considerations into the automated process, which is recorded, logged and tracked by default. Rather than each deployment being a unique ‘snoflake’, software deployments become routine and predictable. It’s not on one person to mentally “flip the switch” and jump back and forth between groups to make sure everyone are satisfied. Rather, it is an automated process that takes everyone’s interests and requirements into account, and then makes sure everything fits within the infrastructure and configuration requirements.

Furthermore, ARA is a “model-driven” approach that allows you to reuse existing templates, configurations and processes over and over to make your deployments consistent, and require minimal overhead for the initial set up of the process. This means you can deploy any version to any environment quickly, with push-button deployments. This not only increases the speed of deploying across different environments throughout your process, up until the final release to Production, but also allows for repeatability in a way manual deployments simply can’t. This is especially important when it comes to testing. Imagine if the framework of every update you deployed was identical – how much easier would that make testing? And how much easier would your tests be if they were all ran continuously and automatically? That is what ARA can offer.

Additionally, with consistency, your deployments are very predictable. You know what the run times will be, allowing you to plan your development processes more accurately and efficiently. This means you can allocate time and resources in a way that maximizes your output – which allows your team members to spend more time on their core competencies and improving your product, versus having to manage the deployment process or the infrastructure.

Along the same line, one of the key tenets of ARA is packaging. When you manually deploy updates, bits and pieces that comprise your application are being deployed (“moving”) at different times, creating a “noisy” process, with lots of dependencies, that’s difficult to manage. With ARA, everything is wrapped up in a tidy “package.” This effectively creates a “bill of materials” for your release and all dependencies and related configurations, which allows you to easily indicate what components of the application need to be deployed where, and in what order.

Application Release Automation also solves the issue of having such a critical process to the company be dependent on what is often just one person – a “star student” in your team who “holds the keys” to the project and only he has the tribal knowledge and expertise to perform or debug a deployment. With ARA, there is an implicit transparency to the project that gives any team member the ability to access the system and deploy the software (pending the right security permissions, of course).

Lastly, with ARA, you have complete visibility of the process from start to finish. If something goes awry, you have a much better view of where the error originated from, making recovering much faster and easier, and the damage much less significant.

Ultimately, a successful ARA strategy eliminates the need to build and maintain custom scripts for application deployments, while simultaneously reducing configuration errors and downtime. It allows strategic allocation of resources, giving users the most “bang for their buck” from their developers and other IT professionals. Because of all these factors, Application Release Automation is a hugely effective strategy for increasing both the quality and speed of your deployments.

About the Author/Anders Wallgren

Anders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings with him more than 15 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products. Anders holds a B.SC from MIT. Connect with Anders on LinkedIn or Twitter.

July 8, 2015
What is DevOps and Why Should CIOs Care?

Like the buzz-phrase: “cloud” or “big data”, DevOps is the new flavour of the month within the IT industry. You’ve probably heard of it by now – but many CIOs and heads of IT have not got to grips with what it is and are therefore reluctant to let developers take ownership and run their own operations.

A recent survey found that 23 per cent of respondents were not familiar with the term DevOps, and another 17 per cent thought it was all hype. DevOps is a method for improving the performance of the entire IT group. It is aimed at creating a better set of joined up IT outcomes for the business. As a methodology, DevOps allows all IT functions and activities, from cradle to grave, to be integrated into a seamless whole. It is an IT engineering philosophy and discipline that sees each part of the IT activity and value chain as being important to the delivery of IT products and services.

So why is it important? Well, DevOps is about culture, organisation, people, processes and tools. It helps directly address the historic silos that have existed between ‘development’ and ‘operations’. It also deals with the unhelpful and counter-productive behaviours that exist within different parts of the IT organisation that interfere with the smooth running of IT and impedes the delivery of high quality and cost-efficient products and services to the business.

DevOps provides a model for a more efficient and effective IT group; one that delivers more business value for less IT cost. By changing the way that different parts of the overall IT group operate together as a unified whole, DevOps improves the eventual outcomes for the business by making the ‘business of IT’ more efficient and more effective: “Better IT means better business”. Well-implemented DevOps initiatives will deliver rewards in terms of IT efficiency and quality improvements.

Whilst it can be a difficult sell to the business, the commercial benefits of a DevOps methodology applied to the ‘business of IT’ can bring significant improvements in productivity, consistency, flexibility and stability and must be championed by the CIO in order to get business buy in.

As promising as the DevOps movement is, especially for global organisations, some clear lessons have already emerged. Understanding these in advance could be the difference between success and failure for your DevOps initiative, and ultimately, your entire IT strategy. The alignment and collaboration of development and operations is key to a successful DevOps programme. Both groups must strive to achieve business agility through enabling change whilst preserving the stability of the existing IT infrastructure.

To achieve this the CIO must foster an environment where there is no longer two groups with opposing interests but one team that is pulling in the same direction and a culture where the individuals are cogniscent of each other’s responsibilities.

Get this right, and it will undoubtedly lead to better business.

About the Author

Paul Greer is Chief Software Architect at RedPixie. Paul works alongside the product and services teams to ensure products are high quality and enterprise ready. Paul also maintains a close relationship with RedPixie’s client base to ensure software services are delivered to a professional standard and exceed expectations. Prior to co-founding RedPixie, Paul spent 14 years in the financial services sector, holding technical leadership roles in business application development, innovation and architecture.

@paul_greer

November 18, 2014