devopsy.kinsta.cloud

Tag: collaboration

  • How Collaboration Can Optimize Product Development

    Strategic collaboration allows companies to build partnerships and seek solutions that are adaptable and specialized

    Systems engineers have faced complexity since the dawn of time. And while bringing complicated projects to market under old rules, methods and technologies was never a walk in the park, today’s highly competitive market presents new challenges to prove the old rules of product development are defunct. In fact, a recent report from Machina Research, now part of Gartner, estimates the number of connected machine-to-machine devices will increase to 27 billion by 2024, up from 5 billion in 2014. The sheer increase in machine devices alone provides a clear picture of the importance placed on systems engineers to stay the course when navigating product development’s complex nature.

    Within the constantly evolving modern product development system comes an increasingly intricate development process. Today’s system engineers are fighting to fit a square peg into a round hole by using old tactics to solve new challenges. This includes an accelerated rate of innovation, increasingly complex end user asks, tighter deadlines and ever-changing regulations. Alongside these challenges, Forrester Consulting found that product development is facing five main obstacles in keeping teams from true optimization:

    • The confusing and constantly changing nature of requirements and a lack of quick development for solutions.
    • Stakeholders providing conflicting priorities, assumptions and unclear objectives.
    • Difficulty collaborating across globally distributed teams.
    • Unnecessary handoffs and delayed decisions.
    • The increased need for collaboration across diverse roles.

    So what is the solution to these problems, you ask? One could argue strategic team collaboration is the best way to address both the challenges of the modern product development landscape and the obstacles systems engineers are facing. Let’s dig into that a bit deeper.

    Team Collaboration: An Enabler of Innovation

    Teams that are still operating with outdated strategies and systems find themselves unable to adapt and adjust quickly when the market changes. With rapid growth predicted to stay at a steady rate, strategic collaboration allows companies to build partnerships and seek solutions that are adaptable and specialized. This includes sharing data throughout your whole business, including distributed teams and partner organizations, which allows transparency to reach the entire supply chain. With the COVID-19 pandemic causing supply chain halts and the backup of product releases, it is now more important than ever to ensure communication throughout the entire development process.

    With the country leaning on a remote workforce more heavily this year, virtual meetings and emails are not sufficient enough as communication tools for a team that has to coordinate across departments, roles, companies and geographic boundaries. As a first step to meet these demands, system engineers should consider the following strategies:

    1. Ask your team the question, what does success look like? If each member has a different end goal, you will end up wasting valuable time. By defining what success looks like, you can align your teams on what you are building and clarify expectations upfront. This saves time and allows for better communication across teams.
    2. Support better decision-making through situational awareness. When you have communication upfront about a team’s end goal, they are far more likely to make decisions that work toward achieving that. Without situational awareness, employees are unable to comprehend the impact of their decisions or clearly define their roles and responsibilities. This makes it difficult to settle on the right choice when faced with a bump in the road.
    3. Ensure you’re up-to-date with your traceability practices. Especially for those who need to adhere to regulations, traceability analysis allows you to ensure your system holds up under regulatory demands. Further, it meets contractual terms before you encounter a problem.
    4. Create collaboration with a purpose. Ensure relevant data is accessible to everyone to whom it may be relevant, and keep them in the loop on decisions that happen outside the process as much as possible. When you keep your teams in the know, they are able to work collaboratively and with greater situational analysis.

    At the end of the day, your goal should be to empower your whole team through data sharing, transparency and a clear definition of success. When you are able to do this, your team will be better positioned to make decisions that benefit the project and work symbiotically across diverse roles.

    We may not be able to predict exactly where the product development industry is going, but know that there will be rapid innovation. It’s best to prepare your teams now; otherwise, it will be a bumpy ride.

  • PagerDuty Looks to Streamline IT Incident Management

    PagerDuty Looks to Streamline IT Incident Management

    PagerDuty has added more automation and analytics capabilities into its portfolio of incident management tools, at a time when organizations are looking to significantly reduce the total cost of IT.

    Jonathan Rende, senior vice president of product at PagerDuty, said the general release of Intelligent Triage advances the level of AIOps that can be applied to incident management by eliminating a raft of manual tasks.

    Intelligent Triage aggregates signals from more than 375 monitoring, observability and ticketing tools, which are then grouped based on relationship and elevated depending on the impact on the business. That level of contextual data makes it possible for IT teams to increase productivity while dramatically reducing alert fatigue, said Rende.

    At the same time, PagerDuty is adding support for integration with Microsoft Teams alongside existing support for Slack. IT teams are increasingly relying on these collaboration tools to process requests for help from end users, he noted.

    In some cases, IT teams are communicating with one another via these media or employing built-in tools embedded in the PagerDuty incident management platform. In either case, workflows across IT teams are now occurring in near real-time, said Rende.

    Finally, PagerDuty is adding a Dynamic Service Directory to give DevOps teams a central knowledge base that identifies owners and experts for each service and their associated run books, in addition to making available a mobile status dashboard to allow remote teams to collaborate more effectively when incidents arise. That capability is especially critical at a time when many IT staffs continue to work from home as part of the effort to combat the COVID-19 pandemic, said Rende.

    In general, IT organizations are looking to automate incident response whenever possible to both minimize costs and potential disruptions. Businesses are more dependent on IT services than ever. However, as more applications are deployed the nosier the IT environment becomes. Discerning which alerts are stemming from the same root cause issue becomes more relevant as organizations either limit headcount or even look to reduce it during a time of widespread economic uncertainty.

    Of course, regardless of the state of the economy, most IT professionals would rather not have to waste time on manual tasks that don’t add a lot of value to the business. Most IT professionals need to free up more time to achieve more pressing goals. Every minute spent on chasing down an alert that winds up being yet another wild goose chase just piles on more stress.

    Advances in automation and AIOps have been coming at a steady pace for the last several years. The adoption of these new capabilities to manage incidents has been uneven at best. In the wake of the economic downturn brought on by the pandemic, it’s now more a question of how soon IT organizations will be tapping into these capabilities to streamline the management of IT. After all, many IT managers are going to conclude there’s no sense in letting a good crisis go to waste.

  • Atlassian Acquires Halp to Gain Help Desk Based on Slack

    Atlassian Acquires Halp to Gain Help Desk Based on Slack

    Atlassian this week announced it has acquired Halp, a provider of a help desk platform that employs Slack as its user interface.

    Steve Goldsmith, head of product integrations at Atlassian, said Halp will provide organizations with a way to manage lightweight processes via an interface that is already commonly used within many organizations. The goal is to provide a level of integration between Halp and the JIRA Service Desk platform from Atlassian to handle more complex requests, he said.

    The Halp platform has already been integrated with Confluence, a knowledge base platform from Atlassian that enables help desk staff to share best practices for resolving known issues. Deeper integrations with JIRA and Confluence will be forthcoming, added Goldsmith.

    At the same time, Atlassian is working on tighter integration between its service desk platform and Microsoft Teams, which has emerged as a popular alternative to Slack, he noted.

    Halp CEO Fletcher Richman said that approach has gained traction because the biggest challenge when it comes to help desks is making it as easy as possible for an employee to generate a help ticket. Halp addresses that issue by enabling end users to simply drag and drop on an emoji to generate a help desk ticket.

    The help desk staff is then provided a web interface through which they can remotely manage tickets and respond to requests via Slack. That approach eliminates the need for the help desk staff to be physically located in an office or employ a virtual private network (VPN) to access a help desk platform running on a local area network, he said.

    Richman noted too often employees wind up supporting each other because the process of generating a ticket is too complex. At a time when many employees are working from home to help combat the COVID-19 pandemic, it’s not really possible for employees to currently provide that mutual support.

    It’s not really clear to how many employees might ever be heading back into an office at this point, so Halp also provides a way for remote employees to more easily remain productive, he added.

    Slack and JIRA, of course, are already de facto standards among many DevOps teams. Halp should provide developers with a means to instantly resolve a wide range of low-level issues in near real-time by generating a help desk ticket via Slack.

    Richman noted that for any IT service management (ITSM) platform to be successful, it needs to meet users where they are. If the platform is too complex or intimidating, users will look to their fellow employees for help first. Before long, however, all the mutual support saps productivity. By making help just a simple Slack message away, many more issues will be resolved by help desk personnel who already know the right answer, he said.

    It’s too early to say how many more help desk tickets might be generated because of Slack. However, in the wake of the rush to remotely enable the entire enterprise, the need for an easier way to provide support is now more apparent than ever.

  • DevOps Deeper Dive: Teams Adjust to New WFH Normal

    DevOps Deeper Dive: Teams Adjust to New WFH Normal

    In the wake of the COVID-19 pandemic the level of software development activity has remained relatively constant, but developers—who, like everyone else—are now largely working from home, are putting in more hours. Organizations are now grappling with whether working remotely on software development projects now represents the “new normal.”

    A report published this week by GitHub shows that while there was a slight dip in activity in various regions of the world as the pandemic spread, activity on the public GitHub repository quickly recovered. Whether developers are spending more time working on projects is difficult to conclude given all the potential distractions at home, but according to the GitHub report, the amount of time spent on the platform per developer has increased. This could be due to various factors including the fact that developers are not commuting to work or are managing multiple tasks—some of which are directly related to work—across an extended working day. Others simply may be taking more breaks between activities.

    Despite working in isolation, it would appear developers are remaining productive, said Kelly Stirman, vice president of product strategy and marketing for GitHub. “More time to code increases productivity.”

    Providers of other DevOps platforms have observed similar increases in activity during the pandemic. Moritz Plassnig, senior vice president and general manager for software delivery management and software delivery automation cloud at CloudBees, said many organizations have been launching custom application development projects to drive digital business transformation initiatives. Now those projects are becoming core to the organization’s business continuity strategy.

    “The current situation has only accelerated that trend,” said Plassnig.

    The biggest challenge in managing a highly distributed workforce is ensuring the right code is being worked on at the right time, said Fred Simon, chief data scientist of JFrog. “Everyone needs feedback.”

    To provide that feedback, managers have employed collaboration tools such as Zoom and, when necessary, shifted work to DevOps platforms made available as a cloud service, added Simon.

    At the same time, the level of communications tooling baked into a DevOps platform matters more than ever, said Emrah Samdan, vice president of product at Thundra, a provider of a platform for securing and observing cloud-native microservices. Developers can collaborate with each other much more effectively using asynchronous communications tools to, for example, share code.

    “A lot of productivity is being lost setting up Zoom calls,” said Samdan.

    The issue now is whether working on software development projects remotely represents the new normal. A recent survey of chief financial officers published by PwC finds that nearly half of the respondents (49%) plan to make remote work a permanent option for roles within their organizations that allow for it.

    How employees will respond to that change will vary. According to results from a recent survey of workers conducted by GitLab, 52% of employees say they are more productive working remotely, while 48% are more efficient. Of course, those results also suggest half of employees don’t share that same level of appreciation for working from home.

    It’s worth noting that many software development teams were already heading in the direction of working remotely more often prior to the pandemic, said Brendan O’Leary, senior developer evangelist at GitLab. In fact, he noted, resources such as the GitLab Remote Playbook have been downloaded more frequently over the last few months.

    “I think it is a time that will see a real separation of bosses and leaders,” O’Leary said, noting leaders will go beyond simply tracking metrics to enable organizations to continue to launch innovative software development projects.

    Obviously, DevOps teams that were working in a distributed fashion prior to the pandemic have a distinct advantage over those that have worked primarily in the same central location. However, given all the current uncertainties organizations now face, it’s probable every member of a DevOps team going forward is going to be working from home a lot more often.

  • GitHub Extends Scope and Reach of Repository

    GitHub Extends Scope and Reach of Repository

    GitHub today at its GitHub Satellite virtual conference announced it has made it easier for developers to either launch a project or join an existing project on its repository and has added collaboration tools directly within the platform.

    GitHub is also moving to advance DevSecOps by adding code scanning tools and making secret scanning tools available for private repositories, in addition to making available GitHub Private Instances to provide organizations in highly regulated industries access to a more secure managed implementation of the GitHub repository.

    Max Schoening, VP of Product Design, said GitHub Codespaces removes a lot of friction associated with starting or joining a project by enabling developers to spin up a project in seconds. In many cases, he said, developers never launch a project simply because the effort required was too great relative to the value of the effort.

    Available in limited public beta, GitHub Codespaces should not only improve developer productivity but also significantly increase the number of projects being hosted on GitHub, said Schoening.

    GitHub Discussions, meanwhile, will provide a threaded format to organize unstructured conversations without having to leave the GitHub repository. Scheduled to be available in beta shortly, GitHub Discussions should increase developer productivity in addition to providing a place for developers to maintain a frequently asked questions document. Over time, Schoening said GitHub expects millions of communities to be formed around GitHub Discussions.

    GitHub is also moving to make DevSecOps a natural extension of any application development project. GitHub Advanced Security Cloud provides access to native code scanning and secret scanning tools that can be embedded within the developer workflow. Currently in beta, GitHub Advanced Security Cloud is based on security tools it gained via its acquisition of Semmle last year. Every Git push can now be scanned using a CodeQL semantic analysis engine to discover vulnerabilities. GitHub Advanced Security Cloud is designed to be an extension of an existing GitHub Advanced Security service.

    Finally, GitHub Private Instances will provide a fully managed alternative that, among other things, allows for bring-your-own-key encryption, backup, archiving and compliance with various regional data sovereignty requirements. GitHub did not reveal, however, when GitHub Private Instances will be available.

    As GitHub continues to evolve as an arm of Microsoft, there is no doubt more IT teams will be embracing DevOps. The biggest challenge is often making it easy to get started. In fact, many developers may find themselves unconsciously embracing best DevOps and DevSecOps processes as they, for example, employ scanning tools baked into the GitHub repository.

    Of course, no one knows for sure whether organizations will continue the pace of application development projects in the wake of the economic downturn brought on by the COVID-19 pandemic. However, Schoening noted the amount of time between pull requests has declined on the GitHub repository, which he suggests is an indication of increased activity and productivity now that more developers are working away from the office.

  • One Identity Allies With HashiCorp to Advance DevSecOps

    One Identity Allies With HashiCorp to Advance DevSecOps

    One Identity, a provider of identity management software, has aligned with HashiCorp to make it easier for DevOps teams to implement best DevSecOps practices.

    Tyler Reese, a senior product manager for One Identity, said via a plugin for HashiCorp Vault developers can now securely manage, monitor, record and audit privileged and administrative access to their vaulted tokens, passwords, certificates, application programming interface (API) keys and other secrets residing in the Safeguard privileged access management (PAM) platform from One Identity.

    The goal is to make it easier for developers to securely access credentials stored within Safeguard without having to provide access to every credential used to access, for example, a packaged application that a developer is trying to provide access to via a custom application or vice versa, he said.

    The two companies are trying to bridge the divide between end user credentials managed by IT teams that have control over access to packaged applications and the way DevOps teams manage secrets within their custom applications, said Reese. DevOps teams increasingly need to integrate custom applications with packaged applications. The challenge organizations face is finding a way to securely provide that access in a way that doesn’t require internal IT teams to be overly involved in the application development process, he noted, adding by integrating with HashiCorp Vault, all the friction is taken out of the process.

    Based on a transparent protocol proxy software that inspects protocol traffic at the application level, Safeguard rejects traffic that violates policies defined by the internal IT team. That approach prevents unauthorized and unfettered access to data. IT teams can also monitor privileged sessions in real-time with the ability to execute various actions, such as terminating a session if unusual or unwanted behavior is detected. Safeguard also enables IT teams to rotate privileged access passwords to comply with a wide range of regulations, said Reese.

    As developers embrace DevSecOps they need to find a way to dovetail their efforts with existing password management processes. For the most part, DevSecOps remains aspirational within most organizations. There is general agreement that more responsibility for security should shift left toward developers. However, most organizations are still a long way from putting the tools in the hands of developers who need to extend existing DevOps workflows. In the absence of those processes and tools, DevSecOps often winds up being little more than a sermon that IT leaders give to development teams.

    On the plus side, the rate at which cybersecurity tools that are integrated with the continuous integration/continuous delivery (CI/CD) platforms on which DevOps processes depend is steadily increasing. As that trend continues to gain momentum, the relationship between developers and cybersecurity teams will evolve. Cybersecurity teams will continue to define controls and verify that they have been implemented. Developers will be held accountable for implementing those controls as part of the overall quality assurance process. The challenge now is getting everyone inside behind that cultural transition in advance of the tools that will be available soon.

  • Kong Brings Collaboration to Designing APIs

    Kong Brings Collaboration to Designing APIs

    Kong has launched an open source tool for designing application programming interfaces (APIs) designed to make it easier for teams of developers to collaboratively edit an API specification that can be stored in a Git repository.

    Based on the open source Insomnia API management platform the company gained last year by acquiring Floating Keyboard Software Inc., the Insomnia Designer tool for designing APIs integrates natively with the testing capabilities embedded in the Insomnia API management platform to make it easier to collaboratively design both REST and GraphQL services.

    As part of that effort, Kong is also releasing plugins that enable teams to automatically embed Kong Gateway policies directly into their API specification files within a Git repository.

    Greg Schier, technology tech lead for Insomnia at Kong, said the goal is to streamline the workflow for designing APIs by enabling teams to share updates to edits of API specifications using best GitOps processes.

    For example, DevOps teams can now search for API designs to discover details such as Git Status and Git Branch. They also can automatically generate configurations for both Kubernetes and Kong for Kubernetes within the individual API spec file. Developers can also select Kong plugins that provide capabilities such as authentication or rate-limiting to govern their API’s behavior.

    As organizations embrace microservices-based applications the need to be able to design, build, deploy and maintain APIs has become more critical. Each microservice within an application exposes its own APIs. Organizations that embrace microservices soon find they need to potentially build thousands of APIs. Rather than address each of those API as an isolated project, Kong is making the case for constructing a set of workflows that make it easier to design and construct APIs within the context of a larger DevOps process.

    The goal should be to eventually make the testing of APIs a natural extension of the unit testing process embedded within a continuous integration/continuous delivery (CI/CD) platform, said Schier.

    Within far too many organizations the designing and building of APIs is still an afterthought. There is naturally a lot of focus on building microservices, but once they are constructed not nearly as much attention is paid to the API. And yet, while microservices frequently are replaced, it is the API that remains constant. All the dependencies between the microservices that make up an application are only manageable because of the APIs employed to connect them all. Rather than constructing APIs after a microservice is built, Kong is making the case for consistently designing and building APIs in keeping with best DevOps practices.

    In the wake of the COVID-19 pandemic, it’s hard to say at what rate organizations will be building and deploying new applications. What is for certain is the bulk of new applications will be based on cloud-native microservices to make them more flexible and resilient. That way when the next major crisis erupts, organizations will be able to respond more adroitly to rapidly changing business conditions because the enterprise architecture now revolves around APIs.

  • Zoho Offers Free SaaS Apps to Combat Coronavirus Spread

    Zoho Offers Free SaaS Apps to Combat Coronavirus Spread

    Zoho today announced it is making available for free a bundle of software-as-a-service (SaaS) applications dubbed Remotely through July 1.

    Raju Vegesna, chief evangelist for Zoho, said Remotely is a humanitarian gesture to help mitigate the impact of a global coronavirus epidemic. Remotely comprises a set of productivity and collaboration applications that users can access in as little as five minutes.

    Included in Remotely are productivity, collaboration and project management applications as well as tools that automate the migration of data into the Zoho cloud platform.

    Vergesna said Remotely also addresses cybersecurity concerns by enabling IT teams to apply security controls to the data that employees are allowed to access. Of course, IT organizations in many cases would still need to make sure the network connections being employed to access SaaS applications are secure.

    Now that many local governments are recommending that organizations allow employees to work from home to help limit the spread of the coronavirus outbreak, many IT administrators are scrambling to provide remote access to applications at scale. It’s one thing to provide access to a small number of employees who might travel intermittently, but it’s quite another to support an entire remote workforce for some unknown period of time.

    Vergesna, however, said that at this point the challenges associated with making that transition have a lot more to do with overcoming cultural issues than they do the technology. Much of the transition to Zoho SaaS applications has been automated, he said.

    It remains to be seen to what degree the coronavirus outbreak might accelerate the transition to cloud applications. Many IT administrators are still managing local instances of Windows servers to deliver applications because the time and effort to migrate to SaaS applications have been substantial. Making those on-premises applications available remotely at scale is not only challenging from a technical perspective, but it’s also expensive.

    Of course, Zoho is far from being the only provider of SaaS productivity and collaboration applications. However, it remains to be seen whether other providers will follow Zoho’s lead. The hope each of these vendors has is that once the coronavirus crisis passes many of the organizations that take advantage of their software to enable employees to work from home will start paying to use that software.

    In the meantime, the economic impact of the coronavirus is likely to be staggering. Conferences are being canceled and face-to-face business meetings are being shifted online. It’s hard to say how many of those meetings are likely to stay there for good. At the very least, many more end users are about out to discover just how rich SaaS application environments have become. In many cases, IT teams will stitch together workflows across a range of SaaS applications using application programming interfaces (APIs). The challenge they will face is acquiring the programming skills required to construct those workflows.

    — Mike Vizard

  • Using Automation Tools to Drive Collaboration, Innovation

    Using Automation Tools to Drive Collaboration, Innovation

    How automation can help business move past the walls of confusion between dev and ops

    In the current state of things, businesses are leaning more than ever on the collective intelligence of their tech teams to drive innovation within their respective organizations. These teams are always comprised of developers and operations professionals. With the foray into automation and the desire for companies to do more with less, it has never been more critical that all individuals, regardless of team, come together to do amazing things. Of all of the services available, Chef is a great example of a suite of tools that want to empower teams to do just that: come together and innovate. It is all about bridging gaps, which can range from simply redefining how teams think about each other to more complex things such as knowledge gaps.

    The first gap that almost always seems to come up when bringing teams together and driving business value is the duties gap. For too long we have sat on opposite sides of the coin. In operations in particular, too often we see ourselves as the ones that have to deal with the aftermath of unfortunate problems within code. But the fact is, we should all care about our systems, we should all care about our code and we should all be ensuring the longevity of both.

    Once you’ve moved past the first hurdle, then comes the gap in knowledge.  Scripting has become pretty common as companies press for automation, but in some instances, it becomes necessary to build up existing team members. Using enterprise automation tools such as Chef, entire teams and entire companies can begin caring about a shared thing: the configuration, health and state of their infrastructure and applications. In doing so, those same teams can begin speaking a shared language. Once this knowledge and shared language are in place, developers no longer view the ops team as an “other,” but rather as collaborators. They can each use their various areas of expertise and speak the same language without having actually having to speak the same language.

    The third common gap is the process gap. Process can represent all of those past processes that a company is reluctant to let go of, which can hinder the ability of the developers and operations humans when they’re attempting to collaborate. The process gap can become particularly difficult to move past without leadership buy-in; as such, it is critical to involve business decision-makers in this transformation. While nearly the entire industry is beginning to move toward more collaborative environments, the entire leadership team must be onboard with the requirements to make changes happen. With the use of automation tools in particular, though, processes can begin to shift more toward collaboration-friendly policies and you can then make the case for further expansion with proof that it can aid in your transformation.

    Empathy is the final gap that must be overcome. The great part about the other gaps is that they work hand in hand to solve each other’s problems. By promoting collaboration, resolving these gaps are also facilitating collaboration. The empathy gap is largely caused by silos of the past that have led to the commonly talked-about “wall of confusion.” Closing the knowledge and duties gap, developers and operations humans can now communicate and understand the same language and processes each is following. This allows the wall to be broken down and operations humans and developers alike can care about both code and stability.

    It’s easy to start getting dev and ops teams working together and on a more even playing field once these gaps have been eradicated. This becomes a big driver for innovation and is, in many cases, a true recipe for success within the company. During my career, I’ve both watched and been involved in these transformations. Working with solutions such as Chef has allowed me to cross the bridge myself, and likewise, be able to share with others how that can be scaled out to entire organizations.

    — Brittany Woods

  • Collaboration Between Competitors is the Future of Enterprise Technology

    Collaboration Between Competitors is the Future of Enterprise Technology

    Mark my words: 2019 will be the year enterprise technology companies go back to kindergarten and realize that sharing really is caring—about their customers. Several key moves last year point toward a future full of collaboration between large and small technology vendors—even those that compete against one another.

    Companies rarely use a single vendor for all their enterprise IT needs, and their shift toward increased agility and their need for specialized capabilities will only lead to greater fragmentation. The vendors that make it easiest for their customers to connect IT systems with one another will be the biggest winners in the current IT market, even if that means they must work with previously sworn enemies.

    While integrating products with those of a competitor may seem like a risky move, the vendors that pull off those integrations have the ability to actually strengthen their defensibility through the application of network effects. Think of it this way: An ERP system becomes more valuable to the company that uses it with each successful connection the system makes to the company’s other systems of record. In turn, that makes it more difficult for the company to turn around and replace those systems.

    Key Examples

    Over the past five years, competing enterprise technology companies increasingly have partnered with one another to benefit their shared customers. Last year was a significant year for that sort of collaboration in the enterprise space.

    Salesforce.com announced several key strategic partnerships last year, including work with AWS that will make it easier for customers to send data back and forth from Amazon’s cloud. Of particular interest is the work the two companies are doing on Amazon Connect, the Seattle-based company’s contact center software that competes with Salesforce’s own Lightning Dialer product. Google Cloud and Salesforce are also working together on IoT and analytics applications to serve their shared customers, even though Salesforce already offers its own analytics suite.

    On the end user side, Google now allows Box users to store files from Google’s G Suite collaboration service in the content services company’s cloud, and is working with Dropbox to provide similar functionality. Box and Dropbox compete with Google Drive, but working with the other companies allows Google to broaden its appeal, especially to companies that would prefer their data not get stored on Google’s servers.

    But there’s a new sort of collaboration on the horizon: Multi-company alliances that provide even broader benefits to customers. Microsoft, SAP and Adobe announced last fall that they’re working on a new project called the Open Data Initiative that’s supposed to bring customer data from the three companies’ disparate products together into a common data lake for processing and analysis. Under the new initiative, customers should be able to read and write data from all three companies’ business applications.

    Microsoft CEO Satya Nadella said at the time that customer demand for collaboration and integration was the driving force behind this initiative. Pooling business application data is critical to enterprises’ futures. Companies that want to make the most of advanced analytics will need to access previously disparate data sources. Organizations must break down their internal silos between functions to increase enterprise agility—and technology must follow suit.

    Partnership Evolution

    Why now? It’s easier for different vendors to integrate with one another when business applications reside in the cloud. Different companies can build APIs to facilitate connections with one another. Vendors can also ensure their customers are running on consistent managed environments, which simplifies connections between different vendors. Customers also can more easily change vendors in the cloud era, which puts increased pressure on tech companies to provide products that meet enterprise needs, which means they must integrate more broadly.

    These companies also can build upon the foundation of their individual partnerships to form broader alliances. Both SAP and Adobe have individual strategic partnerships with Microsoft, and those relationships likely make it easier for them to forge a broader-reaching agreement.

    Finally, if tech companies don’t partner with one another, other firms will come along to do the job. A fleet of businesses including Informatica, Sapho and Mulesoft (now a part of Salesforce) exist to help enterprises create and operationalize connections between data sources. If vendors choose not to build these integrations, customers will find a way to create critical connections and may even abandon siloed products for more open alternatives.

    How Far Does This Go?

    There are still some fairly clear (if unstated) boundaries that haven’t yet been crossed. For example, Salesforce’s partnership work with Microsoft could be best described as minimal, ever since Microsoft’s attempted acquisition of Salesforce fell through and Microsoft beat out Salesforce to acquire LinkedIn. Similarly, AWS and its hyperscale cloud competitors aren’t doing much in the way of strategic partnerships with one another, and are instead content to keep sniping at each other through public announcements and new product launches.

    As such, enterprises should expect there will still be barriers to full and true openness among their technology vendors, and those barriers won’t be overcome easily. Case in point: For all of Microsoft’s talk of openness with the Open Data Initiative, the data lake in which customers are sharing their information with SAP, Adobe and Microsoft is hosted in Azure, not another cloud. If Azure remains the sole storage option for this initiative, it seems logical that not every Microsoft competitor will play ball and participate, since doing so would drive use of one cloud platform.

    However, there are some glimmers of hope on the horizon for broader collaboration between major cloud players AWS, Microsoft, Google and IBM. All of them are now members of the Cloud Native Computing Foundation and are working on the Kubernetes open source container orchestration software. As Kubernetes forms the foundation for an increasing number of modern applications, it’s possible we’ll see major cloud providers opt to work more closely with one another on building foundational components of application infrastructure.

    While such collaboration is far from friction-free, it does provide opportunity and a foundation for these firms and others to increase their collaboration, which we expect will be more important in the future as enterprises continue to embrace hybrid- and multi-cloud deployments.

    — Blair Hanley Frank