Tag: development

  • Shifting to Product-Centric Work in Utilities

    Shifting to Product-Centric Work in Utilities

    Large organizations across the services spectrum are transforming from project-centric operations to product-centric way of working. Customer centricity is driving this transformation, as product-centric organizations put customers at the center of everything they do. Such a transition is largely dependent on how information technology solutions are deployed in the said organization.

    This article looks at the importance of a product-centric way of working for utilities organizations, particularly the power sector, which is looking to transform customer interactions by revolutionary use of new digital technologies and solutions such as smart metering and smart homes.

    At the onset, power utility organizations should focus on shifting to a product-centric way of working in areas that show promise to deliver innovation and digital enterprise such as customer analytics.

    Fig. 1: Current State of Play in Most Power Utilities

     

     

    Fig. 1 outlines the current state of play at most power utility companies, where organizational silos and application silos lead to customer challenges in understanding the products and services offered, as well as productivity losses and an increase in reaction times to changes demanded by business and regulation.

    In most power utilities, silos exist in business units which are reflected in how the applications supporting those business units are organized and managed. This leads to duplication of effort, work and applications, as well as a waste of time and resources. Customers are often confused about multitudes of service offerings and various channels. There is also an inherent delay in responding to challenges thrown by changes to regulation and/or business environment.

    This is changing, though, and one can look at the “meter to cash” processes for a reflection of market realities and customer empowerment.

    In our experience, there are four key drivers of a move toward product-centric model:

    • Digital Core – to evolve, innovate as well as leverage cloud, DevOps and agility to support the business.
      • DevOps practices and agility from ideation to sunset.
      • Encourage innovation.
      • Digital ready systems.
      • Focus on Product value.
      • Lean planning and maintenance.
    • Intelligent Enterprise – to optimize the cost and delivery of services and encourage innovation.
      • Automation to support business agility of the power utility.
      • Autonomous operations to support power distribution and customer management.
      • Decisions based on insights drawn from customer and market data.
      • Focus on the innovation of products, services offered and customer engagement.
    • Experience Quality focused on improving customer experience.
      • Product centric service delivery.
      • Business agility.
      • DevOps practices.
      • Experience centricity.
      • Product and experience-focused metrics.
      • Command center that is aligned with the business.
    • Service Management and integration for scalability and unification of service delivery in the power utility while retaining a multi-supplier ecosystem as needed.
      • Continuous improvements.
      • Standardized deployment and integration management.
      • Collaboration in a multi-supplier scenario.
      • Service lifecycle management.
      • Information technology service delivery performance management.

    This transformation to a product-centric organization ensures that processes, people, workflows and decisions power the power utility’s ability to:

    • Customize services and offers.
    • Improved and faster response to customer requests.
    • Consistent and distinguished cross-channel experience for customers.
    • Boost productivity.
    • Eliminate waste.

    Shifting to a Product-Centric Model

    The product-centric model of delivery uses Agile, DevOps and Lean principles for strategic planning to ensure uncertainties and lack of information do not derail the delivery of services to end customers. A product-centric model places importance on relatively shorter horizons of budget and effort planning over massive planning at the beginning of a financial year. This is important, as a power utility is likely to be able to plan better for a quarter at a time rather than a complete year, particularly in the current economic climate. This not only ties well with the goal of business agility but also ensures improved planning and budgeting, as there is more information available about business goals a quarter at a time. The new teams organized around business capabilities, as shown in Fig. 2, then plan the product backlog, execute, test and deliver business value
    to business and customers continually.

    Fig. 2: Shifting from technology to business-aligned value streams or product-centric organization

    Power utilities also need to change and improve their technology-centric solutions to help with forecasting and data analytics. The product-centric organization helps with this goal by identifying gaps for closure and aiding the creation of self-organizing teams that then take on the goals of the organization to address all the identified gaps, including in areas of forecasting and analytics.

    Fig. 3: Organization design – a product-centric organization

     

    Fig. 3 shows a sample organization design for the product-centric model. The figure also shows the breakdown of the structure from business function to value steams to products or product groups and, finally, applications delivering value—all the while ensuring that the goal of customer-centricity is at the center of every decision.

    Governance and Metrics

    A very important part of creating and adopting a product-centric model of functioning at a power utility includes focusing on the governance of the transformation process, as well as business results accrued from the transformation. The acceleration and adoption of Agile and DevOps practices on the technology side can be tracked through qualitative adoption measures. This leads to product level performance improvement, resulting in better products and faster delivery, with the product delivery mindset focusing on customer-centricity, leading to trends in:

    • Faster time to market.
    • Improved business satisfaction.
    • Improved quality.
    • Reduced information technology cost.

    Other than this, following metrics and measures be focused upon:

    • Adoption Measures.
      • Adoption maturity.
      • Competency/skill index.
      • Operational excellence.
    • Product Team Level Measures – measured at team level per sprint.
      • Productivity measures such as team velocity and throughput.
      • Stakeholder satisfaction measures such as product owner demo satisfaction.
      • Quality measures such as percent automated unit test coverage and test effectiveness.
      • Business effectiveness measures such as business value delivered per feature and requirement readiness cycle time.
    • Product Group Level Measures – measured at product family level per month or quarter.
      • Lead time to change.
      • Cost of requirement change.
      • Release frequency.
      • Cost of rework.
      • Mean time to recover.
      • Application stability.
    • Portfolio Level Measures – measured at portfolio level per quarter or half-year.
      • Delivery satisfaction index.
      • Customer satisfaction index.
    • Team Satisfaction Metrics.
      • Team happiness index.
    • Coaching Effectiveness.
      • Coaching feedback.
    • Team’s Self Organization Quotient.
      • Product ownership.
      • Sprint health.
      • Team health.
      • Technical health.

    Potential Areas of Benefit for a Power Utility

    There are at least four core areas in which a power utility can expect to experience quantifiable benefits by transforming to a product-centric model of operations. They are:

    • Budget and Plan
      • Cost and time are the most valued commodities in a tightly run power utility.
      • A product-centric model ensures money, effort and time are allocated based on the validation of investment already made in an initiative.
      • Improvement in prediction of timelines, effort and benefits of an initiative because of cadence and timeboxing inherent to the product-centric model.
    • Managing the Capacity
      • The key focus is on alignment with business and continuous delivery of business value.
      • The cost of delay and the cost of waiting are also reduced.
      • Focus on value delivery with quantified business benefits.
    • Governance of Programs
      • The governance in product-centric organizations is about the exercise of control on the quantification of benefits.
      • The focus in a product-centric organization is on “building the right things the right way.” Rationalization of cost, elimination of waste and focus on business value are direct by-products.
    • Managing the Demand
      • Continuous visualization and management of demand is an area where benefits are accrued as needs and ideas flow into the strategy filter continually from several sources.
      • The product-centric model allows the continuous elaboration of light use cases to ensure value is correctly calculated and assigned to each use case.
      • The program, portfolio and product backlogs are continuously evaluated to ensure that there is a cost-benefit sense to each item.

    Conclusion

    Some of the benefits of a product-centric model usage at power utilities are stated below:

    • Customized electricity plans for efficiency, cost or comfortable consumption.
    • Improvement in reliability.
    • Creation of environmentally sustainable renewable programs of power for the more aware customers.
    • Incrementally move toward a “business as usual (BAU)” relationship with regulatory changes.

    A product-centric model at power utilities can also help bridge the data divide to improve data and analytics usage and enable creation programs in the following areas:

    • Services and products that the customers are most probable to use.
    • Optimized collection and prediction mechanisms to create plans to encourage timely payments.
    • Create pre-paid services.
    • Plans for direct control of load which allowed the utility to reduce air conditioning kind of machinery during peak usage and in return recompense customers.
    • Improve pattern recognition for delinquency and fraud management.
    • Cross-selling opportunities.
    • Targeted sales and marketing campaigns.

    This article was co-authored by Anurag Choudhry, Enterprise Architect, Manufacturing & Utilities BG at Tata Consultancy Services.

    — Anshu Premchand

  • No-Code/Low-Code: Empowering Collaboration

    No-Code/Low-Code: Empowering Collaboration

    No-code/low-code will create seamless integration between cloud platforms, tools and utilities

    Recent developments have created a massive shift to working remotely, which, according to a recent Gartner survey, is not a temporary move. The survey indicates that 74% of CFOs plan to continue some form of permanent remote working. This in turn paves the way to even greater adoption of cloud-based applications and software to enable businesses to stay connected, collaborative and productive.

    While the ongoing pandemic has helped to underscore the importance of cloud-based applications, it has also revealed that these systems don’t always work well together—an oddity, considering the promises of seamless collaboration, transparency and productivity of cloud platforms. But the reality is that while many cloud solutions claim to be “platforms,” they are not. There are, in fact, only a handful of platform companies, including Salesforce, Adobe, SAP and Microsoft. The rest are tools and utilities that should snap into a larger ecosystem.

    Many organizations think they can implement disparate cloud tools and seamlessly switch them on like a light bulb. But that’s just not the case. This is why no-code/low-code will both end the “cloud platform masquerade” and create seamless integration between cloud platforms, tools and utilities.

    The Rise of No-Code/Low-Code

    No-code solutions typically allow non-technical developers, such as business users, to build or modify apps without having to know any programming languages. Low-code applications, for their part, are enterprise-grade systems built by professional developers that offer drag-and-drop components and require little or no hand-coding.

    The beauty of no-code/low-code applications is that they do not require an army of expensive IT consultants and systems integrators to get them to speak to each other. Instead, these applications are designed to plug seamlessly into an integration platform as a service (iPaaS), a suite of cloud services that connects various applications, systems and technologies within the cloud. As a result, no-code/low-code cloud apps can easily communicate and share data even when they don’t speak the same language.

    Think of it as Google Translate for cloud software. With iPaaS, you can stitch together disparate systems that don’t even know they’re communicating to work together in one smoothly functioning, integrated process.

    The Benefits of No-Code/Low-Code

    The benefits are clear. Instead of handing over piles of cash to systems integrators, organizations can reinvest that money in their own companies. What’s more, they can gain greater visibility into their data, enabling them to correlate information and create contextual insights around many aspects of their business. Individual departments can interact with and combine various applications on their own, without the aid of IT, to quickly and seamlessly model new business processes. That in itself is transformational because it puts the power back in the hands of the non-technical professionals, who know better than anyone what they need to accomplish.

    Going forward, I believe organizations should demand cloud-based tools and systems that offer a no-code/low-code component. After all, systems that don’t seamlessly integrate with each other pose a clear impediment to success. For instance, something as simple as a sales lead can have 10 different meanings in 10 different Martech systems. In one, a sales lead may be a click, while in another, it may be a personal contact. This kind of confusion can be deadly to your marketing efforts.

    Moving Forward

    Greater visibility and orchestration will be more critical than ever in our post-pandemic world. As organizations are figuring out how to respond to the rapid upheaval caused by COVID-19, embracing no-code/low-code applications presents a vital path for improved collaboration, transparency, efficiency, productivity and decision-making—all critical requirements if organizations are to overcome this period of crisis and succeed in the future.

  • F5 Networks Launches Next-Gen ADC Based on NGINX

    F5 Networks Launches Next-Gen ADC Based on NGINX

    F5 Networks this week launched version 3.0 of its NGINX application delivery controller (ADC) that adds application programming interface (API) management tools, analytics and monitoring tools, a service mesh, a certificate manager, a developer portal and integrations with multiple continuous integration/continuous deployment (CI/CD) platforms.

    Ken Bocchino, director of product management for NGINX at F5 Networks, said as the first major update to the NGINX Controller since F5 Networks acquired NGINX last year, the 3.0 release represents a concerted effort to reduce the total cost of DevOps by bundling many capabilities that previously would have needed to be acquired separately.

    In addition, NGINX Controller 3.0 reduces the complexity associated with building DevOps workflows because all the components that make up NGINX Controller have been pre-integrated, said Bocchino.

    Based on the open source NGINX proxy server, NGINX Controller is the mechanism through which commercial capabilities are provided and supported as part of the NGINX Plus subscription service offered to enterprise IT customers. Previous iterations of ADCs were much more infrastructure-centric than application-centric, noted Bocchino.

    While F5 Networks naturally would prefer IT organizations to consume all those services, Bocchino said the ADC has been designed in a modular fashion to enable organizations to consume services exposed as REST APIs as they see fit. A future version of the NGNIX proxy server will be able to support multiple types of service meshes, including the lighter-weight offering created by the NGINX team that will become available later this year as part of NGINX Controller 3.0, he said.

    Bocchino noted F5 Networks envisions the NGINX Controller playing a major role in driving further convergence across network operations, security and DevOps teams. NGINX Controller 3.0 facilitates that goal by providing a self-service portal along with role-based access controls and modular workflows that eliminate the need for tickets to be issued to achieve every IT task.

    It’s not clear at what rate that convergence is occurring. However, F5 Networks last year published a survey of DevOps and NetOps teams that suggests there is still a wide gap between NetOps and DevOps teams. The survey found only a little more than a third (38%) of DevOps teams cited the “integration of toolsets across vendors/devices” as a challenge to network automation. In contrast, almost half of NetOps respondents (47%) noted a lack of integration as a problem, second only to a lack of automation expertise (49%).

    F5 Networks by acquiring NGINX is betting than most organizations that have already embraced NGINX proxy server software would rather extend those existing capabilities versus replacing their ADC with a new stack of software based on, for example, the rival open source Envoy proxy server being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    How the proxy server war and associated ASC platform wars will play out is still anybody’s guess. What is clear is that DevOps teams will need to access a wide range of programmable networking and security services easily to take DevOps to the next level.

    — Mike Vizard

  • JFrog ConanCenter Extends DevOps Reach to C++

    JFrog ConanCenter Extends DevOps Reach to C++

    JFrog this week announced it has updated ConanCenter, a repository for storing and discovering software packages that can be downloaded for free, to include support for C++ artifacts.

    Jagan Subramanian, vice president of community and partner engineering at JFrog, said ConanCenter provides a repository for the open source Conan package manager that JFrog includes as part of its continuous integration/continuous delivery (CI/CD) platform. By making ConanCenter available free of charge, JFrog is trying to encourage organizations that rely on C++ to build applications to embrace best DevOps practices, Subramanian said.

    JFrog is also making available a free Community Edition of its Artifactory CI/CD platform for C / C++ available for download and later this quarter plans to integrate ConanCenter with other JFrog tools to make it even easier to securely access packages.

    As a general-purpose programming language, C++ has been employed for decades to build applications in IT environments where resources are constrained, such as embedded systems. Subramanian said many organizations that rely on C++ to build those types of applications are experiencing the same pressures to accelerate application development as the rest of their software development colleagues.

    To make it possible to achieve that goal, he said, JFrog is now extending its DevOps portfolio to include support for applications developed using C++ tools. ConanCenter not only provides a means to discover artifacts based on the metadata they generate, but it also provides a list of configuration options and a free binary building service that can be applied across multiple operating systems, platforms and compilers.

    Despite its longevity and the rise of alternative programming languages, C++ continues to fulfill a unique role across a range of vertical industries. There are still plenty of C++ developers are that building some of the most challenging applications to develop. In fact, given the rise of robotics and internet of things (IoT) applications involving autonomous vehicles, interest in using C++ to build new classes of applications is on the rise. The ConanCenter repository promises to make it easier for C++ developers to share artifacts across those diverse projects.

    In terms of adoption of best DevOps practices among organizations that rely on C++, Subramanian said it’s still very early, as most are still at the proof-of-concept stage. However, he said most regularly experience all the pain points that best DevOps practices address, which should drive more organizations to embrace DevOps in the months and years ahead.

    It’s too early to hazard a guess as to how long it might take organizations that rely on C++ to embrace DevOps. Many of them have been relying on waterfall-based processes to build and deploy applications for decades. Nevertheless, just like in other programming environments, the need to build and deploy applications faster requires development teams to embrace change. As always, however, the biggest challenge when it comes to DevOps has little to do with the core technology platforms. Rather, the existing culture of the IT organization always proves to be the biggest hurdle.

    — Mike Vizard

  • Survey Sees Massive Adoption of Microservices

    Survey Sees Massive Adoption of Microservices

    Under increasing pressure to innovate faster, a majority (84%) of organizations taking part in a recent survey have already embraced microservices.

    The survey, conducted by Vanson Bourne on behalf of API management platform provider Kong, polled 200 senior IT leaders in organizations with more than 1,000 employees. Among the results, 89% of technology leaders agree that companies that are not able to effectively support microservices will be less able to compete in the future.

    The report also finds on average organizations are running 184 microservices, with 60% of respondents running 50 or more. The primary reasons cited for adopting microservices are improvements to security (56%), increased development speed (55%), increased speed of integrating new technologies (53%), improved infrastructure flexibility (53%) and improved collaboration across teams (46%).

    Kong CTO Marco Palladino said the report makes it clear that just about every organization is on a journey to making a transition to microservices as part of an effort to reduce reliance on inflexible monolithic applications. Initially, that transition involves lifting and shifting monolithic applications in the cloud before decoupling functions using microservices, he said.

    As part of that journey, Palladino noted, the survey also finds significant microservices challenges remain, including ensuring security (36%), integration with legacy applications (32%), the complexity of management (31%) and updating API documentation (31%).

    Despite these concerns, however, more than 80% of survey respondents who have adopted microservices report that their organization performs well against metrics for development efficiency, the ability to use new platforms, collaboration across teams and sharing of services across applications.

    Overall, a full 90% of respondents said securely connecting applications and ensuring performance at scale collectively represent one of the greatest technical challenges of the 21st century. Also, 71% said they believe that organizations would be out of business within six years if they fail to keep pace with innovation in their industry. For public companies, the urgency is even greater, with 39% reporting they believe organizations will be out of business in less than three years if they fail to keep pace with innovation. Overall, 57% of technology leaders feel organizations are concerned that they are at risk of competitive displacement.

    Pressure on IT leaders is high as a result. Nearly three-quarters of respondents (74%) agree that a failed digital transformation effort will result in a missed promotion, lost bonus or even termination. The report identifies the top three priorities for IT leaders as improving efficiency (47%), reducing cost (41%) and increasing security (40%).

    Technology leaders, however, continue to place the highest importance on the availability (75%), security (74%), performance (65%) and scalability (64%). At the same time, technology leaders are focused on faster development speeds (95%), increased collaboration (94%) and reduced deployment risks (93%) as key desired outcomes for adopting any new technologies.

    The challenges most cited in terms of achieving those agility goals are the complexity of using multiple technologies (35%), lack of automation (32%) and reliance on legacy technologies (29%).

    The survey also notes 83% of organizations are relying on open source software to become more agile. The most commonly used open source technologies are databases (64%), containers (48%), API gateways (41%), infrastructure automation (40%), container orchestration (37%) and continuous integration/continuous delivery (CI/CD) tools (36%).

    In terms of cloud adoption, Microsoft Azure (43%) narrowly beat Amazon Web Services (AWS) (42%), with Google Cloud Platform (GCP) coming in third at 27%.

    On the plus side, 78% of respondents said their organizations are increasing IT budgets in the coming year, with 27% of public companies expecting their budgets to grow 26% or more. Nearly 90% of companies will also be increasing headcount, with 56% hiring internally and 31% relying on more freelancers and/or outsourcing to meet hiring goals.

    Hopefully, with that increased funding more organizations will be able to strike that elusive balance between stability and innovation.

    — Mike Vizard

  • Pivotal Software Embraces OpenJDK

    Pivotal Software Embraces OpenJDK

    Pivotal Software has officially thrown its weight behind OpenJDK, the open source version of the standard edition of Java, by adding support for OpenJDK to the Pivotal Spring Runtime on its Spring framework.

    At the same time, Pivotal announced it is extending its commercial support for open source Apache Tomcat servers in addition to providing commercial support for all the major open source Spring projects, including Spring Framework, Spring Boot, Spring Cloud and Spring Cloud Dataflow.

    Since 2011, Oracle, IBM and SAP have been making a case for employing OpenJDK. Ryan Morgan, vice president of engineering for the application platform at Pivotal, said that while other languages have become increasingly popular, the primary workhorse for building back-end applications in the enterprise remains Java. Now that Oracle has formally relinquished control over Java source code to The Eclipse Foundation, research and development into the legacy programming environment should accelerate. Oracle retains licensing rights to the name Java, but versions 8 and higher of Java Enterprise Edition are being converted to an open source platform known as Jakarta.

    Morgan said much of the work going forward would be focused on modernizing monolithic Java applications to make it either to turn them into microservices or at least make it easier for microservices developed in other languages to make calls via application programming interfaces (APIs) to those back-end applications. As enterprise IT organizations make the shift, they increasingly will rely on DevOps processes to manage the transition. The effort should accelerate the extent to which many organizations will need to rely on modern best DevOps practices.

    As both OpenJDK and Jakarta continue to move forward, Morgan said Pivotal is committed to continuing investment in the Spring framework, which has done much to make developing Java applications a much more agile endeavor. The most immediate benefit, of course, is the reduction of licensing fees associated with employing Java platforms. Many IT organizations that have mandated open source code-first and adopted alternative programming languages now may want to reconsider their options, especially when the number of developers who know how to write applications in more modern languages is comparatively small.

    Of course, it will take many years for enterprise IT organizations to fully make this transition. In the meantime, many of them will continue developing applications in Java simply because they have large teams that have mastered a programming construct that has been in place for three decades or more. Many of those same organizations may be making greater use of rival programming constructs, but Java and its descendants will play a major role in the enterprise well into the next decade. The primary challenge Pivotal will face is maintaining dominance of the frameworks employed to build new applications based on Jakarta and OpenJDK, in addition to updated existing Java applications.

    — Mike Vizard

  • DevOps Chat: Mainframe DevOps Update With Compuware’s Chris O’Malley

    DevOps Chat: Mainframe DevOps Update With Compuware’s Chris O’Malley

    Christopher O’Malley is one of the leading voices in the DevOps for mainframe community. He is relentless in advocating how the mainframe platform can not only exist but also thrive in today’s Agile/DevOps environments. His evangelism keeps his company, Compuware, front and center in the mainframe DevOps discussion and it really lifts the entire market.

    In this DevOps Chat, we catch up with Chris to talk about the latest release of Topaz, trends in the mainframe market and what we can expect in the near term.

    Chris is always a great interview with lots to say and this interview is right on point. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. This DevOps Chat features a return of our friend, Chris O’Malley, CEO of Compuware. Chris, happy 2019 and welcome back to DevOps Chat.

    Chris O’Malley: Thank you and glad to be here, Alan.

    Shimel: Absolutely. You know, Chris, it is. It’s 2019; DevOps continues to mature. And I think one of the trends that we’ve seen, certainly over the last year and I expect it to even accelerate this year, is changes are coming to the DevOps and mainframe market. Right? Mainframes aren’t going anywhere; in fact, shops that are using mainframes, I think their footprints are increasing, rather than decreasing.

    And, from what we see in our readers and in talking to them, is that they are eagerly anticipating new developments, new functionality, that their mainframe software will offer, that will allow them to leverage DevOps types of foundations, DevOps types of functionality. And, I mean, DevOps and Agile and, really, code word: continuous delivery, all of these new ways that we’re defining the modern software factory, if you will. You’re in the driver’s seat for it, right, Chris? I mean, Compuware is kinda leading this charge. What do you see – you know, put on your analyst glasses here. What do you see in the market?

    O’Malley: Well, first, just confirming what you said about the mainframe, is that the z14 has been awakening, I think, for customers and analysts, in terms of its success, so the z14 is the most successful mainframe model in over a decade. It’s had five consecutive quarters of year-over-year growth, which probably hasn’t happened in maybe forever. And, as you said, the reason that’s happening is the mainframe is still unmatched in terms of its reliability, its performance, its security, its transactional efficiency. And all of those things, all those virtues, are incredibly important in a digital age, where you try to basically create a customer experience through software. So the mainframe, as you say, it’s not just doing well; it’s actually doing better than historically because of the digital age.

    Shimel: Mm-hmm.

    O’Malley: So, just giving my disposition on the mainframe and the mainframe’s role within DevOps, I think, if you kinda zoom out a little bit to make sense of what’s happening to the mainframe, you gotta start first with the fact that all of these companies that use mainframe are of a mindset that “We’ve gotta be customer-centric. We’ve gotta serve our customers, whether they’re individuals, if they’re federal agencies, whether they’re citizens or it’s business-to-business.” But, for 100 years and for 100 years from today, companies that are the most customer-centric, obsessed with customers, do the best.

    And, when you look at kinda this modern age, to do well from a customer-centric perspective, you’ve gotta create awesome digital experiences. And that’s done by writing software. So companies – you know, and Amazon has taken the lead in a lot of these kinda more newer-age companies. They’re incredibly good at taking ideas that matter to customers – and, again, it’s usually through digital means, increasingly – rapidly turning those into deliverables that make a difference. And, whether it’s centered on creating these awesome experiences and when they kinda look at the measures of what they’ve gotta do better to turn those ideas into deliverables, they’ve gotta be really good at velocity, how fast they do those things. They can’t do it in ways that compromise quality, so quality has gotta be something that’s constantly getting better and they’ve gotta become more efficient.

    I mean, in the manufacturing space, they talk a lot about getting rid of non-value-added efforts and thinking about retooling things that are a cause for technical debt, that encumber your ability to increase velocity and improve quality, so you’ve gotta fixate on the efficiency side of it. So these three metrics are emerging as foundational to improving things like customer sat and improving financial performance.

    So, when you start now getting closer to large enterprise IT, you’ve got a mainframe, these ideas that matter to customers don’t neatly fall either on the mainframe, in terms of the coding work that’s gotta be done or the cloud or some other platform, almost always, these ideas span these platforms. So there’s a necessity to improve velocity, quality, and efficiency across the entire enterprise.

    So, you know, the mainframe, historically, has been this kind of silo-ed organization that had its own culture, its own set of processes, its own set of tooling. And, as you said, the mainframe’s not going away for all the right reasons. In terms of creating these awesome experiences, reliability matters. Performance matters. Security matters. How efficiently you do that, from a cost standpoint, matters. But you gotta draw the mainframe to be a like system and make it different only in syntax from these other platforms.

    So there’s a strong move within these large enterprise ITs to break down this silo, get rid of a house divided against itself, bring the mainframe into a culture that’s centered on innovation, not on maintenance, bring it from waterfall to Agile, to bring it to a tooling set that’s familiar to non-mainframe platforms, the products like Jenkins and SonarSource and SonarLint or Paris. All these type tools that are used aggressively to improve velocity, quality, efficiencies on these other platforms, bring these to bear on the mainframe.

    So that’s what’s causing, I think, the mainframe to be in this kind of disrupted state of trying to get the culture to move, getting people to think and behave differently, to embrace this kind of new order of how work is done, Agile techniques specifically, and to get away from – you know, the mainframe has always been selectively automated in incredible ways. I mean, the transaction volumes it can support are unmatched within the marketplace, but it’s selective automation, not intrinsic automation, which is a big part of what DevOps tries to push. And getting rid of non-value-added work on the mainframe and getting to the point that the value-added work can be done, again, faster, greater-quality, greater-efficiency.

    So that dynamic is now gone from kind of innovators and early adopters within the mainframe market, you’re now getting into more of the early majority, so you’re seeing it more prod-based, in terms of people looking at the mainframe as that “We’ve gotta make this like any other platform.” And I think the success of the z14 makes sense, why it’s doing so well. Not just better than the z13, but better than previous releases over in the last 10, 20 years, so it’s exciting times in the mainframe. And I think its success is gonna be something you see emerging over the next ten years.

    You’ll see fits and starts and, obviously, problems, but one of the things that’s making me so excited – you’re seeing successes in the market that are outrageous. We’ve got customers at Compuware that are increasing their development productivity by a factor of 4, I mean, a 400-percent increase in productivity, so they’re getting 4 times the number of story points completed within a release cycle. They’re taking testing time from weeks to minutes and with better quality. And, when that is understood by customers, you know, if you can go from weeks to minutes, that’s a lot of non-value-added work that you’re doing, right? That’s like burning money in the parking lot because a customer’s not gonna give you more money to do the same or less quality in what you can do in minutes, as opposed to somebody that’s a laggard doing it in two weeks.

    Shimel: Absolutely.

    O’Malley: So you’re seeing these amazing success stories. Again, it’s not just our tools; it’s _____ –

    Shimel: No, no, it’s important – Chris, it’s that 10X, right? Everyone’s looking for that 10X. And we’re starting – you know, 4X is great; 5X is better. We’re getting those – we’re hearing success stories, the 10X success stories, with mainframe. And it goes back to something else you said, that, instead of people saying, “Oh, I’m winding down my mainframe or I’m migrating mainframe,” no, I’m looking at a ten-year roadmap on mainframes. It’s not – a couple years ago, there was this – I don’t know – fake media, fake news, about “Yeah, well, it’s here now, but we gotta kinda wind down.” What you’re saying about the z14 is exactly right; it’s bigger than anything that’s come before it, in essence, right?

    Here’s another thing, though, Chris, and I’m interested in your take: kudos to the mainframe software market and vendors, who are recognizing – not all of ’em, not all of ’em, but the ones who are, the enlightened ones, who are recognizing this and are capitalizing on it by bringing the tools the market wants to bear. It’s more than just the hardware, right? The hardware’s phenomenal – I’m not gonna deny that; IBM has done amazing with the z14 – but the software vendors, including Compuware, right – take a bow – have really delivered. You guys have a new release coming out or just came out, is that right?

    O’Malley: Right. It’s the 17th consecutive quarter that we’ve come out with new capabilities, upgrades to our classic offerings and integration with awesome and preferred DevOps tools, so, yeah, we’re very excited about this newest release.

    Shimel: So talk to me. Give me the three biggest things that get you excited on this release, Chris.

    O’Malley: So, each quarter, we’re turning the crank in terms of trying to nail the jobs that are changing, right? As I explained earlier, when you’re going from waterfall to Agile and from selectively automated to intrinsically automated, you’re trying to go from maintenance to innovation, the jobs that people have to do change radically. And they change radically in ways that are difficult to achieve. I mean, when you’re working on the mainframe, you’re working with large code bases, large in terms of the quantity of those code bases and also the size of any one of them.

    So these techniques, at a high level, just seem obvious, but the practical things that need to be done from an innovation standpoint to help people to nail these things, it takes a lot of innovation. I mean, we’ve had to do a lot of work to get to the point where you’re seeing orders-of-magnitude improvement in the way people develop, the way people test, so this latest release is just another chapter in that story.

    So we came out with Topaz team profiles, so that’s a good example of a capability that allows those that are working on systems to basically be able to store their configurations, the inputs and outputs of these applications, the test artifacts that are used, and build those artifacts and configurations in ways that can be shared broadly within teams or across the organization. That’s important for a couple things – one is the work to do that, you wanna do it once and then do it once for every one ’cause, in the DevOps mindset of continuous improvement, you wanna get rid of things that aren’t value-added, things that customers won’t pay for.

    So, in creating this capability, we allow now, as teams get spun up, right, you get a team that’s gonna work on a two-week sprint, you want them, out of the gate, to be productive. So being able to share profiles day one, with people that may have never worked on these systems before, is crucial so that you’re productive in the first minute of the first day.

    You also have situations where you’ve got, instead of technical debt issues, maybe a team, a large team, that you wanna go after certain work. It’s gonna help to improve the future throughput of the incremental efforts you have, from a development perspective, in the future. And you’re gonna bring large groups of people to work on something and that may be an outsourcer that you’re engaging; it may be new college recruits that you’re engaging. But you, again, want those people to be as productive as possible, as quickly, so, if you’ve got an experienced person on your staff that can create all those configurations and then share that broadly, again, you’re gonna lessen the ramp-up time for them to do their effective work.

    So, again this is another example of us thinking about the mainframe going from waterfall to Agile, at scale, and having a scenario where it’s not just people that have been on your staff for 30 years, working on the same subsystems of your applications, every day for their entire career. Now, ’cause ideas are paramount and where people work has more to do not with what they know but what the company wants to do in better servicing their customers, so there’s more of a randomness to the work and a changing nature to the work, and what you work on is fluid. So we’re really thinking deeply about the implications of that and, for profiles within Topaz, that’s a major step in the direction of getting a different way of working within IT.

    The second thing that we’ve released is another Jenkins plug-in. Jenkins is a central part of CI/CD pipelines, in terms of the automation side of it, and we’re constantly thinking about “What are the things or plug-ins that need to be created to make the mainframe equal to any other platform in all ways, other than syntax?” So JCL, Job Control Language, is a very important part of how programs are run within the mainframe. Creating a plug-in to help bring it into the CI/CD pipeline efforts and the automations efforts was a crucial thing that needed to be done, so it’s a contribution, from an artifacts standpoint, that, again, takes another step for our customers.

    And then, lastly, is in the area of testing. Compuware is the leader, if not exclusive, provider of unit and functional testing as a combined offering. It’s a necessary part of the job that people have to do within Agile, with this concept of shifting left. The developers aren’t just coding; they’re coding and testing, both in terms of bugs and performance, and becoming much more extended in terms of their role. And so their accountability and responsibility is bigger.

    So they need tools, like unit and functional testing tools, to participate within a two-week sprint process so that their deliverable, at the end of that cycle, is one that’s close to bug-free as possible and not putting future work into the system where it comes back as some quality issue 6 months later, 12 months later, when it runs into production, or, you know, as usability concern. So these three things are another turn of the crank, if you will, and Compuware’s offered to help customers nail these jobs, these new jobs that are created within kind of Agile work environments and DevOps work environments.

    Shimel: Excellent. Anything else on the new release before I go off on another direction?

    O’Malley: No, it’s just we’re very excited ’cause we released a technology called “zAdviser,” six months or so ago, which is a method of collecting what business KPIs for customers and then looking at, actually, stats relative to our products, so we can see kind of the behavior of developers. And we’re working with companies collaboratively to treat their people as they should, like high-performance athletes rather than slaves in a Roman ship galley. You can say, “Work harder. Work faster.” Well, you’ve gotta be constructive in helping to share best practices and methods that have a positive effect in things like velocity, quality, and efficiency.

    So, with every release, we’re seeing a significant increase in this KPI performance, so, as we’re talking about earlier, the mainframe is certainly on a march to become a first-class citizen within the digital age, within these enterprise customers, but the more _____ –

    [crosstalk]

    Shimel: I’m sorry; go ahead, Chris. Go ahead.

    O’Malley: Go ahead.

    Shimel: Well, no, I was gonna say, you know what I find interesting is, yeah, we’re talking about the mainframe machines, but so much of your focus is on the people, on the developers, on the team, because, at the end of the day, that’s the gold. Right? That’s the almost irreplaceable asset, are the people and the developers and the IT teams that are working on these mainframes. And it’s about empowering them. Right? So I think that it’s the right place to put the focus.

    O’Malley: Yeah, people –

    Shimel: Yeah, I –

    O’Malley: Just to restate the obvious here, but people matter most. When you think about the mainframe in the context of Agile and DevOps, asking people to change their role, though they’ve been around for 30 years, 40 years, dramatically – I mean, the day in the life in Agile and DevOps is vastly different than the day in the life of status quo. And it’s important that, as leaders, you’re promoting the appropriate culture and getting people to understand why they need to change, important that you’re giving ’em the necessary education, teaching them how to be effective in Agile sprints. I mean, that’s a different way of working. I mean, it’s not that you’re working 24 hours a day, but you’re definitely working in a more intense way. And then products matter then. The tools have gotta be enablers, not things that fight against your efforts to adopt this new culture and Agile nature.

    And, you know, I really try to express to IT leaders, “You gotta think about these things ’cause – ” you know, we use this example, the Gallup survey. Gallup survey have been doing this thing for 20, 30 years of employee engagement in large enterprises, and what’s most interesting about it is, over 20, 30 years, the employee engagement statistics haven’t really changed. And it’s disturbing when you actually hear about them. Two-thirds of employees in most large enterprises are not engaged, half of them are kinda, “It’s a job; I don’t care that much,” and 16, 17 percent are actively disengaged – they try to sabotage the efforts of the companies.

    So one of the biggest problems is engagement and employee engagement, and so I try to get people to understand – people matter hugely. And you’ve gotta give ’em the culture necessary to thrive in this more competitive age, you’ve gotta give ’em direction in terms of the process, the way that work is done, but you gotta give ’em the tools. You know, asking ’em to use mainframe tools out of a NASA movie from 1965 and thinking that something’s gonna happen is incredibly naive, so –

    Shimel: Absolutely. You’re not landing people on the dark side of the moon with that. Chris, we’ve got a few minutes left. I wanted to touch on another subject – we didn’t really kind of pre-talk about it, but I’m sure you’ve got some great views on it – I was out in Seattle last month for KubeCon, you know, Kubernetes, cloud-native. It’s a funny question to ask the mainframe guy the cloud-native question, but, certainly, containers are no strangers to mainframes.

    O’Malley: I mean, they’ve been on the mainframe for –

    Shimel: 20 years, maybe more, right? 25. So anything specific to Kubernetes in the Topaz or Compuware kinda roadmap that you can discuss right now? Or what effect do you see on your world?

    O’Malley: Yeah, so, when you think about kind of the flow of work in large-enterprise IT and what developers are fixated on, I mean, part of it is innovation and functionality that they’re trying to build, which is most important. I mean, that’s the value-added efforts of developers that make a difference in the eyes of the customer. And you wanna do that as quickly as you can, with the greatest degree of quality.

    But the other things you gotta think about are things like  quality itself. I mean, if you get anything that you release that’s got bugs in the system, how rapidly you can respond to it. That’s always part of the work that’s being done and I don’t know of any organization that doesn’t have some degree of bugs. And bugs may be software written improperly – and, again, our tools are helping to fix that – or usability issues, integration into other systems.

    There’s also the work of compliance and security that you gotta do, but this last thing is this thing, technical debt, right? That any code base that’s had any life to it, has meandered through the efforts to serve customers, it’s something that grows over time. And it has nothing to do with mainframe; it happens everywhere. You know, the cloud – you know, Amazon’s got debt. And you gotta deal with that technical debt, so, as you’re dealing with technical debt, the smart approach is to start using more of these modern techniques. SOA was kind of a philosophical approach to breaking down these larger systems into smaller subsystems. When I think about API enabling, REST Y enabling  these kind of smaller chunks, but you also wanna think about containerizing, using these as a form of containers, Docker being the method of creating the container, Kubernetes of being the way of managing these.

    So we do see this playing an increasing role _____, as people start really looking at affecting technical debt ’cause that gives you the biggest bang for the buck. I mean, you certainly wanna do it with any new functionality you’re doing, but you’ve got some huge numbers of lines of code that you’ve developed over four years that works awesome. I mean, it’s really good working code, but making it more manageable and getting rid of that technical debt. Part of that equation is RESTful APIs; it’s containerizing it and managing it more in a cloud-like fashion. So, yeah, you’ll see us enabling those tools.

    Our approach has always been to go to the edge of the mainframe and then we stop. We take care of what we know best and getting rid of these esoteric differences, but then, when we go off the edge of the mainframe, we work with all these other vendors. We allow SonarLint and SonarQube to do its work on COBOL, as akin to what it does with Java or C. Parasoft is a testing framework, allowing our products to work within that orchestration.

    So there’s all these tools that work in kind of the DevOps world that are preferred and we’re enabling them, so you should think of us doing things in support of Docker and Kubernetes over the long term. But, yeah, it’s an important part of making mainframe IP one that the throughput can constantly be improved and those techniques obviously help enormously.

    Shimel: Absolutely. Chris, I’m sorry to get you going ’cause it doesn’t take much when we start talking mainframes and DevOps, but we’re way over time and I need to wrap up. Hey, we’ll have you on, certainly, next quarter for the – what will it be? – the 45th time?

    O’Malley: [Laughs] We’ll be doing this and it’ll be our 1,000th. You and I will be in wheelchairs, talking about it.

    Shimel: By then, you should be down in Florida with me, but, anyway, Chris, it’s a pleasure having you on. Continued success with Topaz and Compuware. And we’ll catch up with you soon?

    O’Malley: Always a pleasure and anytime I can help.

    Shimel: All right.

    O’Malley: And thank you for the hard work that you do.

    Shimel: Thank you.

    O’Malley: _____ important _____ –

    Shimel: All righty. Chris O’Malley, CEO, visionary, leader at Compuware, on DevOps Chat with me today. This is Alan Shimel and you’ve just listened to another chat.

    — Alan Shimel

  • DevTest Scales Out in the Cloud for 2019

    DevTest Scales Out in the Cloud for 2019

    It’s 2019, which means a whole new year of advancements in all areas of technology. One topic that is near and dear to my “cloud” heart is the acceleration and maturation of development and test (DevTest) scenarios and solutions in the public and hybrid cloud space.
     
    I’ve been talking with folks and presenting on the movement of Dev/Test to the public and hybrid cloud for a couple of years now, and I have progressively learned a couple of things from those with which I have had great and sometimes very frank discussions. First, I learned that the definition of DevTest has expanded exponentially, with the movement to the different clouds. Second, I found that the terminology of “DevTest” just doesn’t fit a single threaded way of thinking any longer, such as “It’s just for developers.” Let’s take a closer look at these.
     
    Back when I was a young technician just starting  in the new world of IT, I was working primarily with programmers (they weren’t called developers or devs back then) who would sit in front of their green screens, writing huge applications with COBOL and RPG, or maybe writing shell scripts on a Unix system. They would test their code in different environments that were always on the same infrastructure that the production code was running (which we all know these days is wrong, right?). They didn’t have secondary hardware or OS installations to test against because it was just too expensive to accommodate and most of the code could not support that separation. 
     
    Fast forward the clock almost 30 years, and now the developers need to have logically separated and secure environments to provide accurate and meaningful testing of the code that is “born in the cloud” as well as those created on-premises. The next few years will bring a big push for developers to have their own self-service environments, extensive code portability and more secure isolation for their code. By utilizing container technologies, automation and rapid deploy processes for their code, more development groups will eventually become their own application development as a service. 
     
    DevTest solutions are also moving far beyond just testing code. Quality Assurance (QA) is already a substantial consumer of the cloud for their load, smoke and regression testing. I predict that there will be a huge advent across all roles within IT—and not just the ones of development and QA—that will take the plunge into the DevTest solutions. They will be running release scenarios on their rapidly and continuously updated OS versions, on all of the software-defined environments, while also adding software patch testing and issue mitigations. 
     
    Knowledge transfer, training and E-Learning also will increase the use of these landscapes over the coming years, with everything from purpose-built labs, globally connected classrooms and even enterprises expanding their hands-on learning management system (LMS) offerings to their employees and customers. 
     
    Finally, I would suggest that there will be an inflection point in the coming years in which the use of private, hybrid and public clouds for DevTest—and, eventually, production—will become transparent to the user to the point that, within the overall vision of what you need to accomplish, what cloud or combinations of clouds you utilize won’t matter any longer. Eventually, for infrastructure as a service (IaaS) at least, the cloud will go the way of hardware, which has largely become a commodity in the new evolution of the modern software-defined data center.
     
    Technology is moving incredibly fast these days, especially when compared to the days of old when I was coming through the ranks in IT. The DevTest solutions will continue to evolve, progress much faster and touch more people in technology—and even other professions—than ever before. Start building a solid DevTest design and implementation plan for whatever your business and IT goals may be, and invest in the solution for all of your IT functions. By embracing and utilizing what is available in the hybrid and public cloud space for DevTest, IT will be empowering more productivity and faster execution moving into 2019 and well beyond.

    — Mike Nelson

  • SauceCon 2019 Speaker Profile: Melissa Benua

    SauceCon 2019 Speaker Profile: Melissa Benua

    This is the second in a series of articles highlighting speakers at SauceCon 2019. SauceCon brings together the global community of Sauce Labs users and continuous testing experts to learn from each other and level up their automated testing and continuous delivery skills. This year’s event will be held April 23-25 in Austin, Texas.

    SauceCon speaker Melissa Benua loves horses and riding dressage. Derived from a French word that means “training,” dressage is all about creating strength, discipline and precision. It’s fitting, because she is also passionate about training and mentoring junior-level engineers and increasing developer efficiency—which she’ll be talking about in her presentation.

    At SauceCon 2019, Melissa will present “Continuous Deployment for ‘Mature’ Codebases.” I asked her why this topic was important to her. “When starting a new project, it’s easy to take advantage of modern agile development practices, because you’re starting from scratch,” she said. “However, the reality is that isn’t the case for most projects. Our challenge then is how we can take code that may be many years old and transform it into a lean, mean, continuously-deploying machine.”

    In her presentation, Melissa plans to deliver just that: a road map for getting to a release cycle that deploys on-demand from a one that may take weeks or months. She will leverage her personal experience in significantly re-architecting the deployment structure and offer practical advice to anyone managing a more mature codebase.

    Melissa has worked in nearly every software development role there is—dev, test, DevOps and program management—at companies big and small and somewhere in-between. She has created and run high-availability, high-quality services for PlayFab, Bing, Cortana and Xbox One, and now at mParticle as a senior technical lead.

    When she’s not poring over code or training newer engineers, Melissa enjoys spending time with her two small children—and of course, riding her horse. She travels extensively and presents at industry conferences worldwide.

    You can hear from Melissa and more than 30 other expert speakers at SauceCon 2019, the third-annual Sauce Labs user conference. To see a full list of presentations or to register, visit the SauceCon website.

    — Rebecca Cramer