Tag: business process

  • New Relic Adds Ability to Correlate IT Events to Business Processes

    New Relic Adds Ability to Correlate IT Events to Business Processes

    New Relic this week added an ability to enable DevOps teams to better understand the potential business impact any change to an IT environment might have.

    Manav Khurana, chief product officer for New Relic, said New Relic Pathpoint adds a dashboard to the company’s observability platform through which business metrics can be collected alongside telemetry data. That data is collected either via connectors provided by New Relic or via a metrics application programming interface (API) that IT teams can invoke.

    IT teams can use that API to connect to custom applications or an end-to-end business process, noted Khurana.

    All that data is then modeled alongside DevOps telemetry data to provide insights into the impact any change might have on the business in real-time, he added. That approach provides the added benefit of making it easier to strategically align the management of applications, services and infrastructure by business function, noted Khurana.

    In the near future, New Relic will also extend the natural language capabilities it is currently previewing to New Relic Pathpoint, he said.

    Longer term, New Relic is working toward making it possible to model how proposed changes to business processes will impact IT environments, added Khurana.

    Business and IT leaders intuitively understand that every business event creates a corresponding IT event, but most organizations manage those processes in isolation. New Relic Pathpoint presents an opportunity to close a divide between IT teams and the rest of the business that has plagued organizations for decades.

    It may be a while before advances in data analytics and AI eliminate that divide completely, but creating a common set of metrics for managing business and IT processes is a crucial first step.

    In the meantime, DevOps teams, in addition to accelerating the pace at which applications can be built and deployed, are being asked to employ observability platforms such as New Relic One to minimize disruption to the business. Observability has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications using open source agent software, interest is rising in observability platforms that simplify the investigation of anomalies indicative of an issue that could disrupt an application environment. As that shift occurs, more organizations will seek to correlate IT and business events.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. It’s not uncommon for DevOps teams to have multiple monitoring tools that surface a set of predefined but often conflicting metrics. Observability platforms, however, unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue, hopefully before any catastrophic disruption can occur.

  • 7 Benefits of Self-Contained Apps for BPM

    7 Benefits of Self-Contained Apps for BPM

    According to Gartner, “As business needs change, organizations must be able to deliver innovation quickly and adapt applications dynamically—reassembling capabilities from inside and outside the enterprise. To do this, organizations must understand and implement the ‘composable enterprise.’”

    This is an appealing concept for companies looking for a good balance between highly centralized and highly distributed technologies and information systems.

    For enterprise IT, the use of composable infrastructure – built up of independent components that can be swapped out when needed – is already widely applied. Another place to look for the advantages of composability: Business process management  (BPM) automation. Why? Because IT teams, DevOps teams and leadership are facing a number of pressures:

    • Business teams need responsiveness and speed from IT as everyone continues to look for ways to maximize go-to-market.
    • Current business process automation platforms deploy applications that are all dependent on shared resources. The DevOps team must take interoperability and integration among a group of applications using shared resources into consideration for new developments, new deployments and maintenance. This can be complex, time consuming and can require extensive testing before updates can be deployed.
    • Similarly, whenever the process application platform is upgraded to a new version to take advantage of new features, or when maintenance on a single application is needed, all applications are affected and the need to offline and upgrade everything can impose a high cost in downtime.
    • Scaling grouped business process applications can add unnecessary cost as it is applied across the board even if not all of those applications need to be scaled.
    • The approach of building business applications from interoperable elements promises to address some of these key issues.

    Modularity and component-based systems have already been successfully applied for many years in IT and software development. Infrastructures are composed; we no longer buy machines but CPU, memory, disk space, bandwidth and so on. In software development we see composability applied through containerization, an approach that is already widely used and becoming the standard for DevOps teams, as shown for example by the growing use of platforms such as Docker and Kubernetes.

    Self-contained applications is setting the same trend for composable BPM process-based applications. BPM technologies already fit perfectly into the approach of composable architectures. Applications themselves are also already internally made up of composable elements: Processes, sub-processes, connectors, services, reusable pieces of code, business rules and UI fragments, just to name a few.

    Self-contained apps combine the benefits of containerization approaches and technologies with the power of its BPM application platform technologies for application development. The BPM base offers wide extensibility to integrate with enterprise IT, with good auditability, traceability and compliance; deployment of individual applications using containers offers faster delivery, portability and easier management.

    DevOps teams can deploy complex applications more easily, deliver continuously, and thus support innovation and faster time to market. Each self-contained app can be deployed individually, independently and quickly to deliver increased value through improvements as quickly as the business requires.

    DevOps teams, IT leadership and CIOs will be happy to see self-contained apps because:

    • The containerized approach included with self-contained apps is already familiar to CIOs and their technical teams.
    • The less complex, independent development and deployment of self-contained applications means faster application delivery to production overall. As it’s not necessary to take interoperability and integration among a group of applications into account during development, development is faster, testing is easier and the resulting application is easier to maintain.
    • Scaling an independent application is simpler and it can be applied to each application individually.
    • Application maintenance costs are reduced, as smaller and more regular updates are now possible.
    • Because it’s easier to implement multiple projects, development teams’ efficiency and productivity, and therefore ROI, increase.

    Business will be happy to see self-contained apps because:

    • Automation and business application projects are more easily adapted to business changes; the IT team can respond more quickly and with more confidence due to the smaller scope and less interdependence among other applications.
    • Faster innovation and competitive advantage offers a faster response to new business needs.
  • Micro Focus Lays DevOps Foundation for RPA

    Micro Focus Lays DevOps Foundation for RPA

    Micro Focus has announced the general availability of Micro Focus Robotic Process Automation (RPA), which sets the stage for employing DevOps processes to construct highly automated business processes.

    Thanks to the rise of artificial intelligence (AI) and digital business transformation initiatives, interest in RPA has increased significantly. However, rather than merely using RPA to build bots to automate a narrow set of static processes, RPA is now leveraging machine and deep learning algorithms to optimize a wider range of dynamic business processes and adjust more easily to changes within an application.

    Travis Greene, senior director for IT operations management ay Micro Focus, said new capabilities such as object recognition technology included within Micro Focus RPA enables the platform to detect and automatically adapt to changes to the user interface.

    Other new capabilities now include the ability to visually or programmatically create workflows using a tool that records screen actions, the ability to more easily combine graphical and programmatic workflows spanning multiple platforms and the ability to deploy hundreds of thousands of bots as needed. A centralized dashboard manages the bots, all of which have unique IDs and encrypted, role-based credentials.

    As RPA and other forms of AI continue to be integrated and embedded with applications, Greene said it’s a matter of time before DevOps practices are extended to RPA platforms. Organizations will seek to train bots continuously as more data is made available, which in turn will drive updates to applications that are dependent on those bots. In most cases, depending on the complexity of the task, the bots will be built using a mixture of application programming interfaces (APIs), command-line interfaces (CLIs) and graphical tools. Organizations will need to define the processes to determine how and when each organization will opt to invoke one interface instead of another, either in isolation or combination, added Greene.

    Historically, organizations have been able to apply RPA to static processes with mixed success. With the rise of AI, the scope of those efforts has become more ambitious. Business leaders are too inclined to believe that just about every business process can be automated using a combination of AI and RPA. However, AI and RPA still are confined to relatively narrow use cases involving highly predictable outcomes.

    That’s changing, however, and RPA and AI are becoming more pervasive across the enterprise. DevOps teams will need to find ways to update both their applications and RPA/AI models without breaking one or the other. Most of the current RPA/AI models are highly sensitive to any change made to the application environment they are monitoring. And, unfortunately, the data scientists who are largely responsible for constructing those RPA/AI models don’t yet tend to have much of an appreciation for best DevOps processes. There will, however, come a day soon when these two worlds will collide.

    — Mike Vizard

  • Incidence Avoidance in Action

    Incidence Avoidance in Action

    Today, CIOs are faced with the challenge of making enterprise technologies perform on par with offerings from consumer-facing technology leaders, such as Facebook or Netflix, meaning technology or services being seamlessly available with no performance lag. Of course, these expectations are not always aligned with the realities of managing complex hybrid enterprise systems that were not necessarily designed to deliver this type of performance.

    On the other hand, IT operations supporting new-age “digital” business services are dealing with on-demand resources that are supported by software-defined data centers extending into the public cloud by using serverless computing platforms. This is resulting in a “new generation hybrid enterprise” that must deliver the functionality of, and operate as, real-time infrastructure.

    Lexmark, a U.S.-headquartered global company that manufactures laser printers and imaging products, wanted to achieve zero latency operational performance and enhance its business processes to achieve incidence or error avoidance.

    This article details Lexmark’s IT objective and the solution implemented by Wipro Ltd., a global information technology, consulting and business process services company.

    Problem: Lexmark required a technology solution that would provide visibility into its core business process—managed print services. The solution would also need to factor in other supporting systems and functional processes. The objective was to achieve operational excellence by minimizing errors and risks.

    Solution: To address this critical IT operations problem, Wipro was able to incorporate unique design principles to create an operationally simple, scalable and focused solution that brings IT and business process owners to a common understanding regarding achieving incident avoidance.

    Wipro built a new way of visualizing operations management, based on the fundamentals laid out by IT operational analytics (or AI operations, as it is called now).

    Working only with the tools and data that Lexmark already owned, Wipro and Lexmark created a system that measured the heartbeat of Lexmark’s managed print services business. That heartbeat was synchronized to the printer data collection systems, with the thresholds determined entirely by machine learning techniques. Every underlying system was arranged in a “server room.”  Only out-of-variance conditions are displayed in the main visualization panel, with the root cause just a single click away. This paper provides insights into the challenges faced by IT enterprises to deliver an on-demand solution to clients, similar to the ones offered by digitally evolved B2C companies.

    Digital enterprises that use hybrid environments must respond in real-time and need to achieve incident avoidance, rather than incident management.

    If we look behind the scenes at operation command centers today, we see operations that struggle to keep up the pace. Very few operations have been built from the ground up. In the enterprise world, Severity 1 (incidents that are categorized as high impact by business users) incident resolution times, still run for a couple of hours if IT support is not in a position to find the root cause of the problem. The culprit is often the lack of a proper configuration management database (CMDB), insufficient logging or lack of application discovery and dependency mapping. Every IT professional can recognize these failings, yet projects to correct these flaws never seem to get the necessary capital appropriation. Clearly, a new approach is needed to fix this.

    Identify the Business Process

    The process should start by identifying the key driving force or the heartbeat of the core business operation. Depending on the industry, this heartbeat might be customer orders, service requests or vendor purchase orders. All other systems are connected to this heartbeat. To select the right attribute to monitor as the heartbeat, start with business analysts who have a good feel for the day-to-day struggles of the operation. These analysts often have a series of scripted reports they run to track system health. More advanced analysts might even have automated these with alerts. By leveraging this information and using data discovery techniques, we found that the values can be configured as business KPIs.

    In the case of Lexmark, Wipro streamed the KPI values in real time and used machine and wire data to broadcast the underlying monitoring components by using an existing streaming analytics platform that is supported by AI and machine learning techniques. We found that the amount of data needed to assess process health is time sensitive, and normally less than 24 hours of data is displayed during that time.

    The platform visualization shown above, tracks the creation of sales orders for a business unit. The green line represents the flow of orders through the system. Any anomaly in an underlying system is reflected directly on this flow. This is achieved by streaming analytics and AI techniques that use the business KPIs.

    Apply the Architecture Overlay

    The next step is to subordinate the supporting infrastructure to the business process heartbeat. This feat is accomplished without complex business rules and sophisticated orchestration engines. We call this the “server room” and it is a view of the entire infrastructure on one web page, leveraging a lattice chart format that allows for easy comparison. Each of these underlying components will have a direct impact on the business process.

    Applying the same streaming analytics and AI/ML techniques that identified the anomaly in business process, we identify what is causing that anomaly and can quickly see the problem areas.

    Color coding helps the technician quickly understand the severity of the event. Blue indicates the system performance has not yet violated the set threshold, but an underlying infrastructure issue exists and needs to be proactively addressed. Amber indicates the system has violated the warning threshold. Red indicates the system has violated the critical threshold, a condition that by design we will never allow to happen.

    The user can scroll over any given point and a callout box will display the actual level, as well as a brief note on what has gone wrong and the timestamp.

    Analysts can now instantly focus their efforts on the specific systems that are in an error state, even if an event has not yet created an incident.

    Machine Learning to Define the Thresholds for an Anomaly

    What is normal behavior? This is often the most difficult question to answer because common monitoring and management processes rely on a single data value that was set during implementation. But thresholds must be extremely flexible to capture the ever-changing nature of the business process. Batch jobs that run at midnight, end-of-month closing activities, shift changes and a host of other potential variables must be considered when determining the right thresholds.

    For any component supporting the business process, we need to understand what is normal for right now. To determine that at Lexmark, we applied machine learning to dynamically set the thresholds for each sub-system at the month, day and hour level based on the healthy business KPIs we established.

    Incident Avoidance, Not Incident Management

    To fully understand the potential of this approach, it is necessary to change the way system analysts interact with the system. IT professionals who have been doing system support for several years, may be conditioned to react to the work in their queue. A well-honed incident management process is the enemy of proactive action that can prevent emergencies.

    By aligning the underlying system activity and thresholds with the business process, the IT professional can truly understand the whole environment, not just their individual technical component. The most effective analysts will extend their knowledge into other business areas. At Lexmark, we discovered that we were able to solve “intractable” performance issues by simply adding hardware or capacity.

    Integrated IT operations is not a goal, it is the means by which digital enterprises can be managed in real time. The path to real time management is through service capacity guarantees, performance and availability management and using anomaly detection in the context of the business process to identify issues well before an incident occurs. We advise starting small and building an anomaly detection system for the heartbeat of the process that enables you to see both the forests and the trees.

     

    This article was co-authored by Murthy Malapaka, general manager, Transformation Services Cloud and Infrastructure Services at Wipro Ltd. He helps enterprises digitally rearchitect their operations to run on hybrid IT environments to achieve incident avoidance instead of incident management. He has assumed various technology leadership roles across application and infrastructure architecture domains, specializing in availability and reliability. Murthy has been providing consulting services to CIOs and CTOs in their journey from client server to on demand infrastructure services.

    — Brad Clay

  • Machine Learning Is Working for CIOs, Vendor Survey Finds

    Machine Learning Is Working for CIOs, Vendor Survey Finds

    AI’s time has finally come, if a new survey commissioned by ServiceNow is to be believed. Its results showed that nearly 90 percent of CIOs are at least dabbling with machine learning, with 53 percent calling it an area of strategic focus for their companies. What’s more, almost 70 percent of the CIOs surveyed say decisions made by machines will soon be more accurate than those made by humans.

    The new survey was conducted by Oxford Economics on behalf of IT and enterprise software-as-a-service vendor ServiceNow. The survey, titled “The Global CIO Point of View,” was completed by 500 CIOs in 11 countries across 25 industries.

    The report also fits neatly with evidence from other sources that CIOs are in charge of digital transformation. Just under 75 percent say they lead their company’s efforts to gear up for full-fledged digital business. Business intelligence derived from data analytics has always been a pillar of digital transformation. But with some 85 percent of CIOs reporting that machine learning provided “substantial value” or “transformative value” to the accuracy as well as rapidity of decisions, it’s beginning to change the way some organizations operate, according to the report.

    Within three years, two-thirds of the respondents expect to be making an investment in machine learning. Today, one-third are investing. The size of spend as a percentage of the overall IT budget is relatively modest, however: something like 5 percent for machine learning.

    One of the reasons for the move to machine learning is that sometimes you just have to do things smarter. “We were heading to a tipping point almost where there was just so much work coming in,” said Dave Wright, chief innovation officer, ServiceNow, talking about IT shops. “There was just so much work coming in; the workload just continued to increase year over year. CIOs want to know, ‘How do I get to the point where I can deal with this, because I can’t constantly throw heads at it.’” That’s why the report advises that companies direct their early machine learning efforts at the most commonly used services, freeing resources for more rewarding efforts.

    Machine Learning’s Obstacles Aren’t What You Think

    Machine learning technology has matured so much in recent years that it’s no longer the prime obstacle for CIOs. Instead the challenges are outdated business processes, incomplete insufficient skill sets, lack of quality data, insufficient data sources, risk assessment conflicts and budget limitations. When data is siloed across the company, accessing all the right data for the best decision-making is not always easy or possible. There’s also some inertia built into the organizational structures of most companies; the notion of making business decisions based on machine learning (a.k.a. “decision automation”) may require some handholding, for example. Technology is not the problem.

    Early adopters to machine learning, which represent just under 10 percent of the survey sample, share some characteristics and ways of doing things: They prioritize talent. They are working on better business processes and have a road map for future changes developed by monitoring mistakes made by machines. The road map is also guided by the need to implement policies and processes that improve data quality. They have strong technology foundations, with an emphasis on data analytics, cloud, mobile and IoT. And they expect results. Nearly 90 percent of this 10 percent of early adopters expect decision automation to support topline growth.

    What may be more interesting is that, of the other 90 percent of the CIO respondents, nearly 70 percent expect to develop revenue from machine learning. Looking at the data behind this report, the CIOs who’ve gotten their feet wet with machine learning are very excited by its prospects.

    The report outlines five steps to achieve value from machine learning that are worth a quick summary:

    1. Build your technical foundation so as to improve data quality. Successful companies had already invested significantly in analytics, for example.
    2. Prioritize automation of the most common business use cases; they will return the greatest business benefit.
    3. Build an exceptional customer experience. If customers see the man behind the curtain in a machine learning-based tool, it may become a very negative experience for them. Spend extra time making the entire customer journey seamless.
    4. Attract employees with new skills and double down on culture.
    5. Measure and report. The benefits of machine learning may not be obvious to all. CIOs must set expectations, develop success metrics and build a sound business case to acquire funding. Build some success stories.

    — Scot Finnie

  • Hybrid Cloud: How to Avoid Twice the Problems

    Hybrid Cloud: How to Avoid Twice the Problems

    Regardless of how enthusiastically you embrace the cloud, unless you’re a brand new business, you have already have an infrastructure running your applications. Odds are, you’re either renting space in one or more data centers. Or maybe long ago you reached the tipping point and built a data center or two of your own.

    Regardless, moving to the cloud is going to be a process. You’re going to be working on a scale of months, if not years. During that time, how do you manage and secure assets that are in more than one environment—especially when those environments are radically different?

    The Data Center

    Your data center environment is probably well-established. You’ve got a mature technology stack, a high level of rigor around manual processes and a traditional “castle walls” perimeter-based approach to security.

    Specialized teams are in place for the networking infrastructure, operating system management, security, data center logistics and other areas. Each team does a great job running the day-to-day of their areas and planning for the five-to-seven-year life cycle of their technologies.

    The challenge here is that this structure has lead to a slow, stable cadence around innovation and encourages each team to work in their own silo. Common ground and management is established through a formal change management process. This results in stability, but at a very high cost when it comes to rapidly iterating on ideas.

    The Cloud

    In stark contrast, the cloud is constantly changing. New technologies are deployed quickly, systems such as continuous integration/continuous deployment (CI/CD) enforce what used to be a manual process and capacity planning is basically a thing of the past.

    Just as the cloud is delivered in a different manner, teams working in the cloud also are delivering in a very different manner.

    When assets are available on demand and at a higher level of abstraction, a lot of the work associated with deploying a new application is handled by automation, allowing you to focus on solving problems for your customers.

    Reconciliation

    It’s clear that the data center and cloud are two very different environments. How do you reconcile having assets in each without simply duplicating all of your tooling and processes?

    Tools

    Start with the tools that your teams are using today. Odds are, the set of tools you’re leveraging in the cloud more closely aligns with what you want to achieve around application delivery.

    Cloud-first tools also are more likely to be able to handle the rapid pace of change and the large-scale environments normal to the cloud. These traits make it easier for cloud-first tools to adapt to the data center.

    Make sure you’re pushing your cloud-first tools in to the data center and not the other way around.

    Responsibilities

    Leveraging more cloud services from a variety of providers means that the day-to-day operational and security responsibilities are spread out among teams and organizations. This can pose some serious challenges if not addressed properly.

    You need to ensure responsibilities are defined clearly for all involved and there is a spirit of cooperation so that you can avoid finger-pointing when things hit the fan.

    Remember that service level agreements (SLAs) represent the worst-case scenario. Solutions and services always should beat the stated SLA. If a team or organization you’re working with is consistently blowing their SLA or barely meeting it, it’s time to re-evaluate their involvement.

    Process

    Your processes define how the responsible teams are going to use the tools you’ve deployed. Data center processes are the weak spot in joint hybrid environment processes.

    The traditional workflows typically are too slow and require too much manual work to support the style of work the cloud promotes. Take the processes you use in the cloud (think CI/CD), map out where you absolutely have to make exceptions for the data center, and use those as your baseline processes.

    The goal here it to double down on your DevOps culture shift and force it into the data center. You want to maximize your current data center investment while not slowing down the culture transformation you’ve started with DevOps.

    Security

    The last piece of the puzzle (at least a high level) is security. It’s crucial you view security as a unified layer across all of your environments.

    Security is challenging enough without creating additional work for your teams.

    Security controls need to integrate with your preferred cloud service providers and be applicable inside the data center. The traditional perimeter is gone, and tools that still try to defend your data under that principle are needlessly increasing your risk.

    Modern controls need to be applied as close to the workload and data as possible. They need to present a unified front across environments and still handle the speed and scale of the cloud.

    That may seem like a tall order, but there’s a lot of work being done in the vendor and open-source communities to modernize the approach to hybrid security rapidly.

    The Way Forward

    Even in a best-case scenario, you’re going to be dealing with hybrid environments for months–if not years–to come. Doubling your workload or ignoring the challenges will only make matters worse. It’s best to tackle the problem head on.

    Here are the three keys to remember:

    1. Aim for one set of processes,
    2. Push cloud tools into the data center, and
    3. View security as a unified layer.

    This is a difficult task. You are not going to get it right the first time. The key is to ensure your teams are working together, communicating regularly and iterating often.

    What are your experiences managing hybrid environments? Let me know on Twitter, where I’m @marknca, or leave a comment below.

    BTW, if you’re looking for a deeper dive on the topic of hybrid environments, watch my webinar hosted by devopsy.kinsta.cloud, “Handling The Realities of Hybrid Cloud.” Watch below or over on the Trend Micro site.

  • IT Governance at DevOps Speed: Time to Shift Gears

    IT Governance at DevOps Speed: Time to Shift Gears

    Technology plays an incredibly important role in the idea economy, where business innovation is dependent on the software that powers the business. Speed and agility in IT are key to a competitive advantage in this modern economy, in which small startups with disruptive ideas are competing with well-established enterprises and industries. Consider how Uber and Airbnb are challenging taxis, rental car companies and hotels, all based on the power of an idea and software. Yet, traditional enterprise IT struggles to deliver at the speed business demands.

    Have you ever heard a business leader say, “Our IT teams are extremely responsive and very fast”? The typical response is quite the opposite. IT is commonly viewed as a bottleneck to business innovation and, in many organizations, the business simply avoids IT and instead creates some form of shadow IT.

    IT Governance, the Old Way

    The principles and practices of DevOps creates the potential for faster delivery and higher quality. However, one of the largest sources of friction is the traditional focus on IT projects and project governance. Consider this definition of a project from the Project Management Institute:

    “A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.”

    Given that projects can be expensive investments, and because of limited resources, enterprises justifiably carefully prioritize and plan which ideas and initiatives should be approved.

    Faced with limited resources, enterprises expend significant effort to prioritize, optimize and fund only the most important projects. But no matter how well-intended, this governance approach also struggles to respond to the speed and velocity required in the idea economy. Indeed, the typical portfolio-planning and project-management approach is often an underlying cause of dysfunctional IT behaviors such as excessive requirements, throw-it-over-the-wall deployments and questionable quality—none of which are pleasant.

    Consider how the business approaches user stories and requirements management. In a traditional, project-driven world in which the project is a one-time opportunity, businesses often are given an exhaustive list of ‘must have’ features in their user stories. This behavior is understandable—given the ‘feast or famine’ nature project, funding businesses need to make sure their future needs are included, even if the need isn’t immediate.

    Sadly, this introduces both technical debt and excess complexity from the very beginning. Especially, when you consider that only a fraction of those ‘must have’ requirements will ever be actually used. In fact, a recent IEEE paper noted that 28 percent to 45 percent of software features often go unused.

    Consider how “project success” is typically measured. Project teams typically are evaluated on their ability to deliver on time and on budget, along with other various quality and satisfaction measures. The emphasis on schedule and cost can drive sub-optimal decisions, as deadlines and cost pressures loom. As a result, testing is often abbreviated, as the schedule compresses. Sometimes the scope is reduced to conform to the deadline. This routinely leads to challenged releases in which the service desk is left holding the bag, which ultimately degrades trust and teamwork.

    After the project is completed, the project team often redeploys to other projects, depending on demand for specific skills. The accumulated knowledge and wisdom of the team is lost and there is no further incentive to invest in automation or process improvements because the team has disbanded.

    The DevOps Shift

    DevOps is a very different approach that requires rethinking how work is funded and governed. Fundamentally, a DevOps team is charged with delivering small, high-quality releases, very quickly. The team embraces fast feedback to remove bottlenecks and waste and utilizes relentless automation to make tasks repeatable and efficient. Given that the team will deliver dozens or more releases per year, it is incentivized very differently from the traditional “project” team. The DevOps team often “owns” the application in Development, Test and Production, and has a shared accountability for the value it delivers. The team reduces handoffs and delays and implement small, frequent changes in response to business demand, customer feedback and system performance.

    The friction of traditional governance needs to be addressed using DevOps to enable the enterprise to thrive. One of the ways to remove the governance friction is a paradigm shift from projects as described above to products. It is vital to focus on value and business results along with employee and customer satisfaction. The key difference is that a product is funded for the long haul:

    • A product team delivers ongoing value and the business can count on improvements to meet market demand.
    • A product team does not form and disband depending on funding.
    • A product team is focused on delivering value through the product and will naturally enhance and improve their processes. CIOs and senior leaders need to consider using the Product model as an alternative way to fund and govern their initiatives.

    I’ve talked with several IT leaders who are exploring how to evolve the concept of the traditional project toward a longer-term product orientation. Some organizations explicitly make the change to products, and others are taking a more evolutionary approach. Regardless of the path, the need to evolve the funding model is clear.

    Consider how product governance is different from projects. The product team, in partnership with the business, is funded for a sufficient period of time (year, half-year, perhaps quarter) depending on the business needs. The product team then delivers fast releases of business-driven innovation and rapidly updates the system based on feedback from continuously assessing the product. As the team remains intact, it is able to learn and improve while also accelerating delivery. Additionally, because the product team is able to deliver quickly, the incentive to overload releases with “nice to have” features is greatly reduced.

    Here’s how the mindset is different:

    Project                                                                         Product

    Short time frame                                                   Long term commitment

    Limited funding                                                     Predictable funding over time

    Team disbands                                                      Team owns the product and results

    No incentive to automate                                   Automation improves quality and speed

    Incentives based on schedule/budget            Incentives based business value

    This does not mean there won’t be projects in the future, but there will be a combination of products and projects in most large enterprises. Most likely, we will see projects will be the way new products are proposed, evaluated and conceived. However, once the product is launched, the product team then will operate under a product model and mindset.

     

    About the Author/John Jeremiah

    John Jeremiah_HeadshotJohn Jeremiah leads the Digital Research Team with the HP Software Applications Delivery Management team. He is a software professional with over 20 years of experience including a variety of leadership roles with the U.S. Navy, IT consulting and Fortune 500 IT organizations. His previous roles span from application developer, project and program manager, Director of Testing Services, and Delivery Process and Methodology Director. Prior to joining HP, he was director of Testing Services and Project Delivery Services for Thrivent Financial for Lutherans, where he led the adoption of CMMI Maturity Level 3 process framework.

  • How Mature Is Your Automation Strategy?

    How Mature Is Your Automation Strategy?

    Working in Operations can sometimes feel like walking up a down escalator. The business puts relentless pressure on your team to overcome bottlenecks, accelerate the overall delivery process and grow the volume and frequency of deployments. You’re also faced with a growing number of service level requirements and demand for higher release velocity—all stretched across different platforms and increasingly complex deployment scenarios, on premise or hybrid.

    The answer to these challenges is IT automation. Scaling your automation not only secures continuous service delivery, it also frees your resources to focus on core activities and industrializes more service management processes, such as self-service portals for infrastructure provisioning.

    However, many organizations are still on low automation maturity levels because of various barriers, including:

    • Organizational inertia
    • Lack of process capability maturity
    • Lack of the right technology expertise
    • Mistrust and fear of getting replaced

    Do you recognize some of these barriers to automate faster, better and more in your organization?

    Here’s the problem: You can determine how much and where that IT automation is needed only after you understand the current state of your automation. Are you still at the manual stage (level 0), copying new release files in the production environment, adjusting parameters and restarting the application service via a management console using manually entered parameters, for example?

    Are you automating repetitive tasks through scripts, but need to do all the preparation work to run the script, frequently modify the scripts and script parameters based on changing context, start scripts manually, monitor their execution individually and look at the outputs each time a script runs? If so, you are on level 1—and you can do much better than that.

    Are you connecting scripts into sequences and deploying new releases using a run book automation tool (level 2), where integration with other tools in the release chain is still manual and context-specific parameters have to be set individually for each execution?

    Or have you scaled the heights of process automation (level 3), where you benefit from the automated deployment of the entire process, including automated retrieval of the right parameters at the right time and in the right context triggering of automated deployments (either using commands or driving run book automation tools), confirming completion and updating records? If so, you are doing very well and can reach the last (final) maturity level by adding dynamic composition and configuration of processes based on the real-time context.

    Understanding your automation status and barriers helps you decide how and where to invest in the next automation steps. Having a baseline means you can build a business case, apply goals and targets to your organization, and measure your success as you progress.

    An Automation Maturity Assessment Service can be applied to create this baseline, identify gaps and provide recommendations, which result in lowering the manual effort and increasing your IT automation maturity and operational efficiency. Consultants initially review your current IT infrastructure and your software delivery processes and release management processes. Next, they perform discovery interviews to gather information on core processes relevant for automation. Services are subsequently rated in terms of their automation maturity and their potential for automation. The qualitative results are then correlated with operational measurements and KPIs to understand the impacts of low maturity on service levels and competitiveness.

    The assessment might find, for example, that your development team changed its deliverable for a particular application to a Docker container, which is currently not integrated in your automation release and deployment process. Your tool already supports Docker, the assessment finds, and it can be easily integrated. The benefit to do this is assessed as ‘medium,’ while the cost is ‘low.’

    Based on the results, a business case can be created or a DevOps roadmap can be crafted.

    You already know the benefits of IT automation. By allowing your automation to mature, you open the door to even greater cost savings, increased efficiency and lower risk.

  • Let DevOps be a business process

    Let DevOps be a business process

    I just returned from an amazing time at the first Camp DevOps in Boulder, CO. It was held at University of Colorado, Boulder and in conjunction with Gluecon 2014. This is the first conference I have attended that was singularly focused on DevOps.  I found the three track format at the show had something for everyone. A technical track, a business track and some great DevOps round table discussions with great panel speakers. My takeaway was that DevOps is not just a cultural thing as some claim. DevOps needs to be perceived more as a business process or it will just be a passing fancy. Some may disagree with that view but 35+ years of IT industry experience gives me a bit of a long view.

    Gene Kim enlightened me on some issues in his recent response in the Wall Street Journal with some facts about what is going on within traditional legacy Fortune 500 companies. They are implementing DevOps strategies in a big way. My take is that it is not noticeable within the Fortune 500 because DevOps is viewed by the Fortune 500 as a business process, as opposed to being an implementable organizational structure. Sort of like the DevOps is not really a job title argument.  If it is a business process, no one has DevOps in their title, but it doesn’t mean DevOps is not being done there.

    I think most of us want to see DevOps cross the chasm and become a de facto standard. Since Patrick Debois first coined the term “DevOps” there is no question that DevOps has developed into a global movement. Of course DevOps has its cynics. Pessimists say DevOps is a new name for a Sys Admin,  the flippant say DevOps is just a front for some fanatical developers trying to liberate the world from operations or DevOps is just some foolish operations people trying to make nice with Developers. That it means the extinction of QA job is another familiar mantra.

    I’ve spent a lot of time trying to understand the lack of cohesiveness within the DevOps movement and everyone telling everyone else what DevOps is and what it should be. As with anything else the marketplace will decide the future and fate of Devops. During this process, I’ve begun to notice a common misconception that I think is fueling much of the reactions that some people have to DevOps ideas. Holding DevOps back is not a technology problem or a cultural problem.

    In order for DevOps to happen I realized we all need to keep pushing this philosophy forward.  We cannot worry ourselves with culture, commercialization or technology. Technology plays a critical role in facilitating solutions to DevOps problems. However, DevOps itself is, at its core, a business issue. The most fundamental business process in any company is getting from concept to completion with the end result of profitability.

    If you remove the perspective of the business process, what is left? You’ve got a whole lot of people and groups doing their own thing. Lost is the motivation to battle inefficiency, duplication of effort, turf wars, and disparate groups. It’s a free for all.

    If we don’t let DevOps take its course within the market place and embrace the business process, jobs are lost. We are able to do what we do because of the business of DevOps. If we don’t all push the commercialization of DevOps then we have nothing but a chat room to talk philosophy.

    The sole purpose of DevOps is to enable, big and small alike, business to react to market forces quickly, efficiently, and reliably. Without the commercialization, there is no other reason for us to be talking about DevOps problems, much less spending any time solving them.