devopsy.kinsta.cloud

Tag: DevOps workflows

  • VMware Preps Generative AI Assistants to Automate IT Workflows

    VMware Preps Generative AI Assistants to Automate IT Workflows

    At its VMware Explore 2023 conference today, VMware previewed what will become a suite of intelligent assistants that use generative artificial intelligence (AI) to automate the management of a wide range of IT tasks.

    Krish Prasad, senior vice president and general manager for cloud infrastructure at VMware, said VMware will eventually build out assistants for managing individual platforms such as VMware vSphere and the integrated VMware Cloud Foundation (VCF) platform through which the company aggregates those offerings into a single platform.

    VMware is creating those assistants, also known as co-pilots, using multiple large language models (LLMs) that the company uses to train AI models using code written by site reliability engineers (SREs), said Prasad. That approach ensures that the recommendations being made along with the code generated are of the highest quality, he added.

    That approach will enable IT teams to identify configuration drift that might be adversely impacting performance or that could create a cybersecurity risk, for example, noted Prasad. The first of those assistants is being made available in beta for VMware Tanzu, a platform based on Kubernetes. VMware is also building an assistant for its NSX virtual networking software that analyzes security events to generate policies and rules that can be applied to firewalls in real-time as threats are identified.

    It will then be up to each IT team to decide whether to implement those recommendations. Over time, it’s clear that the management of IT infrastructure is going to become increasingly automated as confidence in those recommendations increases, he added. In fact, the ultimate goal is to fulfill the promise of ‘lights-out’ IT management, said Prasad.

    In effect, advances such as these will lead to the democratization of DevOps workflows as it becomes simpler to manage IT infrastructure at scale. IT organizations will be able to invest more resources in building and deploying applications rather than hiring specialists to manage IT infrastructure, noted Prasad.

    In fact, the pace at which applications are built and deployed should dramatically increase in the months ahead, Prasad predicted.

    The rise of generative AI creates a unique opportunity for IT teams to become more relevant than ever to their organizations. It will soon be possible to build and deploy a wide range of distributed applications capable of processing and analyzing data at the point where it is created and consumed.

    While generative artificial intelligence (AI) has captured the popular imagination, it’s becoming apparent that multiple forms of AI will soon be used together to automate DevOps workflows at levels of unprecedented scale.

    Machine learning algorithms, of course, are already used by many organizations to automate everything from analyzing log data to identifying security issues to surfacing patterns in tests made using multiple regression, function and unit testing tools. With the rise of generative AI, it is now possible to automatically generate code and create summaries of reports that multiple stakeholders can more easily understand. Generative AI doesn’t replace the need for previous use cases involving machine learning algorithms. Instead, generative AI makes use of a form of deep learning algorithms to create different types of AI models.

    As a result, DevOps workflows will soon be invoking multiple classes of AI models to automate workflows in ways that should enable IT teams to automate processes at unprecedented levels of scale.

  • Agile Planning With Generative AI

    Agile Planning With Generative AI

    Generative AI will eventually impact the entire DevOps life cycle from plan to operate. I started as a developer but have been a product manager for most of my career; for me, the ‘Holy Grail of DevOps’ would be one where product managers (PMs) and business analysts (BAs) were able to define a future state of a business process and press a button to deliver it without any developers, designers or testers involved.

    This dream is not practical in the near term and is not really desirable in the long term, either. PMs and BAs are good at understanding the needs of users and translating them into features but aren’t interaction designers. AI may be able to generate code and tests, but the software architecture for both will still require a deep understanding of the system to structure the solution properly, especially in enterprise SaaS development. So my dream is to build a team where the BAs can define the changes and a small team of very talented architects and interaction designers can realize those changes in 10% of the time it takes today without requiring a large team to implement the details. This is similar to what has happened in manufacturing where robots and numerically controlled machines are able to do the heavy lifting with the help of operators.

    Planning is Key

    When generative AI is actually building the solution, proper planning will be the entire key to success. A well-documented, well-thought-out plan will enable the AI to finish most of the heavy lifting. So the majority of the focus for the dream team should be to get the plan right and to document it at just the right level of detail. Just like I was taught by my first Agile coach 20 years ago, when it comes to documentation, you need just enough just in time.

    In enterprise SaaS platforms like Salesforce.com and ServiceNow, the business starts with a newly implemented system in some initial implementation and then incrementally customizes this software to better meet their needs over time. So, instead of thinking about building a system from scratch, we must think of digital transformation as the continuous improvement of an existing system over time. That means the AI must start with a good model of the

    ● Existing business processes,
    ● Metadata configuration of the system and
    ● Dependencies between the settings.

    Development in the New World

    What does this mean in practice? Let’s look at a day in the life of the dream team.

    The BA will start by telling the AI what changes are desired at a high level. The AI will help refine the requirements by filling in missing details. This will happen through an iterative process of expanding, refining and summarizing until the requirements are clearly defined. Just as lint tools check source code today, the AI will examine the requirements to ensure the user stories are complete, with acceptance criteria well defined. During this process, the AI will do a detailed dependency and impact analysis to provide a heads-up to the BA when there are any unwanted side effects.

    This refinement session will be more of a conversation between the BA and the AI than a one-sided writing session. After several iterations, a complete set of user stories will be created with all of the necessary details spelled out.

    Once the requirements are complete, the BA will be joined by a user interaction designer and software architect.

    The interaction designer will define the interaction spec through a combination of natural language description of the new processes and a functional prototype. Both of these elements will be created and refined through interactions with the generative AI. Prototypes will no longer be simple graphic artifacts to be coded by front-end engineers. The AI will generate a working prototype in the framework of your choice on demand through a combination of verbal requests and traditional point-and-click.

    They will review the plan and begin designing the solution’s architecture which will result in a natural language software spec that documents the data model changes and high-level specifications for the classes that make up the solution. It is likely that the data model changes will be created in a dev environment on demand, with the ERD updated to reflect the new model.

    Depending on the type of changes, the architect and interaction designer may collaborate and iterate on the specs until the “how” is well defined. When the design is ready, the dream team will meet to review the design and sign off on the approach.

    Generate and Iterate

    Once the plan is approved, it’s time for the AI to generate a first-pass solution. We hope and expect that generating the solution will be something that happens in minutes. In this scenario, the dream team will take a coffee break and then come back to the meeting room to review the working solution.

    There is nothing like playing with the actual solution to remind you of the edge cases you forgot or to realize how tedious it is to actually use a new feature. But that’s okay because the team can quickly update the requirements to account for these changes and push the generate button again.

    In fact, they can tinker to their heart’s content. But like all great artists, they must decide when it is good enough to ship.

    In the near term, we will not be able to blindly rely on generative AI, so the architects will have to do code reviews, just as they do today with junior developers. Likewise, the AI may not understand all of the possible dependencies in a system. So there will be a transition period where the process is semi-automatic.

    Eventually, the notion of a two-week sprint will seem anachronistic and a daily cycle of define and release to production will be commonplace. Members of the dream team will spend more time worrying about the high-level usability and effectiveness of their designs and less time struggling with actual implementation, which should make their jobs much more rewarding and the work product much better. I am looking forward to it.

  • Survey Sees Value But Limited Understanding of Platform Engineering

    Survey Sees Value But Limited Understanding of Platform Engineering

    Platform engineering is emerging as method for managing DevOps at scale, but a survey suggested that many organizations are still not clear on the concept.

    A survey of 100 DevOps engineers, platform engineers, developers, site reliability engineers and IT managers conducted by Civo, a cloud service provider, found 85% of respondents work for organizations that have partially or fully embraced a DevOps culture, with nearly two-thirds (65%) identifying platform engineering as the next evolution of DevOps. Nearly, a third (30%) of respondents work for organizations that are already currently evaluating whether they should adopt platform engineering.

    Overall, the survey found 50% of the respondents at organizations that have adopted platform engineering reported improved standardization, with 43% also seeing faster product delivery.

    However, only 41% of the respondents in DevOps roles that were familiar with platform engineering said they had a moderate to high level of familiarity with the concept.

    Saiyam Pathak, director of technical evangelism at Civo, said the survey makes it clear that, in terms of understanding how platform engineering best practices should be implemented, there is need for more clarity. Many organizations initially adopted DevOps to spur innovation, so any approach to centralization shouldn’t come at the expense of developer productivity, he noted.

    Historically, DevOps adoption of DevOps workflows in most organizations has been driven from the bottom up. As a result, it’s fairly common for multiple application development teams within an organization to have adopted multiple DevOps platforms to manage workflows. Advocates for platform engineering are making a case for eliminating many of those redundant platforms in favor of, for example, a single continuous integration/continuous delivery (CI/CD) platform that serves as a corporate standard.

    At the core of those efforts is the assumption that centralization will reduce costs by eliminating redundancy. At a time when more organizations than ever are sensitive to the cost of IT, there is always going to be a natural tendency to rationalize platforms. Challenges arise, however, when centralization results in a loss of flexibility. Many of the teams adopt DevOps because they want to be able to add and replace tools as they see fit. If there is a corporate standard that narrows their tool options, those teams may start to look for ways to do an end-run around the corporate standard.

    The philosophical IT battle between advocates for centralization and proponents of decentralization has been around since the first PCs showed up in enterprise IT environments. As always, organizations need to strike a balance between both extremes, said Pathak.

    It’s not clear how much platform engineering might accelerate the pace at which applications are built and deployed, but the total cost of DevOps should decline as various tools and platforms are consolidated. The challenge, of course, is that centralizing DevOps workflows is likely to disrupt the application development workflows on platforms that may about to be rationalized.

    Regardless of what platforms become the corporate standard, the one thing that is certain is the cultural challenges associated with successfully making that transition will loom large within most organizations.

  • Mendix Embraces DevOps for Next Era of Low-Code App Development

    Mendix Embraces DevOps for Next Era of Low-Code App Development

    Mendix, a subsidiary of Siemens, today updated its namesake low-code application development platform to add support for DevOps workflows and make it simpler for developers to compose applications and embed artificial intelligence (AI) capabilities.

    Sheryl Koenigsberg, vice president of product marketing for Mendix, said Mendix 10 makes it possible to use Git repositories for version control along with Mendix Pipelines, currently in beta. Mendix Pipelines is a continuous integration/continuous delivery (CI/CD) environment that will be embedded in the low-code platform. In addition, Mendix is adding support for Webhooks that can be used to integrate Mendix with existing CI/CD platforms.

    Mendix has also added a Solutions Kit, now generally available, to make it possible to customize applications in a way that ensures those changes will be preserved as application environments are upgraded.

    There is also now a Portfolio Manager tool to track projects and a connector for integration with the Jira project management software from Atlassian.

    Later this year, Mendix will also make generally available Adaptation Insights to provide insights into application extensions.

    In the future, developers will be able to leverage an extensibility framework to tailor the Mendix Studio Pro integrated development environment (IDE) by adding their own plugins, wizards, editors and third-party integrations. Later this year, Mendix 10 will also add, in beta, a version of its Studio Pro IDE for MacOS.

    The Mendix approach to composability is also being extended to incorporate AI. The company is adding Mendix Assist, a bot that generates validation logic for data entry. This module is the second AI capability that Mendix has developed after previously previewing Mendix Chat, a tool based on a large language model created using Mendix data that will be integrated into the Mendix integrated development environment (IDE) later this year. Mendix Assist will be incorporated into Mendix Chat.

    Mendix is also developing additional LLMs for creating applications and will as part of its commitment to composability plans to make it possible to integrate third-party AI services and LLMs into the Mendix Runtime to create “smart apps.” AI models will be converted to the Open Neural Network Exchange (ONNX) format, an open standard for machine learning models, to provide that capability.

    In addition, Mendix is adding support for event-driven architectures via Business Events and an Event Broker, to build more complex applications.

    Other capabilities being added to Mendix 10 include updated REST and database connectors, support for visual data filters, rich properties and design controls, a Start from Spreadsheet tool, end user survey tools, a PDF document generator and a revamped set of governance and risk assessment tools.

    Finally, Mendix is adding a Terraform module to make it simpler to deploy its low-code platform on the Amazon Elastic Kubernetes Service (Amazon EKS) in addition to providing a reference implementation for building private clouds to develop applications using the Mendix Cloud service.

    As AI-infused low-code applications are developed faster, it’s not clear to what degree organizations are prepared to embrace the inevitable disruption that will ensue. However, the one thing that is clear is that the DevOps workflows used to deploy these applications at scale will soon be put to the ultimate test.

  • System Initiative Employs Modeling to Reinvent DevOps

    System Initiative Employs Modeling to Reinvent DevOps

    System Initiative (SI) today made available in private beta a platform that creates simulations of IT environments. The platform leverages a built-in framework to generate the code needed to update an application environment.

    Fresh from raising $18 million in funding, SI CEO Adam Jacob said the ultimate goal is to provide a level of abstraction for DevOps environment that eliminates much of the complexity that creates bottlenecks in DevOps workflows.

    For all intents and purposes, DevOps is fundamentally broken; there are too many manual processes that need to be performed, he added. The SI platform represents an ambitious effort to reimagine how DevOps processes are constructed and maintained, said Jacob.

    At the core of that effort are models of IT environments created by the SI platform that are accessed via visual interface. The automation framework built into the platform then uses the relationships between models to infer configuration dynamically and then automatically generate TypeScript code that a DevOps team can apply to automate a task.

    Feedback loops are also provided in real time to provide insight into the viability of a configuration and eliminate the need for no state files to track and no ‘plan’ versus ‘apply’ stages.

    As more organizations realize how dependent they are on software to drive digital processes, many of them are looking to improve the productivity of developers and the DevOps teams that support them. After a wave of initial progress, many DevOps teams find themselves supporting DevOps workflows using custom code that varies widely in quality. SI is making a case for a digital twin platform that generates a set of code that can be applied more consistently, rather than relying on a DevOps engineer to write code.

    Ultimately, the goal is to launch a new DevOps era to eliminate most of the silos that slow down application development and deployment, noted Jacob. In fact, one of the reasons few organizations today fully automated DevOps across the application development and deployment process is that it’s simply too difficult to achieve using legacy tools and DevOps platforms, he added.

    A recent survey conducted by the Continuous Delivery Foundation (CDF), for example, found only 22% of respondents are using CI and CD approaches to automate all building, testing and deployment of code in a production environment. Instead, many organizations are using a combination of DevOps and waterfall processes to manage application development and deployment.

    It’s not clear how many organizations are willing to fundamentally change the way they have implemented DevOps. But at a time when more organizations are moving to centralize the management of DevOps, many of them are evaluating their options, at the very least. The issue, of course, is that multiple DevOps teams within the same organization have committed to disparate platforms. Enticing them to centralize on a common platform will require not just a compelling technical advantage but also a significant amount of political capital.

  • Spotify Adds More Plugins for Backstage Developer Portal

    Spotify Adds More Plugins for Backstage Developer Portal

    Spotify this week added additional plugins for its open source Backstage platform that is used to build developer portals. The new plugins make it simpler to address role-based access and access Insights, a tool from Spotify that tracks Backstage usage trends.

    In addition, Spotify is also enhancing a Soundcheck plugin for Backstage that is used to visualize and track development of software components. Forthcoming capabilities include a no-code interface that makes it possible to programmatically create checks of code without writing any code.

    DevOps teams will also be able to view, export and understand how teams and components are doing compared to established best practices and monitor trends, graphs and historical views, and receive notifications when levels change.

    Finally, Spotify is committing to adding additional integrations with third-party tools and platforms such as Snyk, Sonarqube and the open source Argo continuous delivery (CD) platform.

    There are now five plugins available via a Spotify Plugins for Backstage subscription service, and Spotify said more are planned.

    Meg Watson, a group product manager at Spotify, said Backstage has been gaining traction in cloud-native application environments that are especially challenging to develop using multiple tools. Because of Backstage, developers are not only more productive but turnover has also been reduced because developers are provided with a better experience, she noted.

    There’s a lot more focus than ever on developer productivity, which Backstage addresses by creating a catalog of blueprints that developers can readily consume rather than requiring them to build these capabilities themselves multiple times over. The goal is to create scaffolds that developers can consistently reuse across multiple application development projects.

    Backstage was donated to the Cloud Native Computing Foundation (CNCF) and is now being advanced by contributions from multiple vendors. Much of that focus is on lowering the barrier of adoption for the platform, said Watson. Specifically, Spotify is working on a QuickStart for Backstage edition of the platform that is simpler to install, she said.

    In general, Spotify is trying to strike a balance between centralizing the management of DevOps workflows and the need to enable developers to define workflows that are natural to them versus ones that have been imposed on them, added Watson.

    It’s not clear to what degree Backstage will help fuel the adoption of a shift toward platform engineering to centralize the management of DevOps tools and platforms. The concept of a portal through which developers can self-service their own needs may not be new, but as an open source project, Backstage has made it simpler for many organizations to achieve that goal.

    Just about every DevOps team is now being asked to find ways to help improve developer productivity at a time when many organizations are trying to do more with fewer resources. Regardless of the motivation, however, it’s apparent that DevOps workflows are continuing to evolve and mature.

    In the meantime, DevOps teams would be well-advised to eliminate as many bottlenecks as possible before they negatively impact developer productivity.

  • Harness Acquires Propelo to Surface Software Engineering Bottlenecks

    Harness Acquires Propelo to Surface Software Engineering Bottlenecks

    Harness this week announced it has acquired Propelo, a provider of an analytics tool that identifies bottlenecks in software engineering processes. Terms of the acquisition were not disclosed.

    The Propelo offering will be made available as a module, dubbed Harness Software Engineering Insights, that organizations can choose within the company’s overall continuous integration/continuous delivery (CI/CD) platform.

    Scott Sanchez, chief marketing officer for Harness, said Propelo is unique in that all the integration required to collect data from a wide range of DevOps platforms is already baked into the tool. As a result, DevOps teams can instantly collect telemetry data from not just the Harness platform but also CI/CD platforms such as Jenkins, GitLab and Azure. In addition, there are integrations with more than 40 third-party tools, such as the Jira project management software from Atlassian.

    Those integrations enable the Harness Software Engineering Insights module to surface insights aligned with the DevOps Readiness Assessment (DORA) metrics from Google and the satisfaction, performance, activity, communication and efficiency (SPACE) frameworks.

    In an uncertain global economy, there is more focus than ever on increasing the productivity of DevOps teams, noted Sanchez. More organizations are going to be reluctant to hire as many full-time employees as they once did, so more attention is being paid to getting the most out of existing investments, he added.

    That focus on productivity will naturally lead to a re-examination of workflows to identify bottlenecks in DevOps workflows that, if eliminated, would help increase the pace at which software is being developed, said Sanchez. In some instances, the software development life cycle (SDLC) processes companies are using are as much as 20 years old, he noted.

    The acquisition of Propelo is the latest addition to a portfolio of DevOps tools designed to be deployed alongside existing platforms, noted Sanchez. Organizations that have been using platforms such as Jenkins are not going to rip and replace overnight, he added. The Harness portfolio is designed to be deployed alongside existing platforms to enable organizations to modernize their DevOps workflows in a much less disruptive way than rival DevOps platforms, said Sanchez.

    Harness initially developed a CD platform before acquiring Drone to add a complementary CI capability. It then acquired ChaosNative to add a chaos engineering tool, based on the LitmusChaos open source tool, that is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    It’s not clear how quickly organizations will modernize legacy DevOps platforms. Still, in many cases, workflows and pipelines that were designed for a different era of application development are not able to support the pace at which modern cloud-native applications are being developed. It will, of course, be up to each DevOps team to determine whether adding additional DevOps tools and platforms makes economic sense; application developers tend to naturally gravitate toward organizations that reduce as much development friction as possible.

    In an era where organizations are counting on developers to drive digital transformation initiatives, the underlying DevOps tools and platforms employed to build applications can easily make the difference between success and failure.

  • Atlassian Aims to Improve Collaboration With DevOps Teams

    Atlassian Aims to Improve Collaboration With DevOps Teams

    At an Atlassian Presents: WorkLife event today, Atlassian furthered its efforts to integrate the tools technology and business professionals use to manage processes.

    Erika Trautman, general manager and vice president of product for Work Management for All at Atlassian, said that as organizations increasingly rely on digital processes to engage customers, partners and employees, the need to facilitate collaboration across a diverse set of knowledge workers is becoming more pressing.

    As part of that effort, Atlassian is now making generally available a Smart Links capability within the Atlassian platform. Smart Links can be used to integrate both Atlassian applications such as Trello and Jira as well as third-party applications. That capability is now critical because there has been a Cambrian explosion of adoption of software-as-a-service (SaaS) applications that all need to be integrated into a common set of workflows, noted Trautman. Otherwise, each SaaS application environment becomes yet another walled garden that prevents any meaningful collaboration, she added.

    In addition, the company announced that Atlas, a directory that tracks projects and simplifies communications across teams using disparate applications, will become generally available next month. DevOps teams, for example, will be able to synchronize Jira events with projects being tracked via the Atlas platform.

    Atlassian has also streamlined the tools it provides to reduce the number of steps required to administer its applications and onboard new users.

    Finally, the company also has launched Atlassian Together, a single subscription offering through which organizations can license its Trello, Confluence, Atlas and Jira Work Management applications delivered via the cloud. An enterprise organization with more than 5,000 users can now, for example, license those applications for $11 per user.

    Atlassian is making a concerted effort to enable organizations to more easily collaborate at a time when they have become more dependent on software than ever, noted Trautman. In many cases, businesses are now trying to adjust to the rapid rate at which software is being delivered thanks to the adoption of DevOps best practices, she noted.

    As such, there is a greater need for integration between tools such as Jira that development teams use to manage projects and a wide range of tools used by knowledge workers residing in various departments, said Trautman. In effect, Atlassian is trying to enable organizations to reduce the “collaboration tax” they incur as workflows span multiple silos, she added.

    In fact, in many cases, organizations are struggling to keep pace with how agile software development teams have become. The irony is that not too long ago business executives routinely complained about how long it took IT organizations to adjust as business conditions changed. Now, many businesses are rolling out additional digital capabilities via software updates that can be made multiple times a month.

    The rate at which organizations will collaborate across departments will naturally vary, but the days when each department was a fiefdom unto itself are coming to an end. The challenge and opportunity may now be determining how modern organizations should be structured once it becomes easier to collaborate.

  • Planview Outlines VSM Strategy After Acquiring Tasktop

    Planview Outlines VSM Strategy After Acquiring Tasktop

    Planview this week announced it completed its acquisition of Tasktop, a provider of a value stream management (VSM) platform that enables DevOps teams to align their efforts more closely with strategic business goals.

    Louise Allen, chief product officer for Planview, said the goal is to tighten integration between the Tasktop VSM platform and the project management applications that Planview already provides to software development teams and business executives.

    It’s still early days as far as adoption of VSM within DevOps workflows is concerned, but as more organizations realize how dependent they are on software, they need to better align application development projects with their strategic business goals, said Allen. VSM platforms make it possible to analyze data collected from various DevOps tools and enable business and IT leaders to, for example, visualize how a delay to one project might impact revenue goals for an upcoming quarter.

    Given the current weakness in the overall economy, organizations are looking to more precisely understand the impact software development decisions will have on the business, she added. As part of an effort to address that requirement, Planview will also make it easier for its applications to consume data that was originally created in Tasktop, she explained.

    VSM enables more organizations to function like a software company—aligning application updates with revenue goals. As the number of digital business transformation initiatives being launched increases, organizations are finding they need to operate more like a software company that either manufactures something or provides a service.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to an automated process using DevOps best practices, there is growing appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business.

    At its core, a VSM platform will automatically convert metrics collected from a DevOps workflow to track a set of key performance indicators (KPIs) defined by the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to align the resources needed to achieve a strategic goal by, for example, devoting more developers to a specific project. The data collected via a VSM platform can also then be shared with business intelligence (BI) applications that business leaders typically use to manage the business.

    It’s not clear just how hard business leaders are looking for deeper insights into how software development initiatives are progressing, but at the very least, DevOps leaders need a simpler way to understand all the dependencies that exist between initiatives. Otherwise, they risk missing deadlines simply because no one realized a delay that occurred in one project had a cascading impact across multiple other initiatives. Regardless of who consumes the data generated by a VSM platform, the need to increase visibility across the software development life cycle had never been greater.

  • Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian has added an extensible catalog for tracking software components, dubbed Compass, to its portfolio of DevOps tools along with an Atlassian Data Lake and Atlassian Analytics cloud service that makes it simpler to aggregate and query data collected from the company’s portfolio of tools.

    In addition, Atlassian is making its Atlas collaboration framework—formerly known as Team Central—formally available in beta. That framework, in effect, provides an overlay through which different collaboration tools adopted by various DevOps teams can be more easily integrated.

    Compass provides DevOps teams with the ability to map all the components they use to assemble their software as well as the teams that own them. DevOps teams can access shared components and documentation along with scorecards to allow them to measure and evaluate their architecture based on the baselines, security or compliance requirements they might be required to meet. It can be extended to other applications via an integrated Apps engine using Forge, the existing Atlassian cloud development environment.

    Tiffany To, head of product for Agile and DevOps at Atlassian, said Compass is designed for DevOps teams that are typically trying to manage 50 or more microservices. It is designed to be deployed alongside the Jira project management software that is widely used by software development teams to manage multiple projects.

    Atlassian Analytics, meanwhile, is based on a visualization and analytics platform the company gained last year with the acquisition of Chartio. Initially, the Atlassian Data Lake will include data from Jira Software and Jira Service Management tools with support for additional Atlassian platforms planned.

    Collectively, these tools are part of an ongoing Atlassian effort to make it simpler to integrate multiple DevOps teams, said To. Many of those teams prefer to maintain autonomy over the tools they select. The challenge that creates is organizations need some type of overlay through which they can collaborate and share best practices, she said.

    A survey of 2,000 developers conducted by Atlassian found half of the respondents exercise strong autonomy over the tools they use, with more control over tool selection gained as developers become more experienced. The same survey also found that 65% of developers felt they should be responsible for more of the software product life cycle than they currently are.

    It’s apparent that most organizations building software are trying to strike a balance between developer autonomy and centralized control. Developers are expensive to hire and retain, so there is a natural tendency to make available the tools they prefer. That, however, can lead to a level of tool sprawl that makes it difficult to determine the overall state of application development and deployment within an organization.

    Regardless of the approach, the need to remove as much friction as possible from DevOps workflows is clear, especially as the number of simultaneous application development projects continues to multiply. The challenge and the opportunity, of course, is achieving that goal while keeping developers happy.