devopsy.kinsta.cloud

Tag: innovation

  • How Visibility Helps Devs Focus on Innovation

    How Visibility Helps Devs Focus on Innovation

    As software engineering leaders adjust to a future defined by remote and hybrid work models, they are shifting priorities in the organization of work to compensate for the lack of in-person collaboration. According to a recent study conducted by Jellyfish, the top priority for engineering leaders is ensuring that each member of their team is focused on the highest-priority work for as much time as possible. To achieve this goal, these leaders are using real-time visibility and data-driven decision-making to guide more effective management.

    Earlier this year, Jellyfish analyzed the work of more than 23,000 engineers and surveyed hundreds of leaders to better understand the current state of engineering management. The research revealed that engineering leaders are shifting resources away from reactive work—such as responding to customer-reported bugs—to the type of work that directly impacts top-line revenue. Additionally, engineering teams are emphasizing growth and innovation, developing the type of infrastructure that will enable their teams and their software to scale long-term.

    Prioritizing Visibility

    To shift from reactive to proactive work, engineering leaders must first have visibility into what their teams are doing. How can you allocate your time and resources more effectively if you don’t know how they’re being allocated today? Before work can be prioritized effectively, leaders must understand how much bandwidth their teams have to take on new projects. Additionally, they need data-backed insights in order to align the priorities of the engineering team with those of the company at large.

    Visibility is also key to avoiding work that wasn’t part of the plan. According to the study, teams spent 22% of their time on unplanned work in 2021, a 15% increase year-over-year. This trend indicates that engineering leaders may not realize when certain types of work are taking attention away from mission-critical initiatives. When asked to name their biggest challenge heading into 2022, 45% of leaders (by far the largest group) selected “making sure everyone is focused on the highest priority work.”

    To gain visibility into their operations, some engineering teams are doubling down on data aggregation and analysis. According to the report, while all organizations tend to devote similar amounts of time to “keeping the lights on” and customer support activities, those that invest in a more robust data organization are able to spend 29% more time on innovation and 48% less time on unplanned work.

    Building Through Data and Metrics

    The report also found that engineering leaders who’ve embraced data-driven decision-making are seeing more productive, healthy and focused teams. These organizations tend to release code more quickly and foster higher collaboration than their peers. Conversely, organizations that don’t prioritize data-driven decision-making are more likely to experience burnout, decreased productivity and less focus on innovative work.

     

    Here again, the difference between embracing data and ignoring data comes down to technology. Aggregating data and metrics manually can be tedious and challenging. However, emerging tools are able to automatically collect, measure and analyze data to offer insights on what teams are prioritizing. As a result, leaders can more easily align engineering work with business priorities, ensure more predictable development cycles, increase financial responsibility and continuously improve operations.

    For every engineering leader, nailing this approach to data will be essential for maintaining efficiency as teams expand. More than 79% of engineering leaders expect to grow the size of their teams in 2022, and respondents named employee onboarding ramp time, virtual onboarding and hiring among the most significant challenges they face.

    Despite the numerous challenges engineering teams have endured in the past two years, the industry has adapted and become more collaborative as remote and hybrid work models multiply. For leaders who seek to increase data-driven decision-making, new tools and approaches will result in more intentional engineering work and improved visibility and operations.

  • Rethinking Business Models for Digital Transformation

    Rethinking Business Models for Digital Transformation

    To keep pace with the swiftly changing digital ecosystem, organizations can’t afford to stand still. It’s vital for organizations to continually assess their business models as part of their digital transformation. Organizations must walk a difficult line between maintaining their core competencies while successfully anticipating what is ahead.

    The oft-cited Silicon Valley startup mantra of “fail fast and fail often” may not apply across the board. Still, when it comes to examining the digital future, an intelligent business model incorporates the fact that you may not get it right the first time.

    Innovation fueled by data is the way forward.

    4 Elements of Innovation

    Any business model has four elements:

    • Customer value — how does your model support the customer’s goals?
    • Profit formula — How does your model demonstrate value
    • Key resources
    • Key processes — Resources and processes describe your model’s systems to support your customer value proposition.

    Of course, these elements are interconnected. As an organization shifts during a digital transformation, these four elements will stretch, evolve and reorder. However, customer value should remain at the top of the list. The customer value proposition is more important during your digital transformation.

    Why?

    Because the digital world has given the consumer more choices than ever. If the user doesn’t like your site’s options, it only takes a click to get to your competitor’s site. This seems obvious, but in reality, many businesses don’t consider how easy it is for customers to become ex-customers. In this new era, brand loyalty does not mean as much as price, website experience, quality and other factors.

    This means putting your customers first. It also means avoiding falling into the trap that all you need to do is put your processes and products online. We’ll discuss why in the next section.

    Digital: Not the Answer By Itself

    Many companies, however, behave as if going digital is the answer. On the contrary, going digital is only the first step in the process. The reward comes when a company leverages digital business practices to enhance their customer’s experiences.

    This also requires encouraging innovation in the organization. The most cutting-edge digital business model will provide little benefit to a company that fails to develop the tools, talent and culture to support it. Many well-meaning organizations talk the talk about digital innovation but then are unable to follow through for whatever reason.

    It is easy to discuss the necessary changes; however, altering the business model is challenging for an established company. An organization must understand what makes its present model successful or unsuccessful. This involves analyzing each element separately and as a unit.

    Next, study the marketplace to identify any signs and data that suggest your model needs to change. These include large customer segments whose needs aren’t being met, a customer goal that’s gone unrecognized, a new technology whose capabilities aren’t being fully leveraged, a challenge from existing or emerging competitors and the marketplace redefining your target market or your core solution.

    Any of these signs may be enough to dictate a change in your business model. However, the next step is to evaluate your model’s digital business components, including the content, the platform and the user experience.

    Content describes the product you are offering the customer over your digital platform. It could be content that matches your physical content. Or it could be uniquely digital content, such as streaming video.

    Part of this assessment is finding out how much revenue your existing content generates. This may be difficult to precisely quantify, as some content may be necessary or brand-building?

    Platform describes how you deliver your content (website, a network, streaming, or other channels). How good are your internal platforms? How can you expose more of them to customers to improve their experience?

    The user experience describes how the customer accesses your content over your platform. How good is your customer’s experience? Who provides a better one and how does it differ from yours? These questions help you evaluate the value being created by the digital business components of your model.

    Evolution

    Evolution rather than revolution is often enough if done thoughtfully and strategically. Small changes in a business model can yield significant results. Merely updating the assumptions of your value proposition can open up fresh business avenues to pursue. It is crucial to rethink the economic model behind your products and services as you’re reviewing your business model.

    Are you identifying and capitalizing on the actual value you provide your customers? Pinpoint the customer value you generate and trace it back through your processes, identifying your economic model’s components as you do. Then, flip it. Start with your processes and trace a path from them to the customer.

    By carefully analyzing what you have, who wants it, and what it’s worth, you may open up new revenue streams. The digital marketplace can also be challenging to navigate legally and organizations should involve legal teams to survey the regulatory landscape before committing too many resources.

    Ultimately, successful businesses increasingly depend on a deep understanding of online behaviors, internet-based network effects and the distinctive forms of business modeling that apply in the digital space. Organizations must foster a culture that embraces change, isn’t afraid to take calculated risks and has the appetite for learning new approaches and technologies continuously.

  • DevOps: Driving Innovation With Old Habits

    DevOps: Driving Innovation With Old Habits

    DevOps can help drive cost-efficiency, greater productivity and innovation

    When software development and IT operations merge and work in a state of harmony, they create a flow that we call continuous product delivery. Ideal for project managers, this flow is the elixir to innovation and enables the agility needed to respond to changing market requirements. It also creates currents of speed, proactiveness and integration within enterprises. However, asynchronous code updates, inadequate IT infrastructure, siloed functioning and inefficient processes can hinder this flow.

    In 2009, Patrick Debois and Andrew Clay Shafer devised a framework to break such barriers and coined it “DevOps.” Over the last decade, DevOps has garnered many followers and fans, including myself. Product managers worldwide rely on DevOps to enhance performance, accelerate time to market and innovate with agility. DevOps is more critical today than ever before—when nature mandates a new order of remote working, product managers must rely on DevOps to catalyze innovation and sustain continuous product deployments and updates.

    Yet, not all enterprises that have adopted DevOps have unearthed innovation like that of Dyson, which created a new type of ventilator in a mere 10 days to help the UK government scale COVID-19 treatments. Nor have they been able to match the frontrunners of innovation such as Google and Amazon that can deploy code thousands of times per day, compared to low performers that deploy code only about four times per day. The obvious question on everyone’s mind is, “What are these heroic innovators doing differently with DevOps?”

    Driving Success Through DevOps

    While business executives are aware that implementing DevOps drives business innovation, most are not aware of the old habits that remain, causing unnecessary hiccups within the application cycle and business transformation. As the way forward, organizations must tweak their approach to DevOps to be able to reap more significant benefits of business innovation. They must:

    Ensure speed does not outpace stability

    Today’s digital-first world has swept through every enterprise. However, to keep up with the rapid dynamics of the digital tide, enterprises need to weed out monolithic architectures and manual processes to turbocharge software development and deployment. Automating the deployment process with the help of microservices and cloud can help enterprises gain speed in software deployments and swim the tide of customer experiences. Speaking from experience, this is a privilege that has allowed me to witness how DevOps practices have enabled enterprises to crunch deployment times from weeks and days to just a few minutes. Needless to say, innovation depends on speed: The faster an enterprise deploys a novel solution, the higher its chance to claim the prize of innovation.

    A word of caution here: Many enterprises that have neglected quality and stability while accelerating speed drown in a vortex of defects often. When pushing out a product or an application 30 times faster than the traditional model, enterprises must consider its stability, too. Cloud infrastructure plays a vital role in helping enterprises achieve both stability and speed. On-demand self-service, networks that cater to multiple devices, high scalability and analytics are some of the primary advantages that enable enterprises to deploy faster without impacting the core.

    Losing stability for the sake of speed can cause organizations to regress instead of leaping forward. In recent times, British Airways has been in the news for repeated issues in its IT infrastructure’s stability. It has had to cancel several flights and inconvenience passengers because software upgrades and incidents have caused its infrastructure to fail. Enterprises must consider these four metrics—lead time for changes, deployment frequency, time to restore service and change failure rate—to receive the value of their DevOps investment.

    Make security equal to agility

    The pandemic-driven remote working has seen the video communication solutions provider Zoom soar to 300 million active monthly users last month. The brand showed great agility in meeting the surge in demand but became vulnerable to cyberattacks—500,000 Zoom passwords were available for sale in the dark web’s crime forums last month. This is an excellent example of how security is usually an afterthought when compared to agility; not prioritizing security in the DevOps cycle can place teams and their organizations at significant risk, creating vulnerabilities and exposing organizations to bad actors.

    In my experience, putting security checks in place early in the DevOps process can help enterprises shift left more effectively. As a first step, security and development teams need to communicate better through the continuous delivery flow. Security teams need to play more proactive roles in foreseeing risks in innovative solutions and routine software updates. Leaving security for the last will only force organizations to be reactive versus proactive.

    Build collaboration, not silos

    Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations due to issues around organizational learning and change. DevOps is a process that provides tools but it is also a philosophy that promotes collaboration among teams in software development. It catalyzes an ecosystem that encourages high collaboration and information-sharing. In a DevOps culture, failure is not shot down but leads to inquiry that drives solutions. Seamless information flow is the critical outcome of a DevOps-driven organization. Proper information flow is timely, answers questions and is understandable while needing the support of tools and technologies to drive success.

    The General Motors Freemont Assembly line has been a great case study of how poor workforce culture can cause an enterprise to shut down. As one of the largest automobile factories in the United States, the manufacturer had to shut shop in 1982 due to rising losses attributed to an unruly workforce that was protected by a strong union. Within the next two years, the same factory was re-opened in collaboration with Toyota Motors, and it was called NUMMI.

    NUMMI hired up to 85% of the old workforce of GM’s Freemont assembly. The difference was the Toyota culture–one that focused on learning and improvement and set a framework of how leadership interacted with and inspired teams. This change was fundamental in driving success for NUMMI, which reduced the time to manufacture a car to 20.8 hours in 1986—a drastic improvement over 43.1 hours in 1978.

    At a time when we are witnessing unprecedented disruptions to supply chains, manufacturing and employment, enterprises need to deep dive into functioning to explore new opportunities for cost-efficiency, greater productivity and innovation. DevOps can help achieve these and build the foundations for continuous innovation. Investments in automation, cloud and culture will help enterprises realize the continuous flow of product delivery and innovation. The wave of innovation in the new normal will be propelled by the forces of time-tested practices and new next-generation approaches to enable enterprises to shift-left.

  • Harnessing the Power of Developers

    Harnessing the Power of Developers

    In our fast-moving digital economy, organizations across just about every industry are faced with a stark reality: to remain competitive and deliver the best possible customer experience, they must evolve continuously. The fintech industry is a great example of this–the sector’s growth and focus on excellent customer experience has been driven by external developers rather than incumbent players.

    For many companies, particularly in the service industry, improving customer experience now means developing new apps and services that will maximize the customer journey, engender deeper trust and secure customer relationships for the future.

    The aim is to continuously produce innovations that create delightful customer experiences, which in turn will drive ROI. In its 2019 Technology Industry Outlook, Deloitte highlighted the fact that the “democratization of innovation” is set to be a key strategic factor in the coming years. As cloud infrastructure makes it easier to innovate at speed, “medium and small enterprises can harness powerful capabilities once limited to a select few.”

    That might be a new SaaS application, for example, or the implementation of emerging tech such as AI or VR–anything that helps the company provide a more efficient or accurate customer service. A simple example could be integrating complementary, adjacent solutions to add additional value to end customers.

    Companies need to innovate in order to create unexpected functions and capabilities that will delight. But how do companies go about making that a reality? In a nutshell, there are two groups that can help you innovate: your own developers and the wider developer community. Having the right people involved and the right programs in place for both of these channels will allow you to scale and deepen your innovation more effectively–and ultimately create experiences that your customers cannot live without.

    The more you engage with developers inside and outside your organization, the faster you can accelerate your time-to-market for new innovations and, crucially, ensure that those innovations meet real customer needs.

    In-House Developers

    Building an effective in-house development team to meet customer needs is about more than just hiring the right computer skills. Companies need to aim for a fearless, fail-fast culture that lets teams go above and beyond in answering customer needs. This need not apply to all developers–there will be some focused on refining the core product set, for whom fail-fast may not be the ideal working model. However, in the pursuit of unexpected offerings that will delight customers, a healthy attitude to both fail-fast and conventional development is essential.

    Often, organizations are held back from being the best they can be by ingrained, deep-rooted cultures. The power of “the way we do things ‘round here” can be hard to crack, but good leaders must help staff buy into change as an ongoing process that will help them and the business to succeed in the long run.

    That’s where the concept of experimentation and fail fast comes into play. In these environments, developer teams are given permission to try things out without having to go through multiple rounds of approvals and senior buy-in. That means they can go from an initial idea to a fully testable concept in, say, weeks rather than months or years. It also means they can run their blue-sky ideas through a crash course of reality, bumping up against unforeseen problems–what some people might consider failures, but I think of more as learnings–without being penalized for it.

    When developers are given this permission to get ideas off the ground quickly, the benefits to the organization are obvious. Improved access to innovation; a greater chance of discovering more effective ways of working; and a supportive, forward-looking culture that helps to enthuse non-technical staff as much as developers themselves. The same is true for customers–they will benefit from innovations that improve their experience, surprising and delighting them with the idea they didn’t know they needed, but which exactly addresses their needs.

    Practical Considerations

    There are other key issues to address, particularly senior buy-in and customer-centricity. First, it’s essential that developers know their work is valued by senior leadership. Senior leaders need to trust their experts and not just allow but also champion the fail-fast model if the company is to benefit from the successful innovations that come out of it.

    Second, developers need to work in close communication with customer-facing teams to ensure their efforts are directed toward innovations that will translate into improved customer experiences. In other words, it’s important developer teams innovate with the company’s core goals in mind–not just for the sake of it, however tempting that might be.

    There are also pragmatic issues to be addressed, such as ensuring your APIs or SDKs are well developed, and there are good documentation/guides to help use these APIs. This is required for both in-house and external developers.

    External Developer Networks

    Having a wide network of development partners can also help rapidly scale innovation and deliver solutions that exceed customer expectations with speed. By building a community of great minds around the mutual benefit of market-ready innovation, organizations can unlock far more valuable projects, with positive effects for them, their customers and their partners.

    An effective developer partnership works on the basis that there is a symbiotic relationship where each side has something to offer to the other. For example, the developer partner may come from a smaller company who has specific expertise and can benefit from the financial support and expertise of the larger organizations. While both sized organizations can benefit from the diverse thinking, agility and challenger mindset of the developer partnership. Whether you’re a large company looking to fast-track customer-centric innovation or a small company with a great customer-centric idea that needs a boost onto the next rung, a healthy developer network can be highly beneficial.

    As an example, the accounting industry is currently undergoing a major cultural change, with accountants increasingly seeking to provide customers with value-add strategic services to maintain their competitive advantage. Technology is driving a consultancy-first service model. Accountants have access to more data than ever before, and as a result they can help clients to make effective business decisions based on new analytical insights.

    However, making the jump to effective consultancy requires new tools and innovations to turn raw information into usable insights. By working in partnership with a network of cutting-edge developers, accounting software providers can help to conceive, road-test and launch user-friendly solutions.

    The value of developer networks is also evident as you look at domain specific needs that might span a particular industry or a particular region. One company may not have the expertise or bandwidth to do it all–but by building effective communities of developers, an organization can expand their reach to tap into niche areas of expertise. It also gives the company the ability to deliver innovations more rapidly. Every company has a limited set of resources, and additional developer networks can help scale this innovation. For the developers, the value lies in reaching markets and customers they may not previously had access to.

    Taking Innovation Out of the Lab and into the Market

    Whether your company uses in-house developers or a partner network (or both) the core goal should be to hone ideas into realities through collaborative working practices. When developers and customer-facing teams understand one another, they can achieve great things.

    It’s an exciting time in the industry. Technology is evolving faster every day, solving more problems and opening up new possibilities. For businesses of all varieties, harnessing the power of developers should be a core priority. It’s not a question of pursuing innovation for the sake of it–it’s about taking practical steps to ensure you maximize the positive impact of tech on your customer experience.

    — Shivani Govil

  • Digital Transformation: Thrive, Not Just Survive

    Digital Transformation: Thrive, Not Just Survive

    My conversations about innovation and the enterprise have afforded me an intimate understanding of the technological challenges companies are facing. Chief among these concerns, regardless of industry or sector, is digital transformation.

    Just the other day, a C-level financial executive came to me seeking guidance on this topic. He said his company was on a mission to become a lean, mean, digital machine, and was currently leading four or five initiatives to modernize operations and convert systems from legacy to new. “We’re moving everything to the cloud, we’re building new apps, and our teams are working toward agile methodologies,” he said, “I’m proud of my teams for all the hard work they’ve put in—in fact, they’re worn out from all their efforts! But honestly, I feel like all this work hasn’t paid off. We’re not seeing the dramatic progress that was promised. What are we doing wrong?”

    He’s not alone in his frustration. I’ve seen many organizations get excited about these kinds of changes, high on the notion that once they’ve knocked out a few initiatives, they will have conquered digital transformation and secured the future of their business through technological fortification. But I reminded him not to get too distracted by all of the technology jibber-jabber, and instead make sure to keep the big picture in mind: Digital transformation is, first and foremost, a fundamental shift in your business model.

    It isn’t simply about switching from outdated technologies to newer, slicker solutions. It’s not about transitioning to the cloud or performing a complete upheaval of legacy systems or processes. And it definitely can’t be accomplished in a few steps or one fell swoop. In reality, digital transformation is a journey that requires a road map and strategic planning to ensure all of your initiatives support the greater movement toward agile, streamlined and more efficient, and directly address and impact your business needs and objectives.

    To this end, I posed a critical scenario to this financial executive: Consider an industry competitor who is smaller, newer, more agile and less bound by the market. If this player were to become super successful, how would your company respond? And which parts of your business specifically would be responsive? His reply was that his company is adopting ideas from new-entry players, primarily online-only banks. He’s building a new mobile platform and revamping his web properties to make banking more efficient for his customers.

    While these efforts certainly have value and no doubt will improve how he does business, it’s not enough to constitute a digital transformation. These changes won’t be enough to drive the fundamental shift that needs to happen. It’s more of a blended approach, which won’t be enough. Hybrid models can allow companies to survive—but not thrive.

    We can draw similarities to the evolution of automotive technology. While internal combustion engine (ICE) cars have long dominated the market, about a decade ago electric vehicles gained real popularity as a superior alternative. However, there have been real obstacles in the way of pure electric vehicles going mainstream. For one thing, we have so much invested in the infrastructure to support ICE cars and very little in the way of making electric cars practical. While charging stations are expanding and becoming more common, we don’t have nearly enough to make pure electric travel the practical choice—for now.

    What has been our interim solution? Hybrid vehicles. In response to the electric contender, we’ve developed a number of vehicles that bridge the divide between infrastructure and efficiency needs. We created ICE-electric hybrids to harness the beauty of electric without having to sacrifice on practicality as the infrastructure works to catch up.

    So this is what our financial executive is actually doing: he’s going the hybrid route by borrowing some of the nice, fancy features from the new entry companies while keeping an entire foot of his company in the traditional ICE world. And though the hybrid movement has been serving us reasonably well with cars, it’s not a good approach when it comes to a technology strategy. In the world of enterprise tech, bi-modal IT is like a hybrid vehicle. Sure, it allows companies to say, “We’re getting more electric!” But if they make the mistake of designating a hybrid operating model as their end goal, they’ll be stuck with split IT personalities and bifurcated cultures.

    Organizations can get by on a hybrid approach, but only for so long. They may be able to modernize in part and reap some of the benefits of better technology, but it just gets too expensive to be sustainable. Hybrid necessitates investing in both types of infrastructure—legacy and new, gas stations and charging stations—to keep services running. In the long run, this holds companies back from truly taking advantage of all the benefits of electric, and they need to build transition technologies between ICE and electric components to make them run as smoothly and efficiently as possible.

    “Okay, so hybrid’s not the way to go. What do I do instead?” the financial executive asked. My answer is to create a space expressly for innovation. You should compile whatever resources you can to create an entirely independent division of your company (or even a separate company) that makes room for innovation. This arm would be free from the constraints of legacy systems, free to ignore the norms of its parent, and free to create its own rules and business model. Using our example from the automotive industry, you can think of it as akin to General Motors creating an entire, standalone electric division, rather than simply converting Chevy models into electric versions.

    While your organization may be in survival mode in the near term, you can’t lose sight of the pure electric play. Think about the inevitability of the electric car age: Battery prices will continue to plummet, driving ranges will increase, charging stations will multiply and the auto industry itself is investing in both EV and air pollution standards. We’re not putting all of our money on oil anymore.

    So as you move forward on your digital transformation journey, be mindful of your true end goal: to have your business thrive through this technology cycle and the next (and hopefully the one after that, too). Going hybrid is a necessarily survival mechanism, but only as long as it builds momentum and helps drive you toward success.

    About the Author / Abbas Haider Ali

    Abbas Haider Ali brings over 16 years of experience in networking, cloud services, software, and cloud communications. As CTO of xMatters, he is responsible for evangelizing the adoption of communications-enabled business processes, and has worked closely with more than 400 global enterprises and IT organizations to create a vision for adopting intelligent communication strategies across business scenarios. Abbas holds a BASc in Computer Engineering from the University of Toronto.

  • IT Leadership Still Struggles to Satisfy the Business, Deliver Innovation

    IT Leadership Still Struggles to Satisfy the Business, Deliver Innovation

    If a recently published report by Salesforce is to be believed, the rest of IT leadership is starting to catch up with what IT leaders have long known: Business technology needs to be customer experience-driven. This year’s report, Salesforce’s second annual broad look at the state of enterprise IT found that the line continues to blur between business leadership and IT leadership, driving innovation is the imperative, and IT is focused more than ever on providing business value.

    According to the “2017 State of IT Research” report, based on a survey of about 2,200 technology leaders worldwide, 71 percent of organizations reported they are shifting efforts from technology being a cost center to becoming a “value-based service brokerage over the next 12 to 18 months.”

    “Instead of being viewed as a cost center, IT is emerging as a value-based service brokerage,” the report states. “The old model of IT as a maintainer of the status quo infrastructure is giving way to a new mindset, in which IT adds innovative capabilities that bring a competitive edge to the business. Seventy-four percent of IT leaders say the business teams they partner with believe IT is the biggest driver of business success.”

    How are IT teams gauging their success? They’re measuring success based on satisfaction scores. A sizable 74 percent of IT leaders said that such business satisfaction scores are a leading key performance indicator, IT teams are only delivering on 56 percent of their customer-facing initiatives. With such less-than-flattering results, it’s no surprise that 67 percent of IT teams said that improving their collaboration with other lines of business is a high priority—second only to improving security policies and practices in priorities.

    This inability of some enterprises to execute on business initiatives couldn’t come at a worse time, as every company is tasked with becoming as agile and competitive as possible during a time of critical business disruption. According to the survey, Top IT teams are three and a half times more likely than underperforming teams to say it’s a critical priority to innovate for industry disruption.

    It’s important to note that Salesforce didn’t quantify the performance of the enterprise teams surveyed; instead, the respondents self-identified as underperformers, moderate performers or high performers against their competition.

    One of the biggest challenges IT has when it comes to innovating is the sheer amount of time they must spend keeping up on the basics, such as infrastructure. “Even with all the talk of prioritizing innovation, IT leaders still spend more time on tasks that keep the lights on (54 percent of their time, on average). A majority of IT leaders are moving to automate routine tasks so their teams have more time to innovate,” Salesforce wrote.

    According to the survey, about half, 52 percent, said that legacy technologies are a challenge to meeting strategic objectives.

    Finally, moving at speed remains a challenge as well. “Sixty-seven percent of IT leaders say improving the speed of development cycles is a high priority. And while speed is an important success metric, it’s also a top challenge. To improve, IT leaders are exploring options such as low-code solutions and citizen development. Some concerns—namely, security and insufficient governance or training—still hold IT teams back from putting business users into the driver’s seat,” Salesforce wrote.

    Where do they stand now? Just under half, at 47 percent, can deploy an app in under a month. Based on my reporting that’s quite an improvement in deployment time from just a year ago, and I think what we are seeing here are the fruits from agile, DevOps, continuous delivery, and low-code development platforms. And the half of enterprises that can’t deliver at speed are going to find themselves deeper and deeper down a competitive hole.

    — George V. Hulme

  • Lessons Learned: We’re Still Killing Ourselves with Innovation

    Lessons Learned: We’re Still Killing Ourselves with Innovation

    Since the widespread acceptance of virtual machines (VMs), we’ve been on a racetrack with changing technology, with little opportunity to stop and digest lessons learned. That’s not to say organizations haven’t done a good job of learning from experience and mistakes both; rather, the lessons learned are too frequently obsoleted by The Next Big Thing.

    While I have an abiding interest in several areas of DevOps, we’ll focus on one I’ve spent a lot of time around recently: provisioning.

    All Roads Lead to Rome

    Road signs for Rome
    Image Credit: Melanie Bateman via Flicker

    At this point in time, you can provision to VMs, “the cloud” (note that from an automated provisioning perspective this is anything but homogeneous, but the fiction helps here for a moment), containers, clusters and clustered container managers. While all end up giving you a working machine that has IP access, how each goes about it is different.

    That is a problem for automation, unless a company goes all-in on one of the above. Containers were going to save us from custom configurations based upon target—and largely have—but in DevOps they still leave us with an underlying deployment infrastructure that must handle where that container will land. The infrastructure doesn’t define itself, unless we teach it to, and that is still very much tied to the target. Anyone who has used both AWS and Azure knows that even two cloud environments can look very different to get up and running with automation.

    Server deployment tools are steadily growing their capabilities and are adopting the ability to spin up cloud instances alongside their ability to handle hardware/VMs. That’s a good thing, but it’s still relatively new.

    The thing is, we in DevOps are trying to do the exact same thing in every case: get a server configured far enough that our application provisioning tool (Puppet, Chef, Salt, whatever) can pick it up and get the server populated with our applications. One goal, many paths, and it is a rare organization these days that is taking only one of those paths.

    Plan Ahead, Forge Ahead

    The rate of change is not showing signs of slowing down—the re-emergence of clustering software in the light of containers is proof of that. I’m stoked about the idea of clustering, simply because it can take a layer out of an increasingly complex environment, but it changes the way we deploy yet again, offering new software, configurations and APIs.

    The defense mechanism I recommend is to look at what is available, consider how it does or will fit into your architecture and plan for it. DevOps is the area of IT most affected by these changes, so that’s where the planning should take place. But like all topics DevOps, this requires a lot of communication with Dev and stakeholders to make certain the platforms being considered are the ones that will best serve the needs of the company. But supporting all of the possible deployment mechanisms in a DevOps environment means investment in scripting and apps that do the same job for different targets. While that may be doable today if you are blessed with tons of DevOps man-hours, I cannot say often enough that it is building technical debt. Each of those different deployment mechanisms will need to be maintained moving forward, and while the idea of DevOps is always relatively simple, it has been my experience that the reality means some pretty complex code/script feats are necessary to make it work successfully and reliably.

    So build a list of platforms you aim to support, start working toward that list, then revisit in six months or so to make sure nothing has changed. Considering that the needs of most organizations change continually in light of technical advances, and the markets are changing from those same technical advances, six months is a good timeline for revisiting. Any longer than that and you may find yourself with a list of things to support that isn’t accurate and misguides DevOps automation efforts; any sooner than that and you will find you are shifting priorities too frequently to adequately support large installations.

    It’s About the Business

    In the end, for the vast majority of IT, the goal is simply to support the business in an efficient and secure manner. Find out what your organization needs and then go out and make it work. Our industry is lucky enough to have a metric ton of smart people, so making it work is not the issue; pinning down the goals is.

    And keep rocking it. For every error, there are a bazillion successes we don’t jump up and down celebrating, so do the same with those errors. Learn the lessons and move along. Pretty soon you’ll have fully automated deployment on the newer platforms most-suited to the organization, serving up the apps the organization needs.

    — Don Macvittie

  • DevOps: Commoditizing Infrastructure

    DevOps: Commoditizing Infrastructure

    Hardware vendors face a quandary. How do you distinguish yourself as superior from your competitors if you are unable to continue to grow a distinct architecture as your competitive advantage? But this dilemma does not begin and end with only hardware vendors; operating system vendors and virtual machine vendors are on the same horizon. In an effort to “uncomplicate” hardware idiosyncrasies, our industry evolves efforts from open standards to least-common-denominator functionality for a “common” language or set of features, and over time technologies such as containers emerge. If I can abstract my application from the “uniqueness” of hardware vendors, from the complexity of configuration settings, and make only assumptions about basics such as CPU, disk, memory, etc., then I am free to focus on the application and allow my “hardware mitigation technology” to perform its function.

    The Relationship Between App and Storage

    But to accomplish this feat, I must agree to a basic set of features or functions I intend to call, such as making “x” amount of machine memory available to my application. Whether disk or RAM, I am looking to define what my application needs and then expect the container (or hardware mitigation/abstraction manager of my choice) to manage the actual allocation. Then the quandary begins. Asking for 1TB of disk space as an example is generic enough. But does my request include the ability to specify I am looking only for disks that spin at more than 7,500 revolutions per minute, or will I be saddled with 5,000 rpm disks? There is a clear implication in speed for my app.

    Ultimately, as I sit and tune my code because my app has become “slow,” it could be something as innocuous as having its actual execution occurring in a cloud provider who uses the slower disk revolutions as opposed to the faster ones. Worse, it simply could be that the same cloud provider has a batch of the slower ones in one of its data centers where I wind up executing (only on a temporary basis), and I am never fully able to figure out why my app got “slow” for a while. That kind of random bad ju-ju requires the execution of a chicken to fix (I prefer Popeye’s, myself).

    Different storage vendors might have additional peculiarities that make one or the other superior in speed, reliability or performance over their respective competitors. But the container’s main functionality is to provide “disk” to my app. Specifications of specific disk vendors or providers are the problem of the cloud provider, not the app developer, in theory. But hardware refresh can be pricey, and to make a claim that “all our disks” have rpm specifications above 10,000 will be meaningful only for about 10 minutes when the 12,000 rpm models come out. And of course, there are many more architectural designs in the engineering that are intended to boost speed and reliability. If these are not to be ignored, a decision must be made as to “who” has the responsibility to manage their usage (usually the cloud provider), and “who” will complain when things get slow (usually you the customer).

    And what happens when “breakthroughs” occur in a specific technology? Solid-state hard drives, for example, are not exactly new now, but they once were. When you move your app from operating on a high-speed hard drive that spins to a chip-based hard drive the operates at the speed of the RAM it is based on, the difference in speed is an order of magnitude better. The inevitable question emerges, Will my container have the ability to specify RAM-based disks instead of traditional spinning disks, as part of the disk commodity it is providing to my app?

    Since the difference in speed is so great, you would think it would come up with a way. You would equally expect that providing offline storage such as tape (from the age of the dinosaur) would have its own designation in my container structure (not be equated with offline spinning drives due to the speed differential). When you go to make a backup or restore, the difference between tape and hard drive becomes as apparent as the difference between solid-state and spinning drives on app execution. So when a platform evolves, my container mitigation must evolve with it. But to offer the uniqueness of vendor superiority requires my programmers to learn who to request (or what level of hardware specs they must know), which is the whole point of wanting a commodity in the first place: I don’t have to know.

    Impact of Commodity on Other Components

    This same dilemma can be exhibited in CPU vendors. Intel touts its superiority, AMD would disagree, and there may always be an upstart who wants to rival the current leader in any space. Lest we think Intel-based computing is the undisputed champion, quantum computing may upset that assumption (unless, of course, Intel corners that market as well). The point here is simply to ask: how many features, how many specifications, how much do we the programming team need to know about our platform provider to understand why and where our application runs better and worse? In the days before container-style ideology, hardware vendors touted their differences and their uniqueness as the reason they were better. Now what?

    Then comes our virtual machine providers, and eventually our operating systems. If I want to truly abstract from my hardware layer, I must not call an OS-unique command that only Linux or only Windows can do. I must stick to functionality that both OS instances can reasonably understand and accommodate. While this least common denominator is great for extending where my app can run (on multiple types of hardware, in multiple types of OS installations), it has the same effect on uniqueness and potentially on competitive advantage. If the intent is to come up with a one-world OS, I am generally in favor, but our journey there is sure to have certain casualties in innovation that a single OS is suited for and its competitors are not.

    The inevitable question becomes, How far down, or how far up, do we want to form commodity provisioning of computing capabilities? One could argue that the simplicity of the iPhone platform is a user-centric expression of commodity provisioning at the top of the stack. Drag-and-drop programming languages are yet another expression of bucketing computing capabilities into more simplistic expressions (that more people can understand and, therefore, utilize). Commonality and simplicity do increase audience. In many segments of our industry, this is the nirvana of sales to the public.

    Impacts to the Bottom Line

    DevOps focuses on enabling innovation. At its core DevOps is focused on software innovation. Let’s face it—changes to hardware platforms are generally less frequent. If those hardware platforms are married to a particular app (not serving a large number of apps on the same box, same virtual instance, etc.) then at least provisioning can be tuned one to one with the app. But with the desire to turn infrastructure into a generic commodity that application programmers don’t have to think about comes the fact that they stop thinking about them. Over time they will understand less and less about why things become slow, or work better, as the knowledge of uniqueness goes away.

    Depending on your market focus, ubiquity is either your friend (as it touches consumers) or your enemy (if you are the hardware vendor attempting to maintain relevance over your competitors in an increasingly commoditized market). The questions I raise in this article are designed to focus on how to keep our trend toward hardware mitigation from stifling innovation in the very hardware platforms we depend upon. In any case, I welcome your thoughts on the topic.

    To continue the conversation, feel free to contact me.

  • Preserving Bottom-Up Innovation in DevOps

    Preserving Bottom-Up Innovation in DevOps

    Balancing top-down control and oversight with bottom-up innovation and autonomy

    The driving force behind DevOps adoption in the enterprise is the idea that it will enable faster and more frequent delivery of better quality software. If all goes well, DevOps should result in higher customer satisfaction and lower costs, but the journey to get there can be challenging. Unfortunately, only a minority of organizations that attempt to implement DevOps actually fully deploy it.

    There are many barriers to overcome before organizations can realize the benefits of DevOps. One of the main challenges is retaining sufficient top-down control and oversight without hampering bottom-up innovation. 

    From Start-Up to Enterprise

    The root of this problem lies in the fact that many ideas in DevOps were developed in environments with small teams and flexible organizational structures. In such setups, where everyone can see what everyone else is doing, visibility and control seldom are an issue. Adapting this approach to an organization with hundreds of geographically distributed teams, in industries with a lot of regulatory baggage and diverse legacy systems, is an entirely different prospect.

    How do enterprise organizations find a structure that enables individual teams to unleash their innovation and maintain a feeling of responsibility without losing oversight and control? If DevOps teams are not empowered to make their own decisions and free to move swiftly, then they’ll struggle to realize the benefits that drive adoption in the first place. 

    Walking the Tightrope

    Individual DevOps teams should be free to make local decisions, but these need to be in alignment with business goals at the management level.

    You don’t want to hamper the speed and reliability that automation brings, or the innovation that can come from autonomous decision-making, so you need to find a way to balance tools, processes and team structure to maintain control and visibility. Avoid flying under the radar; instead, aim for maximum transparency in what your DevOps teams are doing. Set goals and measure, because visibility for management will prove that the new approach is working, build confidence and secure more top-down investment.

    Connecting the Dots

    A large enterprise will have a number of DevOps teams, but they shouldn’t be completely isolated. Requirements such as audit trails, security access logs and compliance controls must be met by all of these teams. There’s little sense in making each individual team responsible for solving the same problems over and over again. Offer a set of standards and tools, but be careful not to shut down choice.

    That same logic applies to competence development, so offer your DevOps teams access to best practices and enable them to learn from each other. The size and structure of an enterprise organization does present unique challenges to DevOps adoption, but there’s also opportunity here to benefit from the scale by sharing and collaborating. Sharing and standardizing the right things will eradicate redundancies and free your DevOps teams to focus on improving their products and innovating, so the business derives maximum value from their efforts. 

    Finding What Works

    The right answer will be different for each organization, but there are some things everyone should keep in mind when building or shopping for tooling. It needs to support a large, diverse environment. Look for support for the platforms you use and consider extensibility, so you can add the functionality you need.

    A key factor here for orchestration tools—especially those that define and execute your delivery pipelines—is that they must be accessible for management. You shouldn’t need to be a technical expert to dip in and get an overview, or compile a report that provides the insight you need. Ensure you collect diverse metrics and present information in a digestible format so you can find bottlenecks and identify successes and failures and really deliver the best experience possible for the end user.

    About the Author / Andrew Phillips

    cropAndrewPhillipsAndrew Phillips is VP of DevOps Strategy for XebiaLabs, provider of software for continuous delivery and DevOps. He is a cloud, service delivery and automation expert and has been part of the shift to more automated application delivery platforms. He contributes to a number of open source projects including Apache jclouds, the leading cloud library, and is a co-organizer of the DynamicInfraDays container community events.

  • CloudPassage Named “Most Innovative Cybersecurity Company”

    SAN FRANCISCO, CA–(Marketwired – May 05, 2016) –  CloudPassage today announced it has been recognized as the “Most Innovative Cybersecurity Company” in the 2016 Cybersecurity Excellence Awards, which are voted on by the more than 300,000 security professionals who participate in the LinkedIn Information Security Community. From nearly 200 cybersecurity vendors that were nominated, CloudPassage was selected as the winner of the mid-size company category, focused on the most innovative organization that has between 101 and 1,000 employees.

    “Enterprises are in the middle of a massive transformation of their IT infrastructure designed to let them move faster and stay competitive,” said Robert Thomas, CEO of CloudPassage. “Agile IT delivery models involve lots of automation, high rates of change, mixed environments and on-demand IT services. But traditional security tools don’t work with these modern IT environments. We’re winning recognition as a leader in the space because CloudPassage Halo is now a proven platform that enables this transformation.”

    CloudPassage Halo is an on-demand, security-as-a-service (SaaS) platform that deploys in minutes and automates a comprehensive set of security and compliance controls for servers in any combination of public cloud, private cloud or data center environments. The result is fast, effective security that solves problems of visibility, microsegmentation, compliance and speed of deployment.

    The 2016 Cybersecurity Excellence Awards honored individuals, products and companies that have demonstrated excellence, innovation and leadership in information security. Winners were selected based on the content of their nominations and the popular vote by the Information Security Community on LinkedIn, one of the largest online networks of cybersecurity professionals with over 300,000 members.

    As part of the company’s efforts to remain innovative, CloudPassage was recently awarded three patents that extend the scope of its original, agent-based, agile security model, making it the first company to obtain a U.S. patent for universal cloud infrastructure security.

    About CloudPassage

    CloudPassage® Halo® is the world’s leading agile security platform that provides instant visibility and continuous protection for servers in any combination of data centers, private clouds and public clouds. The Halo platform is delivered as a service, so it deploys in minutes and scales on-demand. Halo uses minimal system resources; so layered security can be deployed where it counts, right at every workload – servers, instances and containers. Leading enterprises like Citrix, Salesforce.com and Adobe use CloudPassage today to enhance their security and compliance posture, while at the same time enabling business agility. Headquartered in San Francisco, California, CloudPassage is backed by Benchmark Capital, Lightspeed Venture Partners, Meritech Capital Partners, Tenaya Capital, Shasta Ventures, Musea Ventures and other leading investors.