devopsy.kinsta.cloud

Tag: business processes

  • OpenLegacy, Boomi Simplify Legacy Application Integration

    OpenLegacy, Boomi Simplify Legacy Application Integration

    OpenLegacy, a provider of a platform through which application programming interfaces (APIs) are layered on top of legacy application processes, announced today an alliance with Boomi, an arm of Dell Technologies that provides organizations with access to an integration platform-as-service (iPaaS) that is made available as a cloud service.

    Zeev Avidan, chief product officer for OpenLegacy, said the company’s core platform enables IT teams to convert legacy application processes into microservices that can be involved by tools such as Boomi using an API. Rather than merely providing access to an application, OpenLegacy is designed to capture all the business logic, metadata and associated middleware associated with a specific business process executing on, for example, an IMS or AS/400 platform, he said.

    The Boomi alliance extends that capability to include processes created by either citizen integrators or developers via the Boomi cloud service. That’s critical because most mission-critical applications in the enterprise still run on legacy platforms. Rather than having to rewrite those applications from scratch, Avidan said OpenLegacy makes those applications more easily accessible to other applications and platforms via a software development kit (SDK) based on Java.

    At a time when many organizations are looking to accelerate digital business transformation initiatives, Avidan said being able to programmatically invoke an entire business process accelerates the rate at which those initiatives can be completed because business processes don’t necessarily have to be re-engineered.

    In the case of Boomi, that capability is now being extended all the way to end users to make it feasible to tap into existing business processes using a set of tools that already have been adopted by more than 11,000 organizations.

    OpenLegacy is making a case for DevOps teams to think in terms of legacy business processes rather than individual applications. Historically, many organizations have relied on enterprise service bus (ESB) platforms to integrate applications. However, a DevOps team still has to manually integrate all the software components that make up a business process once application environments are connected.

    Legacy platform integration in the absence of OpenLegacy becomes the digital equivalent of an archaeological dig, said Avidan, noting many organizations wind up hiring expensive systems integrators to accomplish the task.

    In the wake of the COVID-19 pandemic, there is clearly a lot more interest in modernizing business processes. Many employees are working from home for the foreseeable future. Cloud services such as Boomi provide a means of enabling end users to craft workflows on their own. The challenge has always been finding a way to easily connect those workflows to transaction processing systems and other systems of record around which the business depends.

    It’s not clear to what degree providing that level of access will drive a burst of business process innovation. However, DevOps teams that spend an inordinate amount of their time integrating new applications with legacy business processes might be keen to leverage an approach the promises to turn those business processes into a reusable microservice.

  • Building Effective Digital Transformations

    Building Effective Digital Transformations

    Enterprises have reportedly spent upwards of $5 trillion on their digital transformation efforts, yet they’re also not hitting their objectives. In fact, in many industries, such as banking, health care and utilities, only half of organizations are keeping pace with their digital transformation expectations.

    According to Joe Garber, global head of strategy and solutions at Micro Focus, it’s essential to set goals early and clearly. Garber said most organizations find that their primary objectives for digital transformation fall into one of four buckets: optimizing for speed by prioritizing enterprise DevOps, maximizing agility with hybrid IT, driving insights with predictive analytics, and enhancing the ability to protect users, applications and data with advanced security measures. “Establishing a framework early on helps inform next steps,” he said.

    Once those categories are in place and prioritized, many organizations can benefit from starting small with one department or one geography. This will enable organizations to test their theories and control their trials more closely, but also leverage positive results to establish a business case for future projects, Garber said. “Just be careful to think broadly and long-term when you decide what technology to deploy—software that may be good for a small-scale operation can break down or paint you into a corner if you’re not looking at the big picture and select technology that can support your enterprisewide requirements,” he said.

    Contentstack chief operating officer Matthew Baier advises organizations to pick a real-world challenge and provide a proof of concept that could garner a quick win. Be sure to note upfront the goals and key performance indicators. “Another piece of advice is to include both the affected business and IT teams in the project, to capture feedback holistically about what impact digital transformation efforts have across the organization,” he advised.

    Nabil Freij, CEO at GlobalVision International said pilot projects are key to effective implementations. “Before transforming your entire processes, you need to make sure that the proposed transformation will bring sufficient monetary, quality and/or schedule benefits before they are proliferated across the board,” he said. “This is not hard to do. Be selective with the pilots that you undertake. Make sure that they are representative of the majority of the work that your teams undertake on a regular basis. Create key metrics that are important to meet and measure and track them. After a few pilot projects, you will have enough data to start making conclusions regarding further testing or regarding starting across the board or limited implementations.”

    With objectives down, it’s essential to get the right people in place. “The first step in developing a successful digital transformation strategy is bringing together the right people to assess the current state of the workplace environment,” said Dave Maffei, president and chief revenue officer at Akumina.

    “To get the right feedback, organizations should deploy a survey and interview their employees across business units and job functions to understand what technology and processes they value most, as well as what challenges they face while performing their job duties,” said Maffei. “Without completing this essential step, organizations won’t truly understand what solution they need and could be missing out on solving existing challenges to the overall employee experience. Having internal feedback will allow organizations to understand what their ideal solution might look like.”

    Larry Wolff, CEO, Wolff StrategyPartners, added that a team of digital transformers should be established, if possible. “If an enterprise has the luxury of time, such as no imminent existential threat, then they may want to set up a single, high-performing team to tackle an initial phase of the digital transformation. Set them up for success so that others want to emulate them and drive the next phases,” he said.

    “People are naturally apprehensive about change. Drive one positive change initiative to diminish those fears and get more and more people on board,” he added.

    — George V. Hulme

  • Atlassian Adds Business Planning App by Acquiring AgileCraft

    Atlassian Adds Business Planning App by Acquiring AgileCraft

    Atlassian announced it is acquiring AgileCraft to give business leaders visibility into strategic projects in a way that is closely mapped to IT projects being driven by DevOps processes.

    The value of the deal, expected to close next month, is estimated to be $166 million.

    Many DevOps teams already make extensive use of the Jira project management software developed by Atlassian. AgileCraft emerged in 2013 as a provider of a collaboration application aimed at business users to keep track of the various strategic IT initiatives that are largely dependent on DevOps processes.

    Atlassian and AgileCraft previously established a technology alliance to facilitate that goal. Atlassian president Jay Simons said the acquisition represents an opportunity for Atlassian to extend its reach into the realm of business users who increasingly are trying to keep track of complex digital business transformation initiatives that are dependent on multiple IT projects. Many of those digital business initiatives tend to quickly fall behind schedule because the dependencies between various IT initiatives are not clear to all the key business stakeholders, he said.

    In addition, Simons said many businesses now are trying to apply the agile methodologies pioneered by DevOps teams more broadly within the IT organization. To achieve that goal, business users need a project management application that has been optimized to enable them to keep track of multiple inter-related DevOps projects, he noted.

    Most organizations are not yet anywhere near the point where the IT organization is completing IT projects faster than the business can absorb. But as agile methodologies and best DevOps practices become more widely employed, there may come a day when IT organizations will complete IT initiatives faster than most business will be able to adapt. In fact, it’s not uncommon for organizations that have embraced DevOps to deliver multiple updates to applications a week. AgileCraft planning software will make it easier for business users to appreciate all the business implications associated with each of those updates. The irony is, the constant debate over the inability to align IT with the business usually comes down to the inability of IT organizations to keep pace with the demands of the business. It soon may turn out the business is no longer capable of absorbing the rate at which new applications are being rolled out.

    In the meantime, applications such as AgileCraft should make it easier for IT leaders to have better-informed conversations with business leaders concerning where limited resources need to be applied and when. Business leaders will be able to see for themselves now what impact any given set of missed deadlines is likely to have on any strategic initiative. In fact, there may come a day when business leaders proactively make more resources available to achieve a specific goal without requiring IT leaders to attend a meeting to explain in excruciating detail how every delay adversely impacts the grand scheme of the business. Instead, business leaders will be able to see for themselves exactly where additional resources are needed to achieve a specific business goal.

    — Mike Vizard

  • Leveraging Automation for Your Business

    Leveraging Automation for Your Business

    Artificial intelligence (AI) has the capability to change the way we work, the way we manage, and the way we conduct research. As automation processes improve, businesses increasingly are looking for ways to leverage the new technology to help with their own goals.

    There are certain risks posed by the advancement of artificial intelligence, and the automated applications AI creates are in contrast to the many benefits using automation may bring about. The rewards of automation, when managed properly, are the relief of burdensome activities such as mundane tasks and other minutiae, improved productivity and increased participation.

    Consequences of adopting automation for your purposes must be thoroughly thought out to leverage it to the best of your ability.

    Automation, once used for only a few specialized tasks, now can be used for data mining, marketing, medical research and building financial models. These are just a few of the applications the technology can be used for, and it’s far from a comprehensive list. The details of automation are specific to the industry that employs it, the organization that manages it and the managers who oversee its implementation.

    Why should you consider using automation to help achieve your business goals? Quite simply because utilizing it properly could result in a more efficient, more effective workforce and could even create job opportunities. By freeing up mental resources and enhancing the capabilities of your workforce, your organization will be able to operate at its peak efficiency and efficacy.

    “Machines can attend to vastly more information and more complex processes than human beings, and try out more drugs or vaccines than we can in the lab,” Pedro Domingos, a professor of computer science at the University of Washington told National Geographic. “Machine learning is used to discover drugs by simulating the process on a computer, which takes a fraction of the time and cost.”

    After you begin analyzing where your organization needs help, you can start the process of using automation that makes sense for you. Your business may need help with routine marketing tasks, creating models for the data metrics you bring in. Or, perhaps you need help organizing large amounts of information related to research and development of a product you’re about to roll out. Whatever the application, there are automated applications made to benefit your business.

    “Faced with a constant onslaught of data, we needed a new type of system that learns and adapts, and we now have that with AI,” Arvind Krishna, head of research at IBM, said in a recent blog post. “What was deemed impossible a few years ago is not only becoming possible, it’s very quickly becoming necessary and expected.”

    With automation, you can achieve things you may not have thought possible before. As Krishna makes clear in the quote above, the capabilities of leveraging automation are untested and virtually limitless.

    To truly leverage automation, you’ll need to manage the results of its implementation and have your team perform synthesize and arrive at conclusions through critical thinking and social cooperation—skills yet unmastered by even the most powerful artificial intelligence. Pairing automation with skilled social thinking will result in a highly productive and effective organization. This can result in some ancillary benefits such as increased cooperativeness between team members.

    For companies interested in rapid growth, automation can help propel your processes. From manufacturing to marketing, automation can help boost your efforts in research, analysis and production. Automating repetitive tasks can help free up workers allowing them to work on more complex and pressing problems within the company. In addition, workers learn new skills through the adoption of automation and managers can more effectively understand how to manage complexity within your organization.

    However you decide to use automation, it’s important to do a thorough and objective analysis of your organization. Where can you improve? Where do you need help? How can we empower workers to better perform? How do we measure performance? These are key questions that can help guide your analysis of your organization and well as your adoption of domain-specific automation applications.

    — Anthony Coggine

  • Living in a DevOps World (Part 1)

    Living in a DevOps World (Part 1)

    The concept of DevOps has grown and evolved into a conceptual and working model for more effective and efficient software development and implementation. That said, there are some differences of opinion on the real-world value of any DevOps approach to date, and on the best way to create and implement a real-world DevOps environment. This two-part article will focus on what an agile DevOps approach is meant to address, and what it is not meant to address.

    DevOps sits at the nexus of three essential business technology functions: software development, quality assurance and operations. A short and concise definition of DevOps proposed in 2015 seems as appropriate as any:

    DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into regular production while ensuring high quality.

    The definition was suggested in the book, “DevOps: A Software Architect’s Perspective,” and the authors have hit upon the essence of the practice. The key, of course, is how to put that concept into practice.

    Perhaps the first step on the journey to effective DevOps is the recognition that the concept is the result of the rise of the Lean and Agile software development methodologies. Those methodologies, among other things, emphasize the following:

    • A focus on customer value.
    • The elimination of waste.
    • Reduced cycle time (accomplishing work faster, releasing faster).
    • Shared learning.
    • Avoiding batching (don’t do things until required).
    • Theory of constraints (break things up, focus on individual issues).
    • Continuous integration, testing and delivery.
    • Faster time to market.

    DevOps in Practice

    Adherence to the principles above meant that something had to be invented to accomplish them and that something was DevOps. Over time, an effective DevOps practice should address any number of business technology pain points. The following short list of those pain points and the DevOps response should prove instructive.

    System Downtime

    The developers’ curse since systems were developed, system outages are inevitable as long as systems are designed, tested and implemented—even with increased automation—by imperfect beings. DevOps acknowledges that by changing the focus from trying to create applications that never fail to designing systems that can recover quickly, thus decreasing aggregate systems outage time over the life cycle of any application or system.

    Stagnation

    This was a staple of traditional systems development and is most closely associated with the waterfall methodology for systems development. After requirements were created, the development team would be locked away for weeks, months or, in some cases, years before emerging with “fully” working software that inevitably no longer satisfied rapidly evolving business requirements. DevOps is designed to fit hand-in-glove with the Agile practice of short windows of incremental changes instead of long release cycles, putting working software in the hands of customers as quickly as possible.

    Team Conflict

    Having been borne from the cultural combination of Agile and Lean, DevOps has taken on the problem of functional silos that are often erected between development, operations and the business customers. It follows the methodological approaches of collaboration and teamwork first to understand what others know and to leverage the best of it to solve business problems more rapidly. There is also a cultural bent toward experimentation, continual learning and constant improvement. This leads to blameless post-mortems, where instead of finger pointing when something goes wrong there is collaborative discussion and learning to correct and prevent the problem from occurring again.

    Knowledge Silos

    Functional silos have led to compartmentalized knowledge. If the old game was that knowledge is power, the new game in the DevOps world is that knowledge is freely exchanged as an enabler to solving business problems. DevOps addresses the problem of information being lost in translation between the development and operations functions by eliminating the functional barricades and making knowledge sharing the highest form of collaboration.

    Inefficiency

    Waiting for things to happen used to be a standard operating procedure in the pre-DevOps world. Project plans were created and managed to account for the time it might take for new code to be moved into a testing, quality or even production environment. This was a momentum killer for projects and at times a morale killer for developers waiting to see what changes they might need to make to their code set. The combined Agile and DevOps approach has rewritten the traditional approach to code migration, smoothing and eliminating wait times so that projects flow more seamlessly from start to finish. It also has the benefit of keeping business resources—testers, approvers, etc.—more engaged as a result of a constant flow of new functions and features to test and use. And lest this be viewed as simply a way to keep the technical stuff moving along, it’s important to remember that there is a financial aspect to this as well. Reducing speed to market with new functionality, reducing or eliminating idle hands—be they technical or business—and delighting customers with a steady stream of enhancements and features all go directly to an organization’s top and bottom lines.

    That, after all, is in many ways what the DevOps approach is all about. All of these critical areas become the means to accomplish it. Part two of this article will focus on some more of the benefits of a DevOps approach, and how to achieve them.

    — Dave Farinelli

  • SRE vs. DevOps vs. Cloud Native: The Server Cage Match

    SRE vs. DevOps vs. Cloud Native: The Server Cage Match

    This post supports my DevOpsDays Austin Presentation on May 4

    I don’t believe in DevOps shaming. Our community seems compelled to correct use of DevOps as an adjective for tools, teams and teapots. The frustration is reasonable: DevOps clearly taps into head space for both devs and operators who see a brighter automated future together. For example, check out this excellent DevOps discourse by Cindy Sridharan.

    As an industry, we crave artificial conflict so it’s natural to try and distill site reliability engineering (SRE), DevOps and cloud native into warring factions when they are not. They all share a focus on Lean process.

    Very simply: SRE is a job function, DevOps is a process approach and Cloud Native is an architecture.

    These three concepts have tremendous alignment because they all have the same fundamental goal: increase product delivery through improved flow. It’s really that simple. We are looking to enhance productivity using system thinking concepts from Lean manufacturing.

    SREs improve productivity by eliminating manual operations, reducing errors and improving infrastructure quality. They do this starting from the production infrastructure and working backwards. Highly automated delivery, integrated logs, systemwide monitoring and blameless root cause analysis are key tools. Before we get wrapped up in tools, the distinguishing factor for SRE teams is that they take ownership of the production infrastructure.

    There is tremendous power in assigning ownership for delivery. That’s why I see industry benefit in defining an SRE job function. A DevOps strategy is a system approach and it becomes an anti-pattern to making an individual or team responsible to own “the DevOps.”

    In DevOps, we look for ways to streamline the entire product creation flow. That often drives toward tools and techniques that SREs require; however, our goals are not department-specific. We want to work with all stakeholders including developers, product managers, testers, SREs, executives and customers. This system focus for developers becomes CI/CD pipelines, platforms, work tracking tools and other workflow elements. These tools are not specifically DevOps tools, but confusion is natural since they are often pulled into organizations due to DevOps thinking.

    This SREs should expect to collaborate deeply with other functions under a DevOps process.

    Cloud-native architecture also falls under the DevOps mandate because it strives to decompose large application stacks into highly automated collections of services. There is no magic “DevOps platform” in cloud-native design; however, teams using the architectural approach get modularity, strong APIs, service orientation, simplified configuration and build automation practices that fit perfectly into DevOps thinking.

    For example, using containers does not mean a dev or SRE team is following DevOps process or using cloud-native architecture; however, it is an indicator that they are leaning toward smaller deliverables and improved dev-production fidelity.

    Yet, SRE, Cloud Native and DevOps do have a shared enemy: Complexity.

    We’re doing a great job creating best practices and abstractions that accelerate developers and creating innovative infrastructure options in both cloud and physical. That means we are seeing dual explosions in developer productivity and infrastructure complexity. Unfortunately, this wealth has not made it into operations automation, which has been delivering incremental improvements at best. Even worse, the added workload and complexity adds pressure to SRE functions.

    Ultimately, all three of these concepts are aspects of Lean business practices; however, acceleration from DevOps and cloud native is outpacing progress by SREs. This imbalance creates risk for everyone involved because Lean is about system performance. Delays and failures cannot be isolated to a single silo.

    The mistake of seeing Dev and Ops as silos means creating false contention between SRE, DevOps and cloud native.

    If you are hearing that in your organization, then take it as a warning about how your teams are integrating Lean systems thinking into your processes.

     

    — Rob Hirschfeld