devopsy.kinsta.cloud

Category: DevOps Practice

  • The Phoenicorn Project

    The Phoenicorn Project

    The Unicorn Project is the sequel to the ground-breaking book The Phoenix Project. Most people know the story about Bill the IT manager at Parts Unlimited, who is tasked with fixing a derailed IT project or having his IT department outsourced. The Unicorn Project takes it a step further, with developer and architect Maxine in the starring role, helping Parts Unlimited to develop new products in new markets–the riskiest combination of all. This requires gambles that are only justified when the organization can experiment rapidly, break the rules and deviate from the processes that govern their current–but diminishing–business.

    The content of the book revolves around five so-called Ideals:

    1. Locality and simplicity in our code and organization.
    2. Focus, flow and joy in our work.
    3. Enablement of improvement and achievement.
    4. A culture of psychological safety.
    5. A relentless focus on our customers.  

    These are a natural progression of the themes in The Phoenix Project, in particular the first and third of The Three Ways of DevOps: 

    1. Attending to the performance of the entire system, as opposed to the performance of a specific silo of work or department (related to Ideal 2).
    2. Creating short feedback loops, enabling necessary corrections to be continually made.
    3. Creating a culture that fosters continual experimentation, taking risks and learning from failure; and repetition and practice as the prerequisite to mastery (related to Ideal 3).

    Topics related to the first four Ideals have been explored in other books in the same family of publications, in particular The DevOps Handbook. The last Ideal–customer focus–is for me the most significant addition. It really draws attention to how IT and business have to converge and even merge in order to develop new business models. Meaning that those people-previously-known-as-IT have to up their game and develop a much deeper understanding of the jobs customers need to get done. The business value of DevOps has interested me since I got involved in the movement, and I’ve captured some thoughts in a white paper for the DevOps Agile Skills Association.

    It’s another easy-to-read, fast-moving and plausible story that will undoubtedly inspire the DevOps community. So far so good. But as a facilitator of GamingWorks’ The Phoenix Project DevOps game, it got me thinking how I can incorporate the Five Ideals (and more) into this highly-interactive game.

    My first analysis is encouraging. Starting with the last Ideal and working backwards, the game–that is based on the book–has strong focus on the customer while at the same time ensuring that technical debt (another key topic in the book) is kept under control. Psychological safety comes up a lot in the game–when it’s clear that somebody isn’t really participating, there’s a time out to discuss the importance of people feeling safe to share their concerns without fear for their reputation and position. Continual improvement is hard-wired into the game, with retrospectives after each sprint, leading to hypotheses and experiments for the next sprint. As for focus, flow and joy in our work, we encourage the participants to visualize the value stream and see how work flows from role to role. There’s also plenty of fun, particularly when they hit their revenue targets.

    Locality and simplicity in our code and organization is probably the least dominant Ideal in the game–it’s a non-technical game so there’s no coding, and it’s a small team so almost by definition it’s local. We do discuss, however, the challenge of scaling–which is when this Ideal comes into play. I’ll experiment with the Five Ideals in my next The Phoenix Project games so watch out for further blogs.

    The Five Ideals triggered another association. I was lead editor of the upcoming ITIL 4 High velocity IT module. This is about how digitally-enabled organizations place higher demands on IT, requiring different ways of thinking and working. One of my contributions is the concept of five Key Behavior Patterns:

    1. Help get customers’ jobs done–helping customers become who they seek to become.
    2. Keep raising the bar–taking things to a significantly higher level.
    3. Trust and be trusted–as professional knowledge workers in a healthy workplace.
    4. Accept ambiguity and uncertainty–not scared of not knowing an answer.
    5. Commit to continual learning–all as part of their daily work.

    I believe many practitioners want to work in organizations that foster these behaviors. As such, I see them as aspirations. As marketing legend Seth Godin said, “people like us do things like this.” You can see the similarities with the Ideals: 

    • “Help get customers’ jobs done” equates with “A relentless focus on our customer.”
    • “Keep raising the bar” and “Commit to continual learning” are close to “Enablement of improvement and achievement.”
    • “Trust and be trusted” is the same as “A culture of psychological safety.”

    It is so encouraging to see similar thoughts emerging within different communities. This will hopefully break down the silos that exist in the IT industry and bring us all closer together. All too often, conferences and communities are organized by specialization. They stick safely to themselves and reinforce their stereotypical stories about other disciplines. Praise and power to the rebels who practice what they preach (T-shaping and multi-functionality) and liaise with their industry colleagues, organize joint conferences etc. Evolution thrives on diversity and it would be a shame to see inbreeding in communities, leading to extinction. Let’s not only read The Unicorn Project but also do something useful with it.

    — Mark Smalley

  • 5 Best Practices for Feature Flagging

    5 Best Practices for Feature Flagging

    Feature flags, also known as the feature toggles, are important concepts in the field of DevOps. They have been around for a long time and have been used continually by developers for their convenience. As software development services providers are striving for higher agility, practices such as feature flagging are becoming increasingly relevant. If you are not familiar with the concept of a feature flag, let’s start with understanding what feature flagging is.

    What is Feature Flagging?

    Feature flags are used for the process of branching your code, which means to turn certain code paths on and off to separate the release of new features from the actual deployment of our code. Why do DevOps developers want to branch their code through feature flags? Well, feature flagging is a great software development practice for two reasons. Firstly, for features that are a work-in-progress, developers can use a feature flag to hold their release until they are ready. This ensures the release of other features that are ready is not delayed just because one feature is not. Secondly, features that are being worked on can be kept off using the feature flag and only once it is ready it can be turned on. This allows developers to work directly on the feature without changing the main code, also known as the trunk or master branch. When all is working and ready to be released, turning on the feature toggle releases the feature, just like a switch.

    To understand feature flags in the simplest term, feature flags are “if/else” statements to develop a conditional branch or pathway into your code. For example, you can use a feature flag to state that “if so and so feature is enabled, run new algorithm; or else, run old algorithm.” This allows developers to control the functionality—if the feature flag is enabled only then the new algorithm is executed; else skipped. This is the most basic form of feature flags, however, they could be more complex.

    Feature flags are a practical way for software teams to maintain the delivery and release of features, and there are many advantages of using them. However, too many feature flags can make your code more complex and difficult to manage.

    Here are the best practices of feature flagging that can save your project from becoming a feature flag hell.

    More Feature Flags Equals Complex Code

    Feature flagging is a good practice that can help you maintain the delivery and release of different features, however, using too many feature flags can quickly turn your code into a feature flag hell. The more feature flags you create, the more code paths are going to be created, this increases the complexity of your code and makes the testing process harder. A higher number of code paths can cause a mess and risk the functionality of your code. Therefore, it is best to only create feature flags when it makes sense and always check if a previously created feature flag can be re-used instead.

    Name Your Feature Flags

    For efficient management of feature flags, it is crucial to have a proper flag naming system. Without it, it is possible to confuse the flags, forget why they were created for, or create flags with the same name—all of which can cause disruptions and confusion. When working with a team of developers, it is important to ensure that everyone follows the same labeling method so they can get the information about the flag just by looking at the name. Otherwise, it is likely that a team member might mistakenly trigger the flags, upsetting your code.

    Log and Clean Up Old Flags

    Over time, it can become difficult to keep track of the changes that are made to a feature flag. Therefore, it is important to track changes through logging, especially when working in teams. Using logging, you can keep a track of who created the feature flag, who made a change and at what time. This can save you from wasting time figuring out who was responsible for what change. A log will set the record straight about every change introduced for every feature flag.

    This is also great to know which flag and code paths are obsolete and redundant now. When you know which flags are unused you can clean them from your code to avoid any conflict or confusion.

    Use a Feature Flag Management Tool

    For better management, control and visibility of your feature flags, you can use available feature flag management tools. Like every other management tool, feature flag management tools are enterprise-scale software to manage feature flags. Some of the most popular tools include LaunchDarkly, Rollout and Bullet Train. Tools like these can make the management of feature flags easier for you and increase your development speed.

    Use Feature Flags to Collect Data

    When it comes to scaling your product, feature flags can be of great help to collect data from users. For instance, if you want to introduce a new feature, you can roll out the change slowly to a few users first. Using feature flags, you can make the new feature or update available to a smaller set of users only and collect data about how well they respond to the release. You can then use their feedback to improve or change your features to deliver an improved user experience. Feature flags are used in this manner by companies such as Facebook and Netflix to test their new features before releasing them for the entire user base.

    — Emily Williamson

  • Operational Excellence and the Success of Software Deployments

    Operational Excellence and the Success of Software Deployments

    When we talk about best practices for software reliability, the conversation tends to focus on optimizing the applications themselves and the infrastructure that hosts them. The driving idea is reliability must be baked into system architectures and infrastructure from the beginning.

    That’s certainly true. But by focusing too much on the design and implementation of applications, you run the risk of overlooking another crucial element for achieving reliability (not to mention agility and extensibility): a culture of operational excellence.

    It’s only by baking excellence into your organization’s operational culture that you can maximize reliability.

    Let me explain…

    Defining Operational Excellence

    Put simply, operational excellence is a mindset that is embraced across an organization to maximize outcomes and positive results.

    Operational excellence can be reinforced by specific tools and processes, but it’s ultimately a philosophy and a cultural principle. It must be integrated into your organizational culture in order to achieve its full effects.

    Operational Excellence And Software

    Operational excellence is a buzzword that you hear occasionally in the context of business management. It only rarely appears in conversations about software. Nonetheless, the concept has an important role to play in several respects, including making software more reliable and extensible.

    Uniting Disparate Teams

    One of the most pervasive challenges in modern software deployment and management is the fact that every deployment depends on multiple teams. Developers, IT operations, infrastructure engineers and business managers all have a role to play in ensuring that an application is a success.

    Getting all of these teams to work together can be a challenge. The ideal solution, according to the DevOps mantra, is to de-silo your organization by creating a single DevOps teams that oversees development, operations and everything in between. For some companies, that approach will work, but for others, single-team DevOps is not a realistic goal. There will always be some distinction between teams and specializations.

    Yet whether you have a single DevOps team, or multiple teams working toward a common goal, operational excellence can help you achieve the cultural unification necessary to help everyone advance the common good. Operational excellence serves as a cultural goal shared by all teams and team members during the software development and deployment process. By making excellence part and parcel of your culture, you gain a principle that can guide all of your teams, even if they otherwise share little in common culturally—which, generally speaking, is the case; developer culture is not the same as IT culture and certainly not the same as business culture.

    Operationalizing Best Practices

    Another key benefit of operational excellence is that it helps to ensure best practices are actually followed across the software deployment process.

    Most stakeholders in software development and deployment know what they should do when performing their jobs…but they don’t always do it. Your developers might churn out an inefficient function because they are under pressure to meet a deadline and need to deliver something that works, even if they know that they are not following coding best practices. Your IT team may fail to configure granular IAM permissions for a virtual server because they lack the time, even though they know that is not a best practice from a security standpoint.

    Instilling operational excellence into your teams helps to prevent these types of shortcuts. When a culture of excellence prevails, your team will follow best practices, even if they take longer.

    Continuous Improvement

    Human beings are naturally inclined to desire finality. Feeling like we will never reach the end of a task is discomforting (that’s why poor Sisyphus was so unhappy, for example). Yet, this discomfort needs to be managed if your organization is to achieve a culture of continuous improvement. Continuous improvement means your teams constantly find ways to make things better, even if they are already quite good.

    For developers and IT teams, this can be a tough pill to swallow. Developers or engineers who have achieved 99.99999 reliability for their application would probably rather feel proud of what they’ve accomplished than be told they need to add another nine to that figure.

    Still, striving to become even better is what continuous improvement requires. A culture of operational excellence can help ensure that your teams welcome this type of challenge rather than resent it.

    Collective Effort

    When it comes to software development and deployment, personal ownership of any part of the code or process is a risk to the organization. If only one programmer knows how a certain microservice works, or only one IT engineer has the power to create new databases, your organization will lose agility, or it could even end up with a hostage employee situation.

    Instead, software deployment should be as collaborative as possible. Everyone within a given team should understand and (in a pinch, at least) be able to perform everyone else’s job.

    A culture of operational excellence helps to ensure that your teams take a collaborative approach to the way in which they build and deploy software. Instead of letting each individual own part of the process and receive personal credit for its success, operational excellence encourages team members to think of their work as a collective process with collective responsibility for the results. That’s because operational excellence focuses on the success of the organization as a whole rather than individual employees or teams.

    Conclusion

    To be sure, choosing the right architectures, tools and people will do much to help maximize the reliability and effectiveness of your software, but those are only part of the solution. You also need a culture of operational excellence to unite your various teams behind a commitment to best practices, continuous improvement and collective pride in the applications they build and deploy.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • ServiceNow Makes the DevOps Connection

    ServiceNow Makes the DevOps Connection

    ServiceNow today announced it is extending the reach of its IT operations management platform to integrate with a variety of DevOps platforms.

    Richard Hawes, director of product marketing for ServiceNow, said ServiceNow DevOps will provide IT operations teams relying on an ITIL-based framework accessed as a software-as-a-service (SaaS) application visibility into DevOps processes and events occurring in on-premises environments or public clouds.

    At present, ServiceNow DevOps is available for financial services organizations based in the Northeast region of the United States and the UK. The service gradually will be rolled out to additional ServiceNow customers over the course of 2020. ServiceNow DevOps initially integrates with Jira Software, GitHub, BitBucket and Jenkins, with more integrations expected to be rolled out periodically.

    Hawes said ServiceNow recognizes that IT organizations are building and deploying applications at rates that are faster than existing ITIL-based approaches can track. However, ITIL-based frameworks provide the highly structured set of processes around which the bulk of IT environments are managed. ServiceNow DevOps enables IT teams to automate change management tasks such as planning, development, testing, deployment and operations via a single dashboard surfacing a common set of metrics, he said. He added in many cases, those preset rules and policies will eliminate manual processes that often conspire to slow the rate at which applications can be deployed and updated within any IT environment, said Hawes.

    No developers need to be involved in those processes because IT operations teams can set rules and policies, and developers will see their code running in production environments in a matter of minutes regardless of what tools they employ, said Hawes. That approach also will make it easier to scale DevOps across an enterprise IT organization at a time when adoption of DevOps is still uneven at best, he noted.

    At the same time, that level of integration should also make it easier for IT teams to audit DevOps processes using a common framework to capture events such as when code is checked into a DevOps platform, he said. That capability is a critical requirement for any company trying to apply best DevOps processes with the context of a highly regulated industry such as financial services.

    Hawes said the majority of organizations that have adopted ServiceNow to manage IT have also adopted a DevOps platform. Overall, Forrester Research reports 56% of global infrastructure decision-makers now report that their organizations are implementing, have implemented or are actively expanding their DevOps initiatives. ServiceNow doesn’t expect DevOps processes to supplant ITIL-based frameworks as much as it anticipates both approaches co-existing as they continue to evolve, he said.

    With the release of the latest version of the ITIL framework, it’s apparent that the proponents of ITIL have come to recognize that IT needs to become more agile to meet the needs of digital business. The challenge they face is finding ways to enable IT teams to become more agile without sacrificing the gains in stability achieved over the course of the last two decades. With the launch of ServiceNow DevOps, the effort to find a middle ground between those two extremes can now begin in earnest.

    — Mike Vizard

  • Investing in a Mobile Device Testing Lab

    Investing in a Mobile Device Testing Lab

    It will likely come as no surprise that app downloads are on the rise, with no signs of slowing down. Today’s consumers use apps for everything from ordering food, to shopping for clothes, to managing money and more.

    In fact, according to a recent report by App Annie, consumers downloaded a total of 194 billion apps in 2018, up from 178 billion apps in 2017. 

    Yet, the same report shows that app retention rates after 90 days are low–ranging from 32% to a meager 4%.

    Reasons for app deletion vary, but far too many apps, in a burgeoning sea of apps, are either hastily and incompletely tested or aren’t even tested at all. This can lead to poor consumer experience, deleted apps and even negative feelings about a brand itself.

    Therefore, it’s critical for mobile app developers and practitioners to button up their testing practices before release. Otherwise, you run the risk that all the work you put into your app will only lead to the dreaded and overcrowded app graveyard.

    Overcoming Today’s App Testing Limitations

    The primary challenge prohibiting companies from properly testing their apps is access to real-time devices in the same instantaneous, maintainable and scalable infrastructure. The expectations around continuous testing in desktop, web and packaged applications is difficult to achieve in mobile testing without a device cloud, which delivers seamless access to real devices in an on-demand infrastructure and brings order to the chaos of managing multiple mobile devices in a test lab.

    A cloud-based mobile testing lab provides a comprehensive solution that solves issues around mobile app testing, including too many device types and operating systems to test, as well as a lack of people and time to test. It offers real-time, continuous access to real devices for all mobile testing needs, resulting in higher quality apps and increased customer satisfaction and retention.   

    An added bonus is a cloud-based mobile testing lab frees app testers from initiating and monitoring automated tests. Basically, testers can automate their automation. This, in turn, allows them to perform other significant tasks that can increase user acceptance, engagement and experience.

    Failure Looms with Little or No Testing

    That being said, some organizations, in a rush to go to market, release an app with little to no mobile testing at all. They believe testing is too difficult, too time-intensive or too costly to be worth their while. Some think minimal web testing will keep them out of trouble when it comes to mobile. And although we all like to think that we write bug-free code, unfortunately this isn’t always the case.

    Furthermore, there are those who will test their app and then release it before fixing all the bugs, thinking they can test and improve along the way. However, that way of thinking can be detrimental to a company and its brand. Localytics found technical failure as simple as an image not loading can lead to a 29% loss of customers.

    Mobile App Testing Helps Ensure a Thumbs Up 

    The average U.S. adult, according to an eMarketer study, spends 3.75 hours on mobile devices each day, with nearly three of those hours using apps. Further, Statista estimates app downloads to grow to 258.2 billion in 2022. Clearly, the app market is thriving, but so is the competition. You’ll have a better chance of standing out in the crowd if your app works–flawlessly.

    A mobile device testing lab could be one of the key solutions that will help separate the proverbial app wheat from the chaff. By testing apps in real time, you understand which types of devices are most affected should a crash occur. Analytics show what app features are used most, allowing you to prioritize what should be fixed first during the testing process. 

    The future of apps is in mobile, which is why mobile testing will continue converging with legacy applications such as web and desktop. Forward-looking companies need an approach that allows top-of-line technologies to work together as if provided by a single solution provider.

    A mobile device testing lab helps you break through the barriers of app development. In doing so, your app has a better chance of doing what you say it will do–without crashes–hopefully earning your app a coveted spot on users’ home screens instead of the trash.

    — Dan McFall

  • Five Tips for Solving the Technology Skills Gap

    Five Tips for Solving the Technology Skills Gap

    The insightful, and sometimes breathless, predictions regarding digital transformation are everywhere. We are right to be mindful of both the potential and the challenges posed by digital transformation. Digital transformation is increasing the rate of change in every business, in every line of business and even in every role.  

    Digital transformation requires new development practices, organizational culture changes, customer intelligence and focus, empathy and, above all, new ways of thinking. Only when everyone is committed to improving the way work gets done, can an organization thrive in a competitive environment. As organizations continue to grapple with how to prepare their workforce for an increasingly digital world, they have a technology skills development problem.

    Below are five considerations for bridging the technology skills gap brought on by digital transformation.

    Identify the Skill or Development Problem You Are Trying to Solve

    It’s essential that the technology skills development program be aligned in purpose and design with the intended business objective. That may sound obvious, but organizations have a way of accelerating beyond the original scope and intentions. 

    Ultimately, what you are trying to do will determine the combination of tools, content and even organizational commitment needed to be successful. For instance, are you trying to deepen technical knowledge for a set of employees? Or, are you tasked with improving specific performance objectives in data, DevOps and/or security?

    Before investing in training, it’s important to establish the targeted employees, the range of competencies to be covered, the degree of proficiency required and the time frame to complete the initiative. In all cases, build a program that can solve the problem in a time frame that meets the business needs.

    Establish the Performance Objective 

    For nearly all technology skill problems, the goal is performance: the target learners becoming sufficiently competent to perform at the required level. Understanding what the performance standard or measure of success is or will be helps focus all stakeholders on the same goal.    

    If specific performance objectives are required, monitoring a specific key performance indicator (KPI) can be the most valuable approach to determining training success or impact. If the KPIs are not available, using post-assessments can be a useful measure of knowledge gained and can help demonstrate the impact of the training.   

    Leverage Authoritative Content

    It’s important to understand the sources used to create the course material as well as who authored or collaborated on the material. This matters not just because the learning content should be accurate, but also because adult learners are sensitive to the credibility of the source material. Especially in technical areas, IT professionals expect to be provided with material from authoritative sources.

    IT professionals consider current practitioners, or well-known consultants the most authoritative voices on how to use technology. In some cases, industry associations or trade groups have established themselves as authoritative sources in their specific technical areas. Regardless, the source material should be highly reputable and authoritative. 

    Put User Experience First 

    Making learning as convenient for the target learner as possible is essential to a successful learning program.  

    Convenience has often meant anytime/anywhere learning—learners can take courses at home, while commuting, from their desk or wherever they work. This experience should be much like watching a movie on Netflix or Hulu: Learners should be able to start the course at one location, on one device and continue it at another time on a different device from just the right point in the course. 

    Training can also be seamlessly incorporated into the workflow of some applications. Think of it like a more sophisticated, less annoying version of “Clippy,” the Microsoft assistant that provided in-context help for Microsoft Office through the mid-2000s. For some types of applications and technical roles, having a context-sensitive learning engine that can identify and serve up nuggets of learning appropriate to the task can be very useful. 

    Offer the Right Mix of Push Learning and Pull Learning 

    Employers are beginning to realize the benefits of pull learning where IT professionals identify and select their own learning paths. This model allows motivated professionals to acquire skills, gain more responsibilities and, in some cases, promotions and new job opportunities. Employers have realized that when employees self-select a course, it is a strong indicator of self-motivation, and a strong predictor of professional dedication and success.  

    But pull learning isn’t appropriate for every problem to be solved. For example, maybe you need a group to learn the same thing about cloud security or compliance. In such situations, it’s not practical to wait until the target learners are motivated to take the specific courses. It makes more sense to solve these challenges by assigning specific courses to the right groups of target learners, assigning completion dates and monitoring progress.  

    Depending on what problem you are trying to solve, either push learning or pull learning may be more appropriate. 

    Setting Your Organization Up for Success

    Ultimately, successfully navigating digital transformation requires a team with well-aligned IT roles and skill sets. People are the make-or-break element of a high-performing IT organization. There is simply no replacement for people with the right skills, attitudes and traits. CIOs don’t have the luxury of hiring a totally new roster of people with “the right stuff,” so they will have to be creative in using a combination of hiring, mentoring and training, contractors, and partners to create the needed mix of capabilities. 

    Once you have hired and trained the talent in your organization, what’s your plan to help them continue their learning journey for the duration of their career?

    — Mike Hendrickson

  • IT Enables Scale in Digital Transformation

    IT Enables Scale in Digital Transformation

    Few corporate functions have seen their role disrupted as much as IT these last few years. The help desk days are long gone. As digital transformation accelerates, IT is becoming less about outright technology and more about creating capabilities that enable the overarching business strategy. As such, IT is the engine behind any company’s digital transformation.

    Here are three ways IT can advance today’s digital journey by empowering the business from a consultative, strategic position.

    Going Digital While Digitizing

    First, let’s agree on digital transformation’s foundational terms, which understandably elicit some ongoing confusion: “digitization” and “digital,” which the MIT Center for Information Systems Research has described as two discrete yet complementary things. In short, digitization is about leveraging technology to improve or enhance business processes, operations and offer development. By contrast, going digital is about giving customer value to digitization—with the goal of revolutionizing the customer experience and creating new digital business models. What’s the point of digitizing a process or product if the user experience is poor? 

    Balancing these complementary efforts is essential. It is the role of IT to ensure that digitization and digital can happen at the same time. 

    Rethinking the Economic Model

    To keep up, IT must move away from traditional demand-based models, enabling capabilities with a product mindset instead of a time-bound project mindset. The concept of capability (that is, a business area enabled by a consistent set of IT products) is quite critical to avoid creating one-off or point solutions that are just the means to answer to a specific demand. Instead, looking to IT as the enabler of corporate practices that are always evolving and improving (e.g., cybersecurity) is imperative. Embracing Agile methodologies will bring this approach to fruition.

    Pivoting to this kind of a capability-based model requires a modern API-based architecture, which fundamentally is the way out of building and/or replacing monolithic systems. As today’s world requires a fine balance of speed and frugality, a mastery of resource allocation, and a prioritization rigor, we must unburden resources aimed at replacing systems that are working just fine. 

    To that effect, Amazon Web Services has a great architecture principle referred to as “two is better than zero.” In other words, it is better to have two similar IT components emerge from fast-paced, parallel development than nothing due to project bottlenecks and unmastered interdependencies. Even if we want to drive re-use every time we can (and have mechanisms for that), we should not bog down overall transformation due to one weighty project. So thinking in terms of not just tolerating diversity, but enabling it, is a good way to built an architecture that can empower both agility and resiliency.

    Addressing Technical Debt Continuously

    Technical debt is perhaps every incumbent company’s biggest challenge when going digital. The cost of maintaining legacy and outdated systems is high, and heavy technical debt is another obstacle to achieving full digital transformation. Accenture consultants see this every day, describing this burden as a price that “hinders [companies’] ability to innovate and adapt in the digital age.” 

    This is where IT can come to the rescue by having a structured approach and engagement model designed to streamline systems and processes in order to free up resources for reallocation. First focus on eliminating legacy custom-built applications and localized tools based on criteria that are well known and shared (think of a scoring system). Here, again, resource allocation can play its part by ensuring the full cost of those legacies is being recognized by the organization. 

    A huge added advantage of a continuous effort to remove technical debt (beyond cost, the reduction of obsolete systems and a simplified IT landscape) obviously relates to security. Especially at a time when the average cost of a single data breach globally is $3.9 million. In fact, potential cybersecurity and IoT-related physical safety concerns “will pressure CIOs at G2000 companies to increase IoT security spending by up to 25%, temporarily neutralizing business productivity gains” by 2020 (IDC). Redirecting technical debt can offset part of this essential spending on security.

    Accenture notes that 79% of CEOs report that their organization is adopting new and emerging technologies faster than they can address related security issues. IT teams therefore must carry the security torch, determining and implementing ways to make security easier for employees while also protecting the end-to-end digital ecosystem. A continuous effort to reduce the technical debt is one way—among many others—to improve posture. 

    A Place at the Digital Transformation Table

    Indeed, these are exciting times for every business. Digital is all about creating customer value, guided by a better understanding of customer needs deeper in the enterprise. Since providing a great experience is not only about the user interface but also about the ability to mobilize the internal systems in order to deliver at scale, IT experts now have a major seat at the table for revolutionizing the customer experience at scale.

    The essential ingredients to full digital transformation are clear: digitizing and going digital, being able to embrace emerging technologies with an architecture that makes diversity efficient when required and creating cyber citizens that continuously reduce the corporation’s technical debt. Behind the scenes and now front and center, IT is pushing forward the transformation strategy for companies staking a competitive claim in today’s digital economy.

    — Hervé Coureil

  • How DevOps Is Driving the Demand for Cross-Platform Tools

    How DevOps Is Driving the Demand for Cross-Platform Tools

    The demands of modern business mean companies today want choice when it comes to the technology they deploy. Gone are the days when they rigidly used a single environment–instead they want to be able to use the best of technology from vendors and be sure it will work across environments seamlessly. 

    Whether it’s on-premises or the cloud, Linux or Windows, SQL Server or Oracle databases or even at the development tool level, they want their people to be able to use the Integrated Development Environment (IDE) they’re most at home with, yet still be able to share third party tools and resources. This requirement for greater choice is being driven by three key factors.

    The Growth of DevOps

    Firstly, the spread of DevOps is leading to greater collaboration between departments within an organization, as is the rise of the cloud.

    In the past, for example, database administrators (DBAs) and application developers worked in their own silos, with their own technology, without needing to interact. DevOps has radically changed this, bringing them together in teams where workflows merge and complement each other. They need to follow the same processes, such as continuous integration and continuous development, but have very different technology backgrounds and skillsets. DBAs may know Microsoft SQL Server Management Studio in-depth, while developers are used to creating code in IDEs such as Visual Studio. SQL Server experts may also choose to work in Windows, Linux or a combination of both environments. 

    Forcing everyone to use a single environment will clearly be counter-productive and lead to a drop in efficiency. At the same time, however, letting them use different approaches can harm the very teamwork that DevOps relies upon. Instead, vendors need to allow their software to be used and managed through multiple approaches, ensuring that companies get the best out of their people and investments. 

    Technology Everywhere

    Marc Andreessen coined the famous phrase “software is eating the world“ back in 2011. Since then every business has seen technology spread throughout its organization, with digital transformation initiatives increasing the software development required for all departments and functions. At the same time, data has become central to better business operations, enabling brands to better understand their customers, provide an improved experience and deliver more tailored products and services. 

    This has resulted in the rise of full-stack developers who are now responsible for both application and database development. Redgate’s 2019 State of Database DevOps Report revealed that 77% of developers now switch between coding in application languages, such as JavaScript in one moment to writing T-SQL for the database the next.

    A problem arises if different IDEs are required which inevitably leads to an increase in the need for training alongside a decrease in efficiency and performance. 

    Growing Cost Constraints

    In today’s competitive marketplace, every business investment is subject to a high degree of scrutiny to check that it’s delivering a demonstrable ROI. While budgets in the past might have allowed organizations to use different tools or systems in each department, there is a growing need to avoid duplication and the costs that it brings. Open source and free tools are also being widely deployed in even the largest organizations. This drive for greater efficiency obviously needs to be balanced against the skills and experience of in-house teams, who want to be able to use tools they favor and are accustomed to.

    Conclusion

    All of these three factors are driving a new approach from software vendors. Whereas in the past they might have focused on integrating their tool with a single IDE, they now need to offer choice. This allows a common development approach to be adopted while still enabling collaboration across the business, particularly when it comes to DevOps. It preserves investment in the skills and tools that different groups know best, increasing efficiency, yet also eases the introduction of initiatives like full-stack development.

    Driven primarily by DevOps we’re moving into a more heterogeneous world, and vendors need to ensure that they are supporting companies so they can work in the ways they want, with the tools they want, if they want to remain relevant and successful.

    — Matt Hilbert

  • The Battle for the Frontend: Rethinking APM

    The Battle for the Frontend: Rethinking APM

    With the battle for the backend between data centers and cloud largely over, application development is the next frontier ripe for innovation. Studies project mobile app revenue at $935.2 billion by 2023 and Internet of Things (IoT) installations at $75.44 billion by 2025. It’s no surprise that software innovation is ramping up around application development in a big way. At the same time, the desktop is still a primary interface in the workplace, which has given rise to a wave of browser-based applications for enterprise collaboration and efficiency.

    Apps—both on devices and in-browser—are effectively what businesses run on. New JavaScript-based Single-Page Applications (SPAs) are replacing legacy cloud stacks, where the software runs primarily in a customer’s browser. However, this approach creates an observability gap for teams under pressure to deliver better software more quickly. Because no application is siloed, the distributed nature of modern applications adds further complexity—and increases the risk for defects—for developers, who must code faster, smarter and better to keep their businesses competitive in an application-centric world.

    The Battle for the Frontend

    IDC predicts that by 2022, more than 60% of global GDP will be digitized, with growth in every industry driven by digitally enhanced offerings, operations and relationships—and applications will be the primary method of delivery. Companies in all industries are battling for users, revenue and reputation only, but only those companies with the best software will remain contenders. To innovate continuously, ensure optimal user experiences, and ultimately, retain their competitive advantage, enterprises must ship code quickly, every day and with fewer errors.

    Application errors and crashes will dramatically spike churn rates, kill conversions and impact brand reputation and customer retention. As tolerance for faulty performance is rapidly diminishing, user experience becomes a business-critical concern that has a substantial impact on a company’s bottom line. While companies with faulty code are dealing with the fallout, those that rely on modern application performance monitoring (APM) are shipping better code more quickly and with less risk.

    These new business drivers, along with an explosion of devices—from smartphones to IoT devices—have led developers to move their code closer to customers to increase code speed and improve scale. But this shift means software is run on customer devices over which developers have no control, a reality that inevitably creates its own set of new problems to monitor. To win this battle for the frontend, development teams that create games, mobile applications, IoT and other high-performance applications need rich insights into application health in order to quickly and continuously fix software errors, all with minimal impact.

    Rethinking APM

    Unfortunately, many legacy application monitoring tools do not solve for the frontend. They are fragmented, or specialized, and missing support for JavaScript, mobile, desktop apps or embedded IoT devices—despite these platforms being a significant part of the application ecosystem. Legacy tools focus more on system behavior, offering performance metrics on availability, throughput and latency, but miss the mark when it comes to actionable insight that helps frontend developers make sense of complexity and quickly get to the root cause of errors.

    Modern applications require a holistic approach to monitoring that provides deep context and understanding about how to address issues when they arise, instead of simply displaying the symptoms of a problem. This approach should involve collecting and analyzing transactional traces, scaling search and storage to handle full traces, and building intelligent algorithms to detect and analyze issues. By moving monitoring from production environments to test environments, development teams can accelerate the software development lifecycle and reduce the impact on customers. APM must integrate with continuous delivery tools to monitor continuous health mechanisms.

    — David Cramer

  • Achieving Organizational Change Through Scaled DevOps

    Achieving Organizational Change Through Scaled DevOps

    The rapid pace of technological change has had a major impact on customer expectation, forcing IT decision-makers to adopt agile processes to ensure the continual delivery of innovation. This has led to the mass adoption of DevOps practices, with 77% of organizations indicating they rely on DevOps to deploy software, or plan to, in the near future.

    DevOps is a key ingredient for building and deploying better software faster. It enables developers to spend less time on onerous tasks and more time creating new features that drive competitive advantage and elevate customer experience.

    But, for DevOps to streamline organizational change, it can’t be a one-off initiative. Scaled DevOps requires aligning team members on common goals and best practices and establishing a DevOps maturity model tailored to a company’s individual needs. This is no easy lift and has led teams to abandon DevOps initiatives before they even get started. While the road to scaled DevOps can be daunting, the benefits can have a positive ripple effect across the organization.

    Business

    The business benefits that accompany DevOps are endless. Think: expanding your customer base, spearheading organizational readiness and achieving unmatched speed. As the consumer landscape continues to change, you will be able to adapt accordingly to generate new features and pathways to customers. Plus, DevOps provides a prime opportunity to get more information from your client base and relay it back to developers, equipping your organization with opportunities to learn from its failures and develop a company-wide, reflective model that better accommodates customer demands.

    Once your organization establishes a successful DevOps practice, it will be better prepared to take on other emerging trends and undergo a full-scale digital transformation. With DevOps as the catalyst for change, you can surpass competitors and disrupt the industry with innovative ideas, enabling you to stay ahead of the curve. Once an organization is fully committed to DevOps practices, the company will also enjoy a competitive advantage due to increased speed by empowering your business to provide customers with capabilities faster than rival industry players.

    Culture

    DevOps may require a daunting corporate culture makeover, but it also allows businesses to enjoy unbeatable cultural benefits by improving communication, establishing a foundation for continuous learning and boosting corporate morale with more meaningful work. When effective processes for communication are in place, employees can avoid the misunderstandings and missteps that often lead to failed initiatives and low morale. Once DevOps improves communication between teams, it sets the stage for more collaboration and cross-departmental education, allowing an organization to develop new operational efficiencies and empowering staff with highly specialized knowledge. With reduced inefficiencies, team members are empowered with more free time to create and meet new goals, plus budding talent from competitors will be drawn to your organization’s innovative environment.

    Operations

    Empowered by scaled DevOps, businesses will enjoy huge operational and technical rewards with automation, controlling costs and revamping security practices. Since establishing a DevOps practice requires the successful adoption of automation processes, a DevOps initiative includes the same key benefits that automation boasts by delivering the coveted digital experiences that consumers, employees and stakeholders demand. Automation not only meets these demands, but also sets the groundwork for a DevOps journey with CI/CD pipelines that automate software releases to rid your organization of manual release challenges.

    On the financial front, as your company moves toward a consumption-based economics model for things like public cloud, your DevOps practice will help control costs and environments by alleviating unused tools. In the long run, improved security will also prove profitable because there is no fiscal nightmare worse than a breach. Upon defining your DevOps model, compliance and control are not only maintained, but rapidly transformed through automated policies and configuration management.

    With knowledge of the transformational qualities that come with an effective DevOps approach, IT leaders are eager to adopt DevOps to improve efficiency, boost profitability, deliver superior customer experience and establish a culture of empowerment. However, they must understand that successful DevOps initiatives do not happen overnight. DevOps is reliant on continuous testing and education to ensure that companies can keep pace with their new collaborative culture, rapid delivery process and new technologies. Nevertheless, motivated by the promise of positive business, operational and cultural transformations, organizations will be more willing to prioritize the key credentials necessary to start, and maintain, an efficient DevOps practice.

    — Tim Curless