devopsy.kinsta.cloud

Author: Mike Vizard

  • CloudBees Harnesses Additional Cloud Bursting

    CloudBees Harnesses Additional Cloud Bursting

    At the DevOps World | Jenkins World 2019 conference, CloudBees announced that the latest version of its CloudBees Accelerator platform now supports cloud bursting to all three of the major public cloud service providers.

    CloudBees Accelerator makes it possible to distribute the build, quality assurance and testing cycles across a large cluster of inexpensive servers. Version 11.1 further extends that capability into the public cloud by adding support for Microsoft Azure and Google Cloud Platform, alongside existing support for Amazon Web Services (AWS).

    Company CEO Sacha Labourey said as organizations embrace multiple clouds for application development and deployment, continuous integration/continuous deployment (CI/CD) platforms will need to span hybrid cloud computing environments. Most organizations are not yet making use of multiple public clouds to develop an application, but they are increasingly relying on external cloud resources to augment the infrastructure resources they have available in on-premises IT environments.

    In addition to providing cloud bursting support for Azure and GCP, version 11.1 of CloudBees Accelerator provides support for Android Q, a forthcoming update to the widely employed mobile operating system due out in the third quarter of this year. Other new capabilities include support for the SSL and TLS cryptographic protocols and improvements to out-of-the-box support for Windows, including the ability to distribute and cache Visual Studio projects.

    Version 11.1 of CloudBees Accelerator also now makes it possible to apply CloudBees Electrify, a framework for optimizing the use of all available infrastructure in parallel, to accelerate build tools such as MSBuild and Scons. In addition, it provides improvements for the open source Yocto Project, an initiative from the Linux Foundation that streamlines the creation of Linux distributions for embedded systems. CloudBees Accelerator enables developers to at least triple the speeds of builds using BitBake build tools or Buildroot files and patches.

    As expansion occurs in both the volume and types of applications that organizations rely on to build and deploy faster, the need to rely more on automation also is increasing. Many DevOps processes that organizations adopt initially have been crafted manually. As organizations become more adept, however, it becomes apparent there is an opportunity to automate a wide range of lower-level processes. Frameworks such as CloudBees Accelerator essentially provide a layer of abstraction that enables organizations to devote more time and energy to writing application code.

    In fact, the next wave of organizations adopting DevOps is likely to benefit greatly from all the processes that the first wave of adopters helped automate by identifying best DevOps practices. It remains to seen just how automated the entire CI/CD environment can become with the rise of, for example, artificial intelligence (AI), but with each passing upgrade cycle, the accessibility of DevOps increases thanks primarily to advances in automation. Those advances not only make it easier to share best DevOps practices across an enterprise, but they also make it feasible for more organizations to embrace DevOps because the level of expertise required to master those DevOps processes declines.

    — Mike Vizard

  • CloudBees Looks to Drive Software Delivery Management

    CloudBees Looks to Drive Software Delivery Management

    At its DevOps World | Jenkins World 2019 conference, CloudBees today unfurled an early preview of the CloudBees Software Delivery Management (SDM) service, which applies analytics to metrics gathered by the company’s continuous integration/continuous deployment (CI/CD) platforms to enable organizations to optimize DevOps processes based on their business goals.

    CloudBees CEO Sacha Labourey said CloudBees is trying to take DevOps to another level by providing a unified view of all development activity and the impact any delay those projects might encounter will have on the organization.

    The CloudBees SDM service provides access to a Contributions dashboard to provide insights into work prioritization and dependencies that are hindering other projects, as well as an Efficiency dashboard to provide retrospective insights that can be used to improve development going forward.

    In addition, the CloudBees SDM service surfaces suggestions and alerts based on a policy and rules-based engine that identifies issues that warrant deeper investigation, such as code that doesn’t comply with a regulatory compliance mandate.

    There’s also an integrated feature flag management that enables DevOps teams to manage delivery and rollout of application features based on business and operational metrics.

    Finally, the CloudBees SDM service provides access to a Product Hub module, which provides visibility into all the data, resources, development and delivery activity around a specific product, and a Value Stream Management module, through which additional business insights relating to feature contributions and the overall status of a specific project are surfaced.

    Labourey said the CloudBees SDM service initially will be available as a cloud service, but the company expects to make an on-premises edition available as well.

    The goal is to provide IT leaders with a framework for managing multiple development teams that roughly equates to the capabilities a customer relationship management (CRM) application provides managers of sales teams, which should make it easier for organizations to identify best DevOps practices that should be shared across the organization, said Labourey. DevOps practices have been adopted unevenly across many organizations. The CloudBees SDM platform goes further than legacy approaches to software development lifecycle (SDLC) platforms in that it also makes it easier to identify what impact DevOps processes also are having on the business, he said.

    Longer-term, Labourey also noted the CloudBees SDM platform will act as the mechanism through which machine and deep learning algorithms will be applied, once a critical mass of data is acquired.

    CloudBees envisions its SDM service being used as a tool to coach developers on how to build better code faster. However, there always will be organizations that will make use of any SDLC platform as a vehicle primarily employed to drive higher levels of developer productivity, noted Labourey.

    Whatever the motivation for adoption, advances in analytics are transforming the way every process is managed. Software development is no exception; it’s one of the first job functions where advanced analytics most likely will be applied aggressively.

    — Mike Vizard

  • CircleCI Adds Security Orbs to CI/CD Platform

    CircleCI Adds Security Orbs to CI/CD Platform

    CircleCI has extended the reach of its automated package manager, known as orbs, to cybersecurity software that can be integrated into a pipeline constructed within the company’s namesake continuous integration/continuous deployment (CI/CD) platform.

    Mike Stahnke, vice president of engineering for CircleCI, said extending orbs into the realm of cybersecurity will make it much easier for organizations to embrace best DevSecOps processes.

    Designed to run on Amazon Web Services (AWS) and Google Cloud, the first set of orbs are being created by seven third-party cybersecurity vendors, including Alcide.io, NeuVector, Snyk, WhiteSource, Aqua Security, Anchore, Contrast Security, Probely and Twistlock, which is now part of Palo Alto Networks.

    CircleCI has been making use of orb package managers to make it easier to integrate a wide variety of functions within a CI/CD pipeline. Thus far, approximately 900 orbs have been developed for the CircleCI platform. Stahnke said the goal is to give DevOps teams the option of employing orbs instead of having to manually implement tasks such as secrets management, vulnerability scanning or policy enforcement into DevOps workflows.

    Stahnke said CircleCI doesn’t envision every element of a pipeline will become an orb; there will be instances where DevOps teams will want to exercise more granular control over some aspect of the pipeline. There are, however, going to be many situations in which DevOps teams won’t want to integrate the same functions manually over and over again.

    CircleCI expects orbs will prove especially useful in advancing the adoption of best DevSecOps processes because many of the controls that need to be implemented are the same across multiple pipelines, said Stahnke. By making it easier to incorporate cybersecurity software within a pipeline, DevOps teams will not have to sacrifice speed and agility to ensure security.

    CircleCI orbs

    Most organizations today are just starting down the DevSecOps path. Adoption of DevOps processes in many cases has been uneven at best. Trying to incorporate cybersecurity teams within those processes to ensure higher levels of security is the next great challenge. However, given the chronic shortage of cybersecurity professionals, cybersecurity functions within a DevOps pipeline somehow must be included automatically. In most cases, cybersecurity teams will continue to define policies and controls that increasingly are implemented by developers. Cybersecurity teams, however, still will need to validate that those controls have been implemented and tested before an application gets deployed in a production environment. Cybersecurity teams will then make developers aware of any vulnerabilities they’ve discovered and teams can decide to address them at whatever next stage of the development process they deem appropriate.

    Of course, DevSecOps also means cybersecurity teams will have to learn to trust developers. Historically, that’s been problematic because many cybersecurity professionals have tended to view developers as the primary source of the cybersecurity problem. Nevertheless, the more vulnerabilities that get addressed before an application is deployed in a production environment, the better off everyone involved in building, deploying and securing that application will be.

    — Mike Vizard

  • OverOps Integrates AI Code Analyzer With CI/CD Platforms

    OverOps Integrates AI Code Analyzer With CI/CD Platforms

    At the DevOps World | Jenkins World 2019 conference, OverOps announced it has integrated its namesake tools for analyzing Java and Microsoft .NET code at runtime with a variety of continuous integration/continuous deployment (CI/CD) platforms, including Jenkins, JetBrains TeamCity, Atlassian Bamboo and Pivotal Concourse.

    Eric Mizell, vice president of solution engineering for OverOps, noted that the more errors that are discovered by DevOps teams early in the development cycle, the less technical debt organizations must address after an application is deployed in a production environment. By pushing testing to further to the left of the application development process, the less troubleshooting will be required later on, he said.

    OverOps employs predictive analytics and machine learning algorithms to identify new, increasing, resurfaced and critical errors in a release. It then generates a code quality report that ranks all severe issues likely to impact end users and application functions. By integrating OverOps within the CI/CD pipeline, DevOps teams can use those reports to determine whether code is safe to promote or automatically block unstable releases from moving forward.

    In addition, because the machine learning algorithms surface the true root cause of an issue, DevOps teams can more efficiently remediate issues by routing code back to the development team responsible for all the issues that are being created downstream.

    Making testing an integral part of the CI/CD process not only tightens the relationship between developers and testers, but also in many cases enables developers to test their own code before submitting it for review.

    Mizell said the need to shift testing to the left has become more critical as customer tolerance for application errors is low, especially in use cases involving mobile applications—consumers are especially unlikely to give a mobile application a second chance after they’ve encountered an issue.

    In an ideal world, of course, testing tools that make use of machine learning algorithms would be employed to coach developers in a way that enables them to develop reliable code more consistently and faster. However, some organizations will use tools that leverage machine learning algorithms to identify developers who are not meeting expectations. That weeding out process is likely to begin much earlier in the application development life cycle as more advanced testing tools are embedded within CI/CD environments. Those tools won’t eliminate the need for developers and testers, but they do promise to increase dramatically the rate at which quality applications can be built and deployed at an industrial scale. Technical debt may never be completely eliminated, but at the very least the rate at which that technical debt is being accumulated should substantially decline.

    It may be a while longer before machine learning algorithms and other forms of artificial intelligence (AI) are employed pervasively across DevOps processes. In most cases, those algorithms will help developers write better code faster. However, it’s also apparent there will be other algorithms at work that one way or another ensure developers will have fewer opportunities to make mistakes in the first place.

    — Mike Vizard

  • BMC Extends DevOps Reach to Db2 Databases

    BMC Extends DevOps Reach to Db2 Databases

    BMC Software is extending the reach of its campaign to bring DevOps to the mainframe to the IBM Db2 databases that run on the venerable platform.

    John McKenny, senior vice president, ZSolutions Strategy and Innovation at BMC, said BMC AMI DevOps for Db2 makes it possible for DevOps teams to automate changes to the Db2 schemas as part of a pipeline being employed on a Jenkins continuous integration/continuous development (CI/CD) platform.

    As part of its effort to bring DevOps processes to the mainframe, McKenny said BMC is trying to bridge the historical gap between DevOps teams and database administrators. Many DevOps teams have tried to bypass DBAs that they often perceive to be to slow to keep up with agile development processes. In mainframe environments, however, Db2 databases remain the primary source of data for applications. BMC AMI DevOps for Db2 automatically discovers and determines database schema change requirements, streamlines the review and approval process and implements those changes, he said.

    BMC AMI DevOps for Db2 is part of a portfolio of BMC automated mainframe intelligence (AMI) tools that leverage a policy engine to enforce best practices for database schemas. Those tools play a critical role in enabling organizations that continue to rely on mainframes to capture those best practices at a time when many of the IT professionals who defined those best practices are retiring, said McKenny, adding BMC will evaluate whether it will add support for other mainframe databases such as IMS based on demand.

    It’s unclear how much or even whether organizations that rely on mainframes are embracing best DevOps processes. Providers of tools for mainframe environments such as BMC are betting digital business transformation initiatives will require those organizations to replace their current application development and deployment tools and processes with DevOps processes, which are more agile. The challenge, however, is overcoming the perception that existing waterfall approaches to application development and deployment result in more reliable software. As a result, many organizations that rely on mainframes are trying to determine which methodology to employ based on the nature and criticality of the application workload.

    At the same time, BMC is investing in various forms of artificial intelligence (AI) to automate IT operations, otherwise known as AIOps. Naturally, BMC is not the only provider of IT management frameworks with similar ambitions, but it contends that after decades of providing tools to manage both mainframe and distributed computing environments, it’s in a better position than its rivals to aggregate all the data required to drive the models that are at the core of any AIOps platform.

    Of course, it remains to be seen to what degree IT organizations are comfortable with AIOps. Beyond the perceived threat to their jobs, many IT professionals are skeptical AI models are sophisticated enough to automate complex IT processes reliably. The one thing that is clear is that with the simultaneous rise of DevOps and AIOps, the way IBM platforms have been managed is about to change utterly.

    — Mike Vizard

  • VMware Looks to Accelerate App Migration to the Cloud

    VMware Looks to Accelerate App Migration to the Cloud

    VMware this week expanded the scope of its cloud migration efforts to include workloads that aren’t running on its virtual machine. VMware HCX leverages replication and virtual machine mobility technology to make it easier to automate the migration of either VMware-based workloads or those running on rival platforms to the latest generation of VMware platforms.

    Previously, VMware only offered this migration capability as part of larger services offerings that were focused on only migrating workloads running on VMware platforms. Allwyn Sequeira, senior vice president and general manager of the Hybrid Services Business Unit at VMware, said VMware HCX not only extends that capability to orphaned platforms such as Open Stack and Kernel-based Virtual Machines (KVM), it also marks the first time VMware has offered this migration tool as a separate, standalone offering.

    Sequeira said VMware HCX provides an opportunity for organizations that have committed to a platform other than VMware to reconsider their options. VMware HCX provides a way to migrate thousands of virtual machines at a level of scale that significantly reduces the amount of time to make that transition, he said.

    In some cases, Sequeira said customers have already employed VMware application migration tools to lift and shift thousands of virtual machines into cloud computing environments such as Amazon Web Services (AWS) in a few weeks. Overall, the rate at which those migrations are occurring has doubled every quarter for the last six quarters, he added.

    VMware HCX is based on virtual machine mobility technology developed by VMware combined with a similar cross-platform workload migration technology the company gained in its acquisition of CloudVelox early last year. VMware HCX now provides organizations with the option of migrating virtual machines programmatically via an application programming interface (API) or via a graphical user interface (GUI).

    VMware HCX

    There exist multiple tools for migrating workloads into any number of cloud computing platforms. Many organizations are also taking advantage of Docker containers to encapsulate entire workloads so they can run on any platform. Deciding which path to pursue most often comes down to the level of integration required with the various services available on the targeted cloud migration platform.

    In the meantime, as workload migration tools become more sophisticated, decisions regarding where workloads need to run are becoming less concrete. Competition for new workloads between platform vendors has always been especially fierce, and it used to be that once an IT organization made its decision, it was unlikely it would change its mind, given the effort needed to swap one platform out for another. Now, however, as application workloads become more portable, competition among platform vendors will only increase as they seek to convince IT organizations to shift existing workloads onto a different platform.

    In general, that increased level of competition bodes well for DevOps teams, who are usually among the strongest advocates for change within any IT environment. The issue now is deciding which platforms within those already-cluttered IT environments make the best candidates for rationalization.

    — Mike Vizard

  • GitHub Actions Advances Automation Strategy

    GitHub Actions Advances Automation Strategy

    GitHub Actions, a set of application programming interfaces (APIs) through which DevOps tools can automate workflows, is now available in beta.

    Previewed last year at the GitHub Universe event, GitHub Actions is intended to provide not only a way to automate responses to events occurring within a GitHub Repository but also share those workflows across multiple DevOps teams, said Max Schoening, senior director of product design for GitHub.

    Actions are based on YAML files, which makes it possible to write them in JavaScript or other programming languages or package them up as a set of containers. In either instance, they are designed to interact with the full GitHub API and any other public API.

    In addition, higher levels of automation enabled by GitHub Actions should make it more feasible for DevOps teams to test multiple versions of a project in parallel as workflows written in code replace manual processes, said Schoening.

    As more manual processes become automated, the number of IT teams who are intimidated by DevOps processes today should begin to decline. Organizations also should be able to apply best DevOps practices more consistently across multiple teams. Too often today the DevOps practices within the same organization tend to vary widely. Schoening also noted that given the open source history of GitHub, organizations will be able to see how workflows have been created for popular open source projects and then copy them.

    In addition, Schoening said the arm of Microsoft will continue to invest in analytics that will surface workflow recommendations that can be applied to any project regardless of the language employed or the platform on which it’s destined to be deployed.

    On one level, DevOps is all about a ruthless commitment to automation. But when automation goes wrong at scale, it can be extremely problematic. Rather than relying on “black box” approaches to automating processes, a truly open source approach to automation makes it possible for DevOps teams to see how a process is being automated and then extend it if they so choose, said Schoening. To help address the concern, GitHub Actions also provides access to live logs to provide real-time feedback as builds run, which Schoening said makes it easier for DevOps teams to debug automations created using GitHub Actions.

    It’s too early to say just how automated DevOps processes will get. There’s an emerging school of thought that contends the goal is to make it feasible for developers to spend 100% of their time writing business logic. It’s not clear whether that goal is achievable anytime soon, but progress is made with each update to continuous integration/continuous development (CD/CD) platforms. As complementary advances in machine learning algorithms and other forms of artificial intelligence (AI)—otherwise known as AIOps—occur, it’s apparent many manual DevOps processes will fall by the wayside.

    In the meantime, the workflows that make up any DevOps process should become increasingly sophisticated as advances in automation span everything from hybrid cloud computing environment to internet of things (IoT) deployments. The issue soon may not be how cumbersome any DevOps workflow is, but rather the potential limits of the imagination applied to automating them.

    — Mike Vizard

  • CollabNet VersionOne Advances End-to-End DevOps Strategy

    CollabNet VersionOne Advances End-to-End DevOps Strategy

    At its Agile 2019 conference, CollabNet VersionOne announced it plans to extend the capabilities of its software delivery and management platforms later this month as part of an effort to provide organizations with more visibility into how changing software development project schedules impact the business.

    Company CEO Flint Brenton said updates to the VersionOne value stream enterprise management platform will include a revamped user interface that provides more visibility into events occurring within the Continuum continuous integration (CI) platform.

    Brenton also said those updates will further advance adoption of agile frameworks such as the Scaled Agile Framework (SAFe), a prescriptive approach to combining best agile development and DevOps practices.

    While organizations may opt to employ VersionOne in combination with other CI/CD platforms, Brenton said CollabNet VersionOne provides a more comprehensive understanding of the impact changes to software development schedules will have on the business.

    As part of that effort, CollabNet VersionOne also announced VS Exchange, a marketplace for custom and preconfigured Continuum and VersionOne extensions and workflows, and enhancement to the Continuum TestDrive component within the company’s implementation of Continuum that streamline provisioning.

    With more organizations than ever starting to appreciate how dependent they are on software, Brenton said business leaders are now looking to exercise more control over software development projects. It’s no longer enough to generate more code, he noted; rather, DevOps teams are now being asked to generate more reliable code that has the greatest impact on the business faster. CollabNet VersionOne enables organizations to achieve that goal by providing a management platform in the form of VersionOne that is layered on top of Continuum.

    CollabNet VersionOne is now taking part in a race to infuse more business analytics into a software development lifecycle (SDLC) platform. While SDLC platforms have typically been employed to gather technical metrics, organizations now want to correlate that data against business metrics.

    Less clear right now is whether having access to business metrics will influence the selection of one CI/CD platform over another. Over time, the expectation is that various forms of business intelligence capabilities will be a standard capability of the platform, especially as IT leaders continue to assume larger business responsibilities in the age of digital business processes.

    It may be a while yet before business and IT roles start to converge. In the meantime, CollabNet VersionOne is clearly betting there will be a lot more collaboration between these two camps going forward. In many ways, the DevOps best practices that organizations have adopted to become more agile are about to be extended to the business processes enabled by software. Savvy business leaders will realize their ability to meet financial goals for any given quarter is tied to the timely manner in which new digital customer experiences are enabled. In fact, there may come a day when IT organizations are able to deliver software updates faster than most businesses will be able to consume it.

    — Mike Vizard

  • Twilio Adds DevOps Tool to Invoke Communications Services

    Twilio Adds DevOps Tool to Invoke Communications Services

    At its annual SIGNAL conference, Twilio today launched an initiative intended to make it easier to embed a variety of communication services within an application in the context of a DevOps process.

    Quinton Wall, senior director of developer marketing at Twilio, said the open source Twilio Command Line Interface (CLI) tool, now available in beta, will make it possible to incorporate Twilio cloud services within a larger DevOps toolchain.

    Twilio provides developers will access to a range of SMS, audio and video services that can all be incorporated into applications via application programming interface (API) calls. The pipelines created using those APIs now can be stored and shared via GitHub.

    The CLI tool also makes it possible to extend those services via Plugins, said Wall. In addition, DevOps teams can invoke an existing serverless computing capability from Twilio to invoke the company’s services using functions, added Wall.

    It’s not clear to what degree cloud services such as Twilio will be invoked using serverless computing frameworks going forward. Many of the capabilities that developers once were required to embed in their applications are set to become external services that applications call when needed by launching a function. While that approach makes the application more efficient, it puts additional pressure on IT teams to manage all the calls to various serverless computing frameworks within the context of already complicated DevOps pipeline.

    While serverless computing frameworks are still an emerging IT platform, the rate at which serverless computing frameworks are being adopted suggests the day when they are commonly included with a DevOps toolchain is not very far off.

    In the meantime, Twilio is clearly hoping that by making its communications services easier to invoke within the context of a DevOps toolchain will increase consumption. Twilio has long exposed REST APIs, but the CLI tool will make it easier for organizations to standardize on Twilio communication services across a range of applications. By exposing those services via APIs and a CLI tool, Twilio is betting that the days when end users opened a separate application to communicate are numbered. Instead, most users will invoke communications services within the context of, for example, a business intelligence application that is already open. That approach also eliminates the need to invest in dedicated network hardware to run unified communications applications that, from an API perspective, are often more difficult to invoke programmatically.

    As DevOps processes become more widespread, it will be interesting to see how many other providers of cloud services start to routinely make available CLI tools. Arguably, any provider of a cloud service that doesn’t make a CLI tool available will find themselves on the outside of a DevOps process looking in. Service providers that provide a CLI tool will be preferred among organizations that embrace best DevOps practices. In fact, the challenge DevOps teams soon may face is not whether there is a CLI tool available, but rather determining which of the many available best fits within the DevOps processes they have adopted.

    — Mike Vizard

  • CircleCI Extends CI/CD Reach to Windows Platforms

    CircleCI Extends CI/CD Reach to Windows Platforms

    CircleCI today announced it will make available its continuous integration and continuous deployment (CI/CD) platform available on a variety of Windows platforms.

    Matt Wyman, vice president of product for CircleCI, said the decision to support Windows stems from recent Microsoft DevOps initiatives, most notably its move to acquire GitHub. As Microsoft invests more time and energy promoting best DevOps practices, demand for CI/CD platforms running on-premises or in the Microsoft Azure public cloud will escalate sharply, said Wyman.

    The Windows environment on CircleCI also includes support for Docker Engine – Enterprise for Windows workflows and all Windows jobs run isolated on a virtual machine. Each new job uses an environment that gets created just in time and gets destroyed once the job finishes running. That approach is intended to ensure both build reproducibility and the security of the code, data and secrets stored in a CI environment. All CircleCI features such as caches, Workspaces, approval jobs and Contexts are now being made available for Windows jobs.

    Wyman said CircleCI now expects organizations to extend the same software development lifecycle processes for building and deploying both Windows and Linux-based applications. The ability to leverage the same pipelines within the context of a common CI/CD platform spanning both environments will help narrow the time and effort required today to build Windows applications, he added.

    Currently, it’s unclear whether a common set of processes for building and deploying applications in Windows and Linux environments might foster greater collaboration within IT organizations. Linux and Windows teams don’t tend to interact much. However, as more organizations look to apply repeatable processes that enable them to build more reliable software faster, the need to standardize DevOps processes has become apparent. Of course, Circle CI isn’t the only provider of a CI/CD platform looking to take advantage of that emerging hybrid cloud computing opportunity.

    It’s also worth noting that providers of platforms such as Microsoft and Red Hat are also promoting their own approaches to software development lifecycle management. Organizations need to decide how much they want to rely on the tools and processes made available by platform vendors instead of a CI/CD platform that integrates DevOps processes across multiple platforms. To fight that battle, CircleCI last month revealed it has raised another $53 million in funding. At that time, the company noted that the total monthly job count on its platform stood at 30 million, up from 7 million in January 2018.

    Regardless of the path chosen forward, organizations increasingly need to build and deploy software on multiple platforms. The challenges associated with managing those processes are nothing less than considerable. The issue IT leaders will need to determine first is how much they want to drive unification of software development from the top down versus simply providing a common set of tools and platforms that their teams will (hopefully) gravitate toward.

    — Mike Vizard