Tag: mainframe

  • DevOps is a Lifeline to Connected Mainframe ROI

    DevOps is a Lifeline to Connected Mainframe ROI

    A new IDC white paper sponsored by IBM and CA Technologies reveals the adoption of DevOps is a hallmark of those organizations that are actively modernizing and integrating legacy systems such as a mainframe to support digital transformation.

    Early adopters are blazing a path for faster innovation and greater ROI.

    DevOps Delivers Mainframe Modernization and Integration

    I’m encouraged to see DevOps recognized as an important element in realizing a “connected mainframe” vision. Respondents demonstrated a continued commitment to modernizing their mainframe environment.

    The IDC study confirmed that leveraging Java on the mainframe was one of the most popular approaches. In fact, I’m constantly surprised at how few managers realize that these days, Java and Git can be used by developers in such a way that allows them to completely separate themselves from the mainframe “green screen” environment when coding or maintaining applications.

    DevOps automation has also helped organizations overcome many of the cultural and operational challenges to a fully end-to-end enterprise by aligning application development tools and orchestration chains across multiple platforms and teams.

    Adopt a Business-First Approach

    Customers I’ve spoken with are experimenting with DevOps for mainframe tools and practices, with many piloting new approaches across the life cycle. They’re immediately becoming more agile, realizing shortened development cycles, improved collaboration between distributed and mainframe teams and faster MTTR that maximizes availability. In all, these early adopters have benefited from increased speed to market, improved business agility and better platform economics.

    The IDC study concurs, identifying more effective delivery of applications and services as a powerful cost-saver, with savings of $58,900 per application achieved through increased developer productivity and day-to-day support efficiencies. By helping mainframe organizations to realize improvements at every stage of the application life cycle—from build through test, deploy and operate—DevOps delivers compelling benefits; for example, from our recent study Accelerating Velocity and Customer Value with Agile and DevOps:

    • Advanced DevOps users reduce the time taken to develop, test and release new applications by 42 percent.
    • Advanced agile users reduce their time to decide and act on new opportunities by 40 percent.
    • Advanced agile users accelerate the time to develop, test and release new apps by 36 percent.1

    Excited? I encourage you to catch up on the full IDC White Paper here.

    — Aline Gerew

  • Culture Comes First in Bringing DevOps to the Mainframe

    Culture Comes First in Bringing DevOps to the Mainframe

    One of the most difficult challenges in engineering, oddly enough, isn’t technical: the challenge is culture transition management. In my 20-plus years of managing engineering teams worldwide, I’ve led teams through countless organizational adjustments and process improvements toward high-performance and quality, beginning with QA segregation to CMMI to ITIL, AGILE and SAFe.

    Today, mainframe organizations have emerged as the focal point for enabling DevOps capabilities and practices. Why the mainframe? Well for starters, business critical applications rely on mainframe data and business components. These applications are mission-essential and that sustained innovation requires solution sets that deliver continuous testing, continuous delivery and continuous feedback on the mainframe platform.

    But culture comes first.

    Understanding Your Key Players

    In conversations with our customers we’ve observed an interesting dynamic emerging within mainframe application development teams. Within these teams are experienced developers who were instrumental in creating the applications that helped make their companies so successful. Over time, many have become set in their ways, adopting a motto of, “If it’s not broken, why fix it?” Such developers are not interested in trying out new things, including programming languages and tools used by the modern-day programmer.

    New to the scene are the millennials who have also taken up the mantle of enterprise software engineer. They are a bit more open-minded and bring a different programming language profile, including Java, .NET and C. These developers might be learning how to code APIs with the support of management, and have likely dabbled the basics of how to code iOS apps. Millennial developers are typically much more active online and, as a result, prefer to leverage Twitter and other social channels to stay informed with the development community.

    United We Stand

    Who, then, should be involved in the journey to realizing DevOps? The answer, of course, is both. Because we’ve heard it reinforced among our users we talk with in the CA Communities every day, at user groups and at prominent mainframe community events such as CA World and SHARE.

    You know it, because you probably see it in your organization as well. There are experienced developers: people who have deep knowledge of the applications in place, business intelligence, database tables, cross-application dependencies, batch execution windows and the general experience of how things work on the z/OS platform.

    Most importantly, they also know how to avoid breaking what’s working.

    And there are the millennial developers: people who are curious to learn about new programming languages, platforms, people who, with the advent of Agile development, and open source have played with things, tested them and are using it to enhance their skill sets.

    These people prefer to use modern user interfaces and tools to increase their productivity. Sometimes they might be tentative about making mainframe changes, not willing to risk their careers by breaking poorly documented code.

    Culture – Have it Both Ways

    While the interests of millennial and experienced developers may at times seem conflicting, both have pivotal roles to play in application development and will benefit greatly from the common sense practices of DevOps and agility that are coming to the mainframe platform. To survive and thrive, teams must unify to facilitate the change process. Most importantly:

    • Code must be accessed and modernized at the speed of business. Enterprise developers, testers and architects cannot be afraid to go talk to the “black box” that is the mainframe team.
    • Project managers can’t worry that a six-week turnaround for small changes will kill their hopes of meeting their delivery windows.
    • The delivery team—QA, release management and operations—can’t afford to sit around waiting for simple deployment steps to happen: when we can automate and integrate to increase deployment frequency.

    The promise of DevOps and agility on the mainframe is to fix this, and that’s why our engineering teams are actively building out solution sets that extend DevOps practices to the mainframe, including continuous testing, continuous delivery and continuous feedback.

    Curious about what it will take to bring DevOps to the mainframe? Catch some tips and best practices from Forrester Research principal analyst Rob Stroud, or hear from the leaders driving change in their organization in our CA World 2016 Mainframe DevOps panel.

    — Aline Gerew

  • Mainframe Apps and the Long View of DevOps Strategy

    Mainframe Apps and the Long View of DevOps Strategy

    IT is constantly under intense short-term pressures. Line of business (LOB) executives demand a competitive advantage in digital customer engagement now. Marketing leaders demand better customer analytics now. Legal demands better audit reporting now.

    In fact, much of the investment that companies are making in Agile, DevOps and continuous delivery is due to the urgent, short-term demands of the business.

    But short-term actions alone are insufficient for business success. IT leaders must also strategically navigate the vagaries of the digital economy over the long term—or, as Wayne Gretzky’s father taught him, to “skate to where the puck is going to be.” Otherwise, today’s small wins inevitably will lead to tomorrow’s egregious failures and inefficiencies.

    And integration of your mainframe apps and data into your enterprise DevOps tool chain is central to that long-term digital strategy.

    Here’s why.

    The Mainframe: Big, Nimble Iron

    A DevOps tool chain is only as fast as its slowest link. For most large enterprises, that slow link is the mainframe.

    Slow, waterfall-bound and underautomated mainframe dev/test processes are non-trivial—because mainframe applications and data are non-trivial. They typically are an organization’s most important apps and data. So if you can’t modify your mainframe application logic quickly or leverage your mainframe data in new ways easily, you’re uncompetitive toast in today’s fast-moving markets.

    Also, mainframe applications and data typically serve as the back-end systems of record for front-end mobile and web-based systems of engagement. Your ability to innovate and remain competitive when it comes to digital engagement and digital perceived value is, therefore, almost universally contingent on lessons learned from frequent and timely mainframe code drops.

    In other words, everything IT is under pressure to deliver—new mobile apps, better analytics, fulfillment of increasingly stringent compliance mandates, etc.—depends on bringing Agile, DevOps and (ultimately) continuous delivery to the mainframe.

    Just about everyone realizes this. Sure, there are some holdouts who still advocate something they call “bimodal IT”—which prescribes allowing the mainframe to languish in obsolete waterfall and dev/test practices while the rest of the enterprise moves forward. But bimodal lT has proven to be a mistake. An Oct. 31, 2016, Forrester Research report titled, “Predictions 2017: CIOs Push For Speed Amid Volatility,” shines a light on the fatal realities of bimodal IT:

    “In early 2016, many CIOs fell for the false promise of a bimodal strategy. They only pushed part of their team to adopt an accelerated pace — and left others unchanged. But those CIOs are already experiencing the shortcomings of operating at two speeds. Business peer frustration, polarizing and deteriorating cultures, and unsustainable operational complexities will continue, ultimately spurring most of these CIOs to course correct in 2017.”

    Given the explosion of mainframe-related innovation that has taken place in the past couple of years, enterprise IT leaders and industry analysts agree that “mainstreaming” it into enterprise DevOps is the right and necessary strategy (see as examples here and here).

    Some Good Things Take Time

    While instant gratification may be the order of the day—and gain without pain may be an all-too-frequent vendor promise—the reality is that great IT achievements all require effort, investment and time.

    Inclusion of the mainframe into your cross-platform DevOps tool chain is no exception. No CIO can achieve mainframe agility and cross-platform DevOps orchestration by simply waving a magic wand. But there is a clear, practical path to these goals for those with the requisite foresight and leadership.

    That path includes:

    • Modernizing the developer workspace. Most mainframe development is still performed in “green screen” TSO/ISPF environments that require specialized knowledge and limit staff productivity. A modernized, graphical workspace as part of a preferred DevOps tool chain will allow staff at all experience levels to perform dev/test tasks on both mainframe and non-mainframe applications.
    • Graphical visibility into existing code and data structures. Mainframe applications typically are large, complex and poorly documented. These attributes are a major impediment to mainframe transformation. The right tools enable new participants in mainframe DevOps to quickly and easily “read” existing application logic, program interdependencies and data relationships.
    • QA “shift left.” Early detection and correction of quality issues is a central principle of modern programming—and it’s particularly important on the mainframe, where there’s an especially low tolerance for error.
    • Initial Agile training and adoption. Once you put the right development environment in place, you can start shifting your process from a traditional waterfall model with large sets of requirements and long project timelines to a more incremental model that allows teams to quickly collaborate on user “stories” and “epics.”
    • Use operational data throughout the dev/test life cycle. By using operational data in the dev/test life cycle, your DevOps team can ensure that applications perform optimally in production. They also can significantly reduce your MIPS/MSU-related costs by avoiding excessive CPU consumption caused by inefficient code.
    • Agile-enable source code management (SCM) functions. Traditional mainframe SCM environments are inherently designed for waterfall development and thus are incapable of supporting Agile requirements such as parallel development on user stories. The shift to Agile-enabled SCM is, therefore, absolutely essential for mainframe transformation.
    • Automated release management. To keep pace with today’s fast-moving markets, you must be able to quickly get new code into production. That means automating and coordinating deployment of all related development artifacts across all targeted environments.
    • Cross-platform DevOps. Ultimately, you need to fully de-silo your enterprise environment so the mainframe becomes “just another platform”—albeit an especially scalable, reliable, high-performing, cost-efficient and secure one—that can be modified quickly as needed to meet the relentlessly evolving needs of the business.

    ‘What’s My Motivation?’

    With as much as IT departments have on their plates, it’s easy to continue putting off mainframe DevOps integration. But, ultimately, there are only two alternatives to doing so:

    • Re-platform your mainframe applications. This alternative has proven to be a costly and extremely risky undertaking that delivers zero benefits while it consumes resources and potentially disrupts IT operations, or
    • Continue doing nothing. This alternative puts your company at further competitive disadvantage and hastens the day when you’ll experience total mainframe paralysis due to the loss by attrition of all your veteran mainframe developers, QA specialists and operations staff.

    Viewed in this context, genuine investment in the mainframe—whether you call it modernization, mainstreaming or “Millennializing”—is the only reasonable course of action. Such investment starts improving your digital competitiveness immediately, while paving the way for a future where you can make the most of all your resources and confidently transfer platform responsibilities to your next generation of IT professionals. Including the mainframe in your broader DevOps efforts (while extremely valuable) does require commitment, and there are resources available to help. Just be wary of those who may talk a good game, but whose actions don’t really convey a strong commitment to users’ best interests. Fortunately, there are truly dedicated experts who can help every step of the way, and have direct experience modernizing on platform within their own organizations.

    It’s the smart, viable long-term DevOps strategy every CIO of a mainframe-enabled enterprise needs to adopt ASAP.

    About the Author / Christopher O’Malley

    chris-omalley2Christopher O’Malley is CEO of Compuware. He has nearly 30 years of IT experience with past positions including CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit, where he led the successful transformation of that division. Connect with him on LinkedIn and Twitter.

  • Mainframes and the Myth of Bimodal in DevOps

    Mainframes and the Myth of Bimodal in DevOps

    Rewind 20 years ago when we lived in a business world where big companies with unlimited resources beat out smaller, more strapped companies. The digital era—also known as the “age of the customer”—is changing all that. Where big once beat small, fast now beats slow. The DevOps approaches of startups often make them more adept at continuously delivering the innovations and conveniences that earn customer raves. Bigger, established companies often feel disadvantaged‚ shackled by an outdated culture and inflexible processes that haven’t kept up with the pace of change.

    Gartner coined the term “bimodal IT” as a way for older IT establishments to keep pace with agile startups. In the bimodal model, IT teams are separated into two distinct styles of work—one focused on supporting predictable, well-understood workloads with legacy systems and another that is more fast-moving, experimental and adaptable in meeting users’ constantly evolving demands and flourishing digital expectations.

    But the bimodal concept is not well-aligned to the spirit of innovation underlying modern application development and delivery. This is especially true for bigger organizations using mainframes. Here’s why.

    Successful DevOps Depends on Mainframe Agility

    The goal of DevOps is to roll out high-performing software and updates, ahead of the competition and with maximum speed, ease and cost-efficiency. In a DevOps model, software delivery can only happen as quickly as the slowest team. Modern web and mobile applications tend to span multiple platforms in their end-to-end transaction—from front-end web servers (systems of engagement) all the way back to mainframes (systems of record). IT places a lot of emphasis on systems of engagement, often taking back-end systems of record for granted. The reality is, the value in systems of engagement cannot be realized without the systems of record—making it essentially all one system. Developers supporting modern applications must be able to maneuver across and between all platforms, especially within mainframe code and data.

    Let’s look at a tactical example of this. According to industry research, 80 percent of the world’s corporate data—including customer data—continues to reside on mainframes. When a mobile web application is used to make a bank deposit, or purchase a product, for example, the transactional component of those applications typically is executed on back-end mainframes.

    This means mainframe applications are crucial to development efforts. What happens when mainframe developers and testers are locked into waterfall processes or don’t have the modern tools necessary to understand application logic or access mainframe data for testing? Frustration mounts and the overall innovative effort is unnecessarily stalled.

    Stability and Agility are not Mutually Exclusive

    The longstanding myth that stability and agile cannot co-exist is simply untrue. Unfortunately, it’s at the core of negative perceptions surrounding the mainframe today—people think the mainframe environment is too slow and cumbersome to support agile development. Development teams may think if they have mainframes, the only approach it can support is waterfall.

    The reality is, though, no customer will accept poor availability and performance in exchange for new features delivered quickly.  People with hands-on experience painfully understand that slow, waterfall delivery methods produce far greater quality issues and missed expectations, resulting in competitive risk. Additionally, large enterprises taking the “slow and stable” route give startups a head start in beating them to market, with offerings that customers want now.

    Alternatively, Agile process and DevOps tool chains enable scrum teams to test quality in terms of usability, function and stability early and often in the development cycle—when the time to remediate is the fastest and the cost the lowest. Agile process and DevOps tool chains build higher quality applications and enable continuous improvement in quality over time.

    Re-Platforming is not Necessarily the Answer

    Some DevOps proponents believe moving off the mainframe—to a supposedly more modern, commodity server-based distributed architecture—is the best way to circumvent perceived challenges to nimbleness and agility. But this is almost never the best answer. The mainframe retains its distinction as being the most powerful computing platform on the planet. It remains deeply embedded in large organizations, setting the standard for reliability, security and availability for mission-critical data and transactions. The new IBM z13 mainframe, for example, can handle the load of 100 Cyber Mondays every day, 365 days a year. Currently, mainframes process 30 billion business transactions per day. The post-modern mainframe is an engineering marvel unequaled as a system-of-record, business compute platform.

    The mainframe also offers cost advantages. Studies have shown that the mainframe is more cost-effective than commodity servers in handling the massive computing volume increases instigated by mobile applications. This is because decreases in commodity server pricing have not kept pace with the increase in computing volumes. In addition, leading vendors have worked together to deliver intelligent cost management on the mainframe, enabling workloads to be distributed in a way that keeps mainframe licensing costs (MLCs) down.

    In our view, “biomodal” advocates for the exact problem that must be solved. We think the answer is not replacing the mainframe, although if mainframe development is left unaddressed, this can present obstacles to DevOps. Rather, the answer is to evolve the mainframe to keep up with the pace of DevOps. There are mounting examples from large, high-performing organizations that it is possible to apply modern practices to the fullest extent, including mainframe applications. These organizations do this by giving developers the tools they need to work on mainframe code and data just as they would with any other programming language on any other platform, while meeting the escalating quality expectations of the digital age. For example:

    • Mainstreaming the Mainframe Environment – Mainframe users need to move away from the antiquated “green screen” mainframe environment, adopting state-of-the-art interfaces and tools. This is the first step enabling developers to work more fluidly on the mainframe, in an environment that’s much more familiar and comfortable to them. Organizations that fail in this adoption will have a very difficult time enabling the next generation of development talent to leverage invaluable and irreplaceable mainframe code and data. This will place a huge hindrance on DevOps success.
    • Leveraging Tools from the Java Development World – One example is visualization capabilities, which enable developers to quickly and easily identify critical interrelationships between apps and data. This helps them to sidestep unintended, undesirable impacts as they modify applications, increasing confidence and mitigating unnecessary delays.
    • Make it Easier to Identify Mainframe Code-Level Issues – Developers need tools that enable them to identify problems with mainframe code; for example, when it is the source of a widespread user performance issue, or when it is consuming too many resources and driving up costs unnecessarily.

    Conclusion

    In our view, “bimodal” is not the solution, but a broken state of disadvantaged affairs for too many organizations. From a competitive vantage point, bimodal will only hurt DevOps teams and hold back the innovative efforts of the organizations they support.

    The bimodal IT model is a road to inevitable failure for those enterprises seeking success in the digital economy. This is especially true for organizations that rely on mainframes. A smartly leveraged mainframe is an extremely valuable competitive asset that needs to be removed from its silo, evolved and smoothly integrated into modern, heterogeneous development environments.

    It is possible for big, established companies to adopt DevOps, become agile, and move as fast as startups. But the ability to think and act like a startup requires some major fundamental changes, particularly at the level of software development. The good news is, the legacy technologies that are often perceived as impediments can actually be a tremendous competitive advantage, if they are harnessed and evolved in the right manner.

    About the Author / Christopher O’Malley

    chris-omalley2Christopher O’Malley is CEO of Compuware. He has nearly 30 years of IT experience with past positions including CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit, where he led the successful transformation of that division. Connect with him on LinkedIn and Twitter.

  • Mainstreaming the Mainframe: DevOps, Automation, Unified Deployment

    Mainstreaming the Mainframe: DevOps, Automation, Unified Deployment

    The mainframe is alive and well.  That big metal beast in the data center is not going anywhere anytime soon—nor are its applications.

    “If mainframe applications disappeared tomorrow, planes couldn’t fly, people wouldn’t get paid, and the economy would come to a halt,” wrote Forrester analysts in a recent report, “Digital Transformation Needs Mainframe DevOps.”

    I couldn’t agree more.

    Mainframe systems are the brain of most enterprises. Unfortunately, many mainframe applications have failed to keep pace with technology innovations, forcing enterprises to update them at any cost.

    Those “dinosaur” apps need to be modernized so they can become part of the mainstream IT ecosystem that revolves around the web, the cloud, and everything mobile. To make that leap into the modern software world, mainframe apps need to be re-engineered to fit into what is increasingly a cross-platform, predominantly digital world.

    Digital enterprises need to apply the same continuous delivery management practices to mainframe environments that they use for their distributed, web and cloud platforms.

    Scripting is Not the Solution

    Complex, multi-tier enterprise applications often include back-end mainframe applications and data. Upgrades and enhancements of these applications, therefore, require modifications of application code, data interfaces and other components across multiple platforms simultaneously.

    Scripts are virtually impossible to audit and typically depend on the knowledge of the individuals who write them. Furthermore, scripts lack the end-to-end process visibility and auditability vital to the success of continuous delivery.

    The Need to Re-Engineer Mainframe Apps

    DevOps, which mostly revolves around adopting or improving automation, increasingly is being embraced by enterprises. Having initially chosen DevOps for pilot projects, departmental needs and individual applications, big companies now are taking a broader perspective of DevOps—focusing on their needs to drag their mainframe applications into the modern world.

    Most enterprises that embark on transforming their legacy applications realize it is smarter, easier and more cost-effective to build a bridge with modern engineering than to start from scratch. Typically, these companies deploy DevOps principles because research and analysis prove they accelerate the delivery of top-quality software. At the same time, they realize their existing investments in their mainframe applications cannot be thrown away or ignored.

    Applying DevOps principles to the mainframe application delivery pipeline can help enterprises cut risk, cost and complexity, while improving their responsiveness to ever-changing customer needs.

    Unified deployment means that enterprises might need to work with two or three leading vendors to achieve their vision of automated, cross-platform DevOps. Such a vision typically involves unifying COBOL applications, DB2 databases, z/OS processing power and other mainframe assets into a single, shared pool of enterprise digital resources that IT can adapt wherever and whenever they are required by the business, without operational or staffing impediments.

    The Need for a Unifying Software Delivery Infrastructure

    In enterprises, it is common to have a broad mix of back-end systems, middleware and various platforms from a vast array of vendors. These technologies might be managed by distributed teams and potentially in different parts of the world as well. When it comes to the process of creating and delivering software, the same level of distribution and diversity also is common.

    To connect these islands of technology and expertise, enterprises need a unifying technology that sits on top of everything else, connects to everything, and helps to orchestrate, automate and provide visibility into the process of creating and delivering software. Improving traceability, auditability, security and risk compliance through orchestration and automation of the entire stack of applications is critical to any organization.

    What that means in practice is that people with different skills in different parts of the world can collaborate easily without having to learn new skills. For example, if you know all about the mainframe but know nothing about middleware or distributed systems, that’s no problem. You can still contribute to the process through a unified pipeline.

    In the same vein of thinking, a unifying technology should reduce, if not eliminate, the gap between highly technical and non-technical contributors. That means the unifying technology should provide a solution where people don’t have to write (or even understand) code to make core changes to software.

    In Summary

    Modernizing the way organizations deploy applications to the mainframe is crucial to their success and very survival. Organizations need to embrace change at all levels of their IT infrastructure and begin automating their processes today. By applying DevOps processes and tools to their mainframes, these organizations will help their “dinosaur” applications evolve and survive under the pressures of modern software delivery processes and deadlines.

    About the Author / Sunil Mavadia

    sunil-mavadia_xebialabsSunil Mavadia is director of Customer Success for XebiaLabs, provider of software for continuous delivery and DevOps. A former customer, he was the head of major DevOps transition projects with his previous company. Sunil runs Client Services, including consulting and implementation of the XebiaLabs product suite: XL Release, XL Deploy and XL TestView.

  • Separate but Equal: Not Equal and Not the Right Way

    Separate but Equal: Not Equal and Not the Right Way

    The DevOps Enterprise Summit in London provided another opportunity to speak to many clients about their organizations’ DevOps transformations. The key message is, “It’s all about people and culture,” but how do you make those changes? In session after session it was clear the source code manager (SCM) is central to this transformation. All clients included the SCM as a key part of the solution. SCM’s key value is as a common place to version all the artifacts from the source code to the system configuration. As such, it must provide visibility to all to allow for sharing and collaboration.

    So how can z/OS participate in this transformation if its source code is locked away in some host-based SCM? The answer is, It doesn’t. In my interview with devopsy.kinsta.cloud editor Alan Shimel, we discussed this issue and he related it to the idea of separate but equal, which we all know does not work. What’s worse is separate but equal was really never equal, and the same is true for the host-based SCM to which the z/OS source code is relegated. I have asked many companies if they would move their distributed source to those host-based SCMs, and the answer is always, “Of course not; it does not provide what the distributed teams need.” How can it provide what the host teams need? It doesn’t.

    Separate but equal does not work; it’s never equal and it isolates people. That’s not the way we should be looking at our z/OS source code. It’s critical to the business and should have the best support and capabilities, not the least. Now is the time to move to modern tools and processes and stop isolating the z/OS environment from the rest of the development environment.

    The key is to focus on collaborative management solutions that do not separate, but bring teams together by providing one environment that all teams can use together for cross-platform collaboration. Various solutions include all the capabilities companies need to provide the modern agile development environment including z/OS.  No separation—the z/OS code is in the same repository as all the rest. In these tools, the modern dependency-based build provided for z artifacts is based on Ant technology, so it can be extended just like existing build tools. With this tooling you can use your existing continuous integration pipeline and plug z into it.

    It’s time we move z/OS development into the 21 century.

    Read the thought leadership paper on DevOps for Enterprise System POV to know more on the essential tools and process that can enable disruptive technologies and an innovation at the speed the business requires.

    About the Author / Rosalind Radcliffe

    Rosalind
    Rosalind is a Distinguished Engineer within the IBM Rational organization. She is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi-platform architecture. This includes System z and Power system. In addition, she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions. This includes UrbanCode Deploy and Rational Team Concert’s support for standard Mainframe development activities. She is a member of the IBM Academy of Technology and a Master Inventor. Prior to Rational, she was in Tivoli responsible for the SOA Management Strategy for IBM. Connect with Rosalind on LinkedIn / Twitter.

  • Raising the Bar on DevOps for Enterprise Systems

    Raising the Bar on DevOps for Enterprise Systems

    What do you do when you are a leader in DevOps solutions for Enterprise Systems and you practice what you preach? You raise the bar to continually improve your offerings and share thought leadership about where the future lies for clients as they navigate the world of continuous delivery in a climate of digital disruption.

    The primary reason why most companies adopt DevOps is to reduce cycle times and to improve responsiveness to the market. This is accomplished by breaking down organizational and role-based silos and by allowing people across the end-to-end software lifecycle to work more closely together. While culture is the most tricky part of a DevOps transformation, tools play a major role in enabling information to rapidly flow across people and lifecycle phases, reducing manual and error prone steps, and alerting people of issues as early as possible so they can be addressed. A key feedback loop comes from development in small batches, where frequent compile, build, deploy, and test cycles, allow you to discover issues within hours of the code having been written.

    Over the last month, IBM has made major announcement improving our DevOps for Enterprise Systems solution to help our customers to more easily realize the value of DevOps. Here is a summary of the many announcements we have made.

    • Integrated Suite: We announced the new Enterprise COBOL Suite, which provides one integrated suite of five tools targeting developers and systems programmers. The suite of tools allow you to do performance analysis, analyze abends, code and do unit testing, debug problems and manage complex files and data sets. Click here to see for the next level of details.
    • Frequent build and release: Many customers have concerns that a transformation to DevOps may drive up their MIPS cost with frequent compile, build, deploy, and test cycles. To mitigate this concern, we announced the Enterprise COBOL VU Edition consisting of Enterprise COBOL for z/OS V5.2. This edition allows you to increase your compiles up to a factor of 10x without an increase in your MIPS cost.
    • Integration Platform: In the blog All aboard the z/OS release train – Aqua is coming, my colleagues Kenichi Yoshimura (@kyosh1107) and Joe Winchester (@JoeWinchester) discussed how Explorer for z/OS Aqua has been expanded into an integration platform across the DevOps lifecycle, with initial capabilities for Development (RDz and PD Tools), Operations (CICS Tools), and Runtime (CICS Explorer). The Aqua release improves the user experience for application developer and system programmers, makes installation easier by allowing all of the above rich client tools to be installed using one installer, and makes deployment easier through push-to-client technology.
    • Drinking our own Champagne: We have also built a brand new continuous build, deploy and test infrastructure that is shared across our tools running on our integration platform, Aqua. This allows us to build, deploy and test plug-ins across our integration platform to ensure that they are compatible before we make them available to you. This means higher productivity for our development teams and better quality for our customers.

    The whole intent behind offering a suite of products with continuously improved end-to-end integration is to enable teams to realize the value of their DevOps investments more quickly. While we will continue to bring our “A” game to the Agile software delivery court,  I am interested in what innovations you see coming that would increase IT’s value to the business.

    About The Author

    Per KroPer Kroll is Director of DevOps for Enterprise solution in IBM zSystems Software unit, where he oversees offerings management, development and support. Per also co-leads a DevOps transformation of 2,000 developers within IBM zSystems Software unit. Per has focused on helping organizations improve how they develop software throughout his career. In past positions, Per drove development of the world’s most broadly adopted commercial process library (Rational Unified Process), development of a measurement framework, and lead an open source project centered on agile best practices. Per has also managed development organizations spanning a dozen countries, support, product marketing and product management organizations. Per has authored more than 30 articles and 2 books, sold in more than 30,000 copies and translated to 6 languages.

    Follow Per Kroll on Twitter: @perkroll and LinkedIn: https://www.linkedin.com/in/perkroll

  • Making Over the Mainframe for DevOps

    Making Over the Mainframe for DevOps

    Introduction

    As a discipline, DevOps emphasizes mitigating any and all constraints in order to roll out high-quality, high-performance software, faster. Constraints can be man-made – such as lack of communication between developers and IT operations teams – or technical in nature, such as an overcommitted testing environment. DevOps teams are only as strong as their weakest link. Ironically, the strongest computing platform available in the

    world – the mainframe – can be an Achilles heel in DevOps.

    Since the 1990s, the mainframe has been a target of many jokes, being far less “en vogue” than its modern, distributed architecture counterpart. But the reality is, no computing platform comes close to matching the speed, reliability, security and cost-efficiency of the mainframe. When managed properly, the mainframe can unleash tremendous competitive advantage as the transaction-processing engine at the heart of modern applications. But if it is not properly evolved and left to languish, the mainframe can quickly rear its head as an unwelcome bottleneck.

    This article will explore the current state of the mainframe; why mainframes have the potential to hamper even the most nimble DevOps teams; and how mainframes must continue to modernize in order to keep up with the pace of DevOps and today’s hyper-competitive application delivery landscape.

    Mobile Means The Mainframe Remains Firmly Embedded

    In contrast to many industry prognostications, the mainframe isn’t going anywhere, due to the unparalleled strength of the platform and the billions of lines of code that dictate much of an organization’s business processes. Consider this:

    • IBM’s new z13 mainframe is capable of handling 100 Cyber Mondays every day, 365 days a year.
    • The volume of CICS (mainframe-based) transactions on any given day dwarf the number of Google searches, Twitter tweets, YouTube views and Facebook Likes combined, according to IBM.
    • Mainframes currently process 30 billion business transactions per day, and enable $6 trillion dollars in card payments annually.

    Most organizations find that moving off the mainframe is too risky, too costly and too time-consuming – and with the technology advances in the platform, just plain unnecessary. Numerous instances have shown mainframes to be more cost-efficient than distributed commodity infrastructures, because reductions in commodity server pricing have not kept up with the growth in computing loads spurred by mobile.

    Mobile computing loads are growing at a dizzying pace. Recent research from the global payments industry shows that more than 27 percent of global online transactions are now conducted on mobile devices. And increasingly, these mobile transactions need to pass through mainframes. Consider a mobile banking application, where users snap a picture of a check in order to instigate a series of steps leading to a deposit. Ultimately, this transaction takes place on the mainframe and must connect through it.

    How Mainframes Can Pose a Challenge to DevOps

    Traditionally, mobile/distributed teams work in very different silos from mainframe teams. Each with their own distinct culture. Unfortunately, the characteristics of mainframe systems can cause an overall software development effort to encounter slowdowns, or even come to a screeching halt.

    As one example, consider a mobile developer working on a hybrid application needing test data that resides on a mainframe. Developers and testers must be able to access test data quickly and easily, in order to adhere to compressed go-live schedules. Any challenges to accessing this data – such as not understanding how and what data flows through the program – leads to unnecessary delays. At a micro-level, this negatively impacts the effectiveness of DevOps. But at a higher level, ongoing obstacles like this can quickly snowball, and in an era where “software defines the business,” the organization’s competitive position can be compromised.

    What’s more, mainframe experts (primarily baby boomers) are expected to retire en masse over the coming years. According to industry research, 55 percent of today’s enterprise apps still touch the mainframe, and more than five billion new lines of mainframe code are being added each year to a base already exceeding 230 billion code lines. A sudden loss in the expertise responsible for this intellectual property can expose a company to major risks, or even disasters, and managing it cannot be left to chance.

    Evolving the Mainframe to Keep Up with DevOps

    For organizations looking to distinguish themselves through cutting-edge mobile transactional applications, the mainframe can be a key competitive differentiator. But in order for this to happen, it must be continually nurtured and non-mainframe trained resources must be enabled to support it.

    Over the past year, mainframe ISVs have driven tremendous advances in this area. These ISVs are adopting Agile development processes themselves, in order to help their customers bring the mainframe into the DevOps fold; extend the value of their legacy investments and in the process, become more competitive in today’s fast-moving markets.

    These advances include:

    • Windows-like interfaces and functionalities (for example, copy and paste) on the mainframe: This allows modern developers to work in an environment they’re familiar with, while providing tools that enable them to easily and quickly complete such tasks as dragging and dropping mainframe data from one host to another. Mainframe-specific expertise is no longer required to complete simple tasks.
    • Program and data visualization on the mainframe: These capabilities enable developers – both mainframe and non-mainframe experts – to better understand program and data interdependencies; find and fix mainframe code issues and build the highest quality mainframe code possible.
    • Insights into the performance of code created with the world’s most common programming languages, such as Java: Java developers can truly “write once and run anywhere,” including the mainframe, and ensure the smooth connectivity of applications traversing numerous platform types.
    • Visibility into the often-complex interactions between mainframe programs: This makes it easier and faster for developers to understand, modify and troubleshoot even the oldest, most complex and/or poorly documented mainframe code. Developers can shave days or even weeks off mainframe software updates, while reducing unintended mistakes.

     Conclusion

    When barriers to enabling DevOps on the mainframe are removed, the positives benefits extend beyond creating a more agile DevOps team. Newer generations of developer talent become attracted to mainframe careers, drawn in by the prospect of working on the some of the most exciting, new mobile transactional applications that feed the world’s economy. And with everyone working in a common, visual, intuitive and modern environment, the knowledge transfer between newer developers and more experienced generations of mainframe experts becomes more fluid and seamless, protecting much of a company’s DNA – its mainframe code.

    The mainframe has a very real place in modern application delivery and DevOps. However, mainframe users require support in bringing fast and agile DevOps best practices to bear on their mainframe-resident applications. With new advances, the mainframe can successfully evolve from yesterday’s computer, to an innovation engine suited to modern DevOps teams.3

    About the Author/Chris O’Malley

    Chris OMalley2Chris O’Malley is CEO of Compuware. With nearly 30 years of IT experience, Chris is deeply committed to leading Compuware’s transformation into the “mainframe software partner for the next 50 years.” Chris’s past positions include CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit.

    Follow Chris on Twitter: https://twitter.com/chris_t_omalley and LinkedIn: https://www.linkedin.com/in/christophertomalley

  • DevOps Chat: Rosalind Radcliffe, Mobile to Mainframe DevOps for Dummies

    DevOps Chat: Rosalind Radcliffe, Mobile to Mainframe DevOps for Dummies

    mtmdummies_large

    I recently had a chance to sit down with IBM Distinguished Engineer Rosalind Radcliffe about her new book, Mobile to Mainframe DevOps for Dummies. The book is actually quite a bit deeper than your usual “for Dummies” book and an excellent read. Of course you would expect as much coming from Rosalind who has quite a list of well deserved accomplishments and accolades on her CV.

    Saleem Padani of IBM has a good post up on LinkedIn announcing the book as well that you may want to check out.

    FYI, we will be doing more DevOps Chats in the future. If you would like to be a guest on a future episode please contact editor@devops.com

    Above is an embedded audio player to listen to the interview of Rosalind. Below that is the transcript if you would like to follow along or just skip the audio and read the interview. You can download the free e-book copy now by visiting https://ibm.biz/m2mdevops

     

    Audio Transcript

    Alan: Hi, everyone, this is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud, and we’re kicking off a new feature here at devopsy.kinsta.cloud—DevOps Chats. Each episode will feature me speaking with a thought leader around a particular topic of devops.

    Kicking off our series today with a very special guest, Rosalind Radcliffe of IBM, and we’re gonna be talking to Rosalind about a new book which she has just offered called Mobile to Mainframe: DevOps for Dummies. Rosalind, welcome to devopsy.kinsta.cloud.

    Rosalind: Thank you.

    Alan: Okay, let me briefly give our listeners a little background on Rosalind, and Rosalind, I don’t mean to embarrass you, but you have quite a résumé. Rosalind is a Distinguished Engineer in IBM. She’s Chief Architect for CLM and DevOps, and she is responsible now for driving devops for multi-platform architecture. This includes System z and Power Systems. In addition, she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions, and this includes both UrbanCode Deploy and Rational Team Concert’s support for standard mainframe development activities.

    Beyond that, Rosalind is a member of the IBM Academy of Technology and a master inventor. Prior to her current development related responsibilities, she has been responsible for IBM’s SOA Management Strategy and Services, responsible for deploying Systems Management solutions, and she started with ISPF development.

    Rosalind, I hope I didn’t embarrass you too much, but once again, welcome to devopsy.kinsta.cloud, and congratulations on this great new addition to the DevOps for Dummies series, Mobile to Mainframe DevOps for Dummies.

    Let’s start today’s chat, if you can share with our audience a bit more about you and where you are in your career.

    Rosalind: Thank you, and I’m looking forward to this chat. So, a little history on why I wanted to write the DevOps for Dummies book. I started in IBM 28 years ago in ISPF development, as you mentioned, and I’ve been in different roles and different responsibilities along the way, including spending a good amount of time in the Systems Management organization, responsible for actually doing operations like tasks and deploying our Systems Management solutions for clients.

    I’ve also spent a number of years in the application development space, providing and building application development tools. And so, as this developed over the years, working in operations, I used to blame development, and then when I moved to development, it was, “Oh, I guess I can’t blame operations.” So it’s deemed appropriate that I would move into this devops space of trying to bring these teams together.

    In looking out at the industry today, I see that there are lots of questions, especially in the mainframe space, about, “How does this devops really apply to that environment, and with all the drive for mobile and mainframe together, how do we really make this play as an environment?” And so, that’s how I got here and why I wanted to write this wonderful book.

    Alan: So, let’s dig in quickly to the book. You know, I think everyone in our audience is familiar with the “For Dummies”, if you will, franchise, and some of them can be rather fluffy, some are better than others, obviously, depending on authors and so forth. My initial reaction when I read it, Mobile to Mainframe DevOps for Dummies was, “Wow, that’s a pretty heavy topic for a For Dummies book.” Why write this book in the first place and why now?

    Rosalind: Well, I think now is a perfect time, with the industry evolving, with the mobile frontier and everybody focusing on mobile, and with mainframes truly being our systems of record. So, everybody needs to connect mobile to mainframe, and if we look at the development environment, most mainframe development shops look remarkably like they did when I started 28 years ago, and that’s not necessarily a good thing.

    So what I wanted to do was help explain to executives, senior leaders, and anyone in the industry, how mobile and mainframe play together and, in using the devops transformation helping them work together, they can get more value out of the systems that they currently have.

    Alan: Absolutely. And just so we can mention, of course, Rosalind, the book is available for download, we’ll have links on it up on devopsy.kinsta.cloud. But, as I mentioned, it’s not a fluffy book—there’s a lot of great content here. I can tell how much time and effort you put into this thing.

    But, give our audience a sense—how much, how big an effort was it for you?

    Rosalind: It was a significant amount of time in writing. I spent a lot of time on plane flights back and forth to Europe, and that gives you a lot of time when you can’t do anything else, and so I spent a significant amount of that time writing. It’s a relatively short book, it’s only 70-something pages, so it’s not as long as a very long book, but it did give me the opportunity to hopefully give some background, explain more about the current environment, and give people an insight as to what I’ve been seeing with clients and help them move forward.

    After you write it, then you have to edit it, and I have to thank the many people that helped me work on this and help provide contributions and pieces of the document, because they helped me put this together, and helped me do a lot of editing as well to make sure that it was complete in the environment.

    Alan: Sure. I mean, I’ve been lucky enough to have a chance to see a pre-publication version of it, and I do think—you’re right, it is only 70-some odd pages, but it’s pretty in depth. But it really benefits from the sort of, the For Dummies kind of franchise—you know, the icons they use to help you focus in on what’s really important and giving you Cliffs’ Notes version if you wanted to not read every word. You used the format very well, and I think people will get a lot out of the book.

    Let’s dive in a little bit, though, into some of the key points that you’ve brought up in the book. You know, just picking some random ones that I thought were important—in chapter 3, for instance, you speak about why we need to understand why devops is so critical for mainframe environments. And we need to start with the dev side.

    But devops is about breaking down silos, it is about cross functions—and nowhere, in my mind anyway, nowhere are these silos more separated than between the mainframe teams, like you said, haven’t changed sometimes in 28 years when you started, and the distributor mobile development teams, who are today all about cloud and virtualization and instant up and instant down.

    Can you elaborate a little bit more on this point for our audience?

    Rosalind: Yeah, I’ll be happy to. This is one of the key points as to why devops matters more than ever now in the mainframe space—this transition to mobile, this transition to systems of engagement and their dynamic changes, their need for speed, and the need to access these back end systems of record. So now is the time for us to evolve the environment, the mainframe development environment, to modern technologies and modern tools to allow these teams to actually work together.

    There is absolutely no reason that mainframe environments need to do development the same old way. They don’t need to be done using waterfall development practices. There’s no reason not to apply the same agile and lean IT practices across the development organization from mobile to mainframe, and using the same tools and the same capabilities so these teams can work together, they can share information, they know what each other’s doing, and you can break down those silos.

    One other reason those silos are there is, you know, if your mainframe development team is using ISPF, I’m not sure those mobile guys using X code even want to look at a green screen. So this has to change. The perfect time—bring these teams together, use modern development practices, use modern tools, and this allows the silos to be broken down, allows the teams to work more efficiently together, and helps deal with this variable speed IT issue that we have. Mobile needs to move fast. Those systems of engagement need to be moving.

    But the back end systems of record need to be able to define standard APIs. They need to provide those services that the front end needs, and they need to do it fast enough—so they need to do it at the speed of business, and devops helps them do that.

    Alan: Excellent. And so, Rosalind, you actually touched on something here, and it’s this variable speed IT—variable speed devops, I’ve heard some analysts call it a bimodal  IT—and it, I mean, you nailed it right on the head. These mobile development teams that are running at the speed of today’s business, tearing it up, putting it up, tearing it down, putting it back up—changing, changing, changing thousands of hundreds of times a day, even, in some cases.

    We can’t expect the mainframe systems of record to perhaps move at that pace, but there’s no reason they can’t move faster, especially using modern tools, modern development environments, though I still find something comforting about a green screen. [Laughter]

    But, that being said, you know, this was the subject of a whole series of webinars we did here on devopsy.kinsta.cloud on variable speed IT and variable speed DevOps. Can you help our audience understand why it’s so critical for mainframe environments to embrace devops and why now, more than ever, now is the time?

    Rosalind: Yes, so with this variable speed IT, and as we talk about it, it’s not that the back end is slower because mainframe development is slower, it’s that, in variable speed IT, you need to move at the speed of business, and if you define services as your back end systems of record, those don’t need to move as fast.

    What we need is to define those as services so the front end system can use them, so these systems of engagement can call back into the function. So the need to define these services based on the existing legacy code means development teams need to be able to respond at the speed of business. They need to be able to move faster. And the old ways of doing things—you know, making a change and testing it for three months—just isn’t gonna work. We need to apply the principles of automation, automated testing, virtual services, and interface testing, and bring all of those concepts to allow you to build those services based on the existing business function into the environment so that they can then be called by the systems of engagement.

    Companies have significant assets sitting on the mainframe systems. Mainframes aren’t going away. They’re gonna be here forever. They provide the qualities of service needed for large scale transaction performance systems. And so, with mobile, large scale transaction performance systems—that’s perfect. Mobile backed with mainframe is a perfect environment. And companies with the assets that they’ve built up, if they can service-ify them fast enough, they can provide disruptive technology today.

    And that’s what the companies need to do. They need to take advantage of the assets they have, providing services using the new development practices, and then it all fits together and they get the business value at the speed they need to. And you know, I helped build ISPF, so I do like that green screen, too—but it’s not really the right development platform for developers today.

    Alan: Yeah. But what about—look, you know, people make fun of COBOL developers, but there’s still a lot of jobs out there for COBOL developers.

    What about the shortage of experienced mainframe IT skills in the marketplace, Rosalind?

    Rosalind: Yeah, so that’s one of the points I make in the book. Developers can write any language. You know, get a good developer, they can write COBOL—and there’s nothing wrong with COBOL. COBOL serves its purpose. PL/I serves its purpose. And some people will cringe as I say this—Assembler serves its purpose. But you know, I’m not gonna write it using ISPF.

    If I’m a kid coming out of college and you give me a modern IDE that has all of the language syntax in it, it has code rules, it has the ability to build unit tests for me—I can write COBOL. Not a problem. It’s the—give me an ISPF screen, and I don’t even know how to use it, much less how to do COBOL.

    Alan: Understood, understood. Let me—we’re running low on time, so let me turn to some other questions I had prepared, if it’s okay. In the book, you talked about some of the best practices—devops best practices on System z which, for our listeners who may not be IBM aware, System z is the IBM mainframe platform.

    Rosalind: Correct.

    Alan: And there are several good ones that you have highlighted in the book. Are there specific devops practices that you would recommend for System z to get started down the path of continuous delivery, which some people think is the ultimate aim of devops, or the ultimate goal?

    Rosalind: Yeah, so there are a number of different practices, but a few call out based on the way many mainframe organizations are working today, and it has to do with where they are today. How do they improve the process from where they are to get into more continuous delivery practices?

    And before someone says something, I’m gonna say—continuous delivery does not necessarily imply continuously delivering into production. It means continuous delivery into a pre-production, et cetera, environment. You may still need to stage those based on an outage window, especially for systems of record, because you can’t afford to have a transaction change mid-flight.

    So there are some—you know, continuous delivery within reason. But if we think about those things, one of the key practice is modern development tools to break down the silos. And one of the others that is absolutely critical is automated testing. There is no way to get to continuous delivery without automating testing, and since you’re building services out of your back end systems, services are a perfect thing to use automated testing against.

    So, building up automated testing based on the service interface, being able to test the function without having to have users go in and test the business function—just run a bunch of automated tasks and make sure you’re picking the right automated task based on the code that you’re changing, but automated testing is probably the biggest change that is needed for mainframe environments and, in many ways, the most valuable. We look at many shops and they’re spending months running lots and lots and lots of manual tests that they hope will find the problems.

    Alan: Got it, got it. Rosalind, we only have time for maybe another question or two, but I have one very IBM specific one, one a little bit more general.

    So recently, the new z13 launch really put the mainframe front and center as the core element for IT infrastructure.  Is this the rebirth of the mainframe? How do we see this new mainframe fitting into this seemingly ever changing IT landscape? More importantly, what do existing mainframe clients do to prepare for this new age of mobile to mainframe?

    Rosalind: So, the z13 has lots of additional capability and functions along with the updated compilers to increase the speed to allow you to provide more function faster, COBOL improvements using the new system hardware, Java improvements to be able to do more Java development on the mainframe, as well as significant memory availability changes.

    So, with the combination of the system, you can look at it as the best Linux environment that you can use for your cloud environment, so you can have—use Linux on System z to provide your Linux environment for your front end applications, and then, looking at z/OS, you can start to take advantage of this new memory that’s available to increase and improve your performance from a caching standpoint, numerous other things from a performance standpoint with the new compilers, and the mobile connectivity into the system. If we think about the fact that that could drive huge numbers of transactions—could drive huge numbers of transactions—we get the mainframe as the perfect platform to handle that variable load.

    So you never know—you know, I guess if you’re a retailer you know if it’s Thanksgiving or near Christmas it spikes, but many times, you don’t know where the spike’s gonna come, so it’s important to have that capacity on demand, to have that variability, and so the system plays very well.

    I think there are a lot of clients and a lot of organizations that are taking a new look at the mainframe of the latest z13 because of its capability, because of its enhancements from a memory standpoint, and because they think—you know, reality. People are realizing the mainframe is not going anywhere, and it really is the best platform for those high transaction systems and allows you to consolidate things together in a Linux platform. So it’s a great advantage that customers were already using we they have, and it’s something other customers are looking at to do, “You know, I can take advantage of that as well.”

    Alan: Okay. Rosalind, again—I’m sorry to keep saying this, but I’m trying to keep it short for our listeners, and relevant, but there’s just so much here. So you’re constantly out talking to clients that utilizing mainframes, and kind of living this devops and mobile to mainframe way of doing business—can you give me two or three quick examples of companies that are, that you think are doing it right?

    Rosalind: So, if we look at the industry and we look at the publicly available references, Nationwide is one of them that’s been out talking and describing their devops transformation and how they’re exploiting the fact that they’ve brought their teams together to provide value faster in the environment. We can look at Fidelity, who’s talked about their improved deployment capability and their improvements overall in their environment. Or, one of the examples I like that Walmart and their example of using services on the mainframe to actually provide infrastructure services to all their distributed applications from a caching service.

    And so there are numbers of good examples that talk externally, and then there are a whole bunch more examples who consider their transformation to devops a business advantage. They see that, by transforming to devops, they’re getting a leg up on their competition, and so they’re not as willing to let us use their names—but there are lots of wonderful examples of people who have transitioned and who are getting the value out of it, including IBM itself. We have numbers of examples that we provide to show our development process significantly improving and breaking down the silos within our own organizations and improving our ability to deliver.

    Alan: Excellent. Rosalind, I think this was very helpful, as is the book—a great guide for, as you mentioned earlier, both executive managers and practitioners.

    What about you, Rosalind? You’ve had such a successful and storied career—what’s next? What’s next for Rosalind?

    Rosalind: Yeah, so the next thing next week, actually, I’ll share. So, next week, we have one of the major user conferences or the major user conference happening in Orlando. And, as part of SHARE, obviously, we talk about mainframes and development activity as well as lots of different topics, and I’m looking forward to that in particular, because we’re doing a series on mainframe and mobile. More specifically, we’re doing a discussion about hooking Bluemix, our development app platform as a service along with IBM devops services to the back ends, and helping show the relevance of Bluemix to mainframe environment through a series of sessions as well as showing System z as the new cloud disruptor, and there are numerous sessions by other clients like Walmart who will be speaking.

    And so it’s a great opportunity for me to, first to hear stories from our clients as well as to provide some additional sessions for our clients and show what we’re doing, and it will be my first opportunity to have hard copies of this book and do a book signing for any of the client who are there.

    Alan: That’s what I was gonna say—there’ll be plenty of copies of the book there available and signed by yourself.

    Rosalind: Absolutely.

    Alan: Great. Okay, we’re gonna—I think we’re gonna call it a wrap here, Rosalind, and thank you so much for your time. I know you’re busy and I appreciate it. Rosalind Radcliffe, author of Mobile to Mainframe DevOps for Dummies, available now for download or if you’re attending SHARE in Orlando next week, you can get an autographed copy. Rosalind, thank you so much for your gracious time and spending some time with us today. We hope to—you know, best of luck with the great book, highly recommended, and we hope to have you back here soon.

    Rosalind: Thank you for having me, and I’m happy to come back and talk to your audience whenever is appropriate.

    Alan: Okay. Rosalind Radcliffe, IBM, and author of Mobile to Mainframe DevOps for Dummies. This is Alan Shimel for devopsy.kinsta.cloud, and thank you for listening into this DevOps Chat, and join us again soon for another one. Have a great day.

    That’s a wrap on this DevOps Chat. If you would like to be interviewed for a DevOps Chat please contact me at editor@devops.com

  • Webinar: Canada Mortgage Housing Corporation breaks down IT silos and speeds up mainframe development

    Webinar: Canada Mortgage Housing Corporation breaks down IT silos and speeds up mainframe development

    DevOps encourages adoption of lean and agile development practices irrespective of platforms. However in most organizations mainframe and mobile/web development teams are functioning in siloes, resulting in a plethora of technology platforms and tools, fragmented or manual processes, skills shortage causing unnecessary delays, rework and friction among teams, impacting organizations ability to respond to the business needs.

    Join Jeff Blackadar, Application Development Manager at Canada Mortgage and Housing Corporation, Alan Shimel and IBM experts as they explore the various DevOps strategies, practices and solutions to increase collaboration, streamline processes and leverage modern tooling to attract next generation of mainframe developers to speed mainframe application development and maintenance.

     

    Event recorded Wednesday April 22nd, 2015

    VIDEO

    SLIDES

    [seoslides embed_id=”24772d7de05d” script_src=”https://devopsy.kinsta.cloud/embed-script/variable-speed-devops-ibm-chmc/6919/” overview_src=”https://devopsy.kinsta.cloud/slides/variable-speed-devops-ibm-chmc/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Variable Speed DevOps-IBM-CHMC” /]

     

    Your Host:

    alan_new_head_shot Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.


    About Panelists:

    jeffJeff Blackadar, Application Development Manager, Canada Mortgage and Housing Corporation

    A veteran at application development, Jeff leads a team that programs COBOL, VB.Net, Java and Enterprise Generation Language applications. He is dedicated towards implementing and upgrading of tools and practices to improve productivity and reduce the risks of making changes to mission critical mainframe applications.

    venkjatVenkat Balabhadrapatruni, Senior Technical Staff Member, Chief Architect, Enterprise Modernization, IBM

    Powered by extensive knowledge of z Systems, software design, development, delivery and enterprise modernization, Venkat is responsible for technical architecture and direction of Rational Developer for System z (RDz) and understanding requirements, emerging technologies, market trends and translating them into a technical strategy