Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Birmingham looks like the Detroit of the UK—is it Oracle’s fault?
Plus: Was Toyota’s factory failure caused by running out of disk space? (more…)
In this post-pandemic world, large enterprises are looking to streamline and improve business processes within a storm of marketplace constraints. Companies in asset-heavy industries such as oil and gas, energy, retail, or distribution and logistics have especially been working to reconfigure their supply chain processes to better manage inventory and operations. The focus in the market has shifted from supply chain optimization to supply chain resiliency, creating efficiencies that will help them best survive current delays and rising costs.Â
The question is not simply whether companies need to modernize their business applications to increase efficiency and lower costs, but how to accomplish a necessary modernization in the midst of barriers like rising costs, supply chain disruptions and a severe shortage of developer talent. Developers and DevOps teams need to find ways to do more with less.
The reimagining of business processes is an excellent strategy to reduce overhead and allow companies to become nimbler and more efficient, consequently helping them preserve or improve marketshare. Many large enterprises work in environments that use enterprise resource planning (ERP) software; systems that, over the years, have been subject to ongoing upgrades, patches and redesigns by developers and IT managers. This creates technical debt, which makes it difficult for many of these large-scale companies to migrate their business applications to cloud-based systems.
Many of these ERP-based companies are facing pressure to update to more modern, cloud-based versions of their ERP platforms. But they must run a gauntlet to modernize their legacy applications. In a sense, companies that maintain these complex ERP-based systems find the environments are like “golden handcuffs.” They have become so complicated over time that they restrain IT departments’ innovation efforts, hindering their ability to create supply chain resiliency when it is most needed.
To make matters more difficult, the current market is facing a global shortage of human resources required to get the job of digital transformation and application modernization done, including skilled ERP developers—especially those skilled in more antiquated languages like ABAP. Incoming developer talent is often trained in more contemporary languages like Java, Steampunk and Python. These graduates have their pick of opportunities and gravitate to companies that already work in these newer programming environments.Â
ERP migrations can be hampered by complex, customized systems developed by high-priced, silo-skilled programmers. Many enterprise leaders have a great desire to break out of these restrictions and modernize legacy applications with greater speed and at lower cost, and they need to do so with minimal downtime and disruption.Â
In a 2022 report on application development strategies, industry analyst Deepa Salem interviewed enterprise companies that used sophisticated SAP-based ERP solutions about their approach to software modernization strategies. More than 80% of respondents said they planned to upgrade their business applications in conjunction with a major migration of their ERP software platform to the latest, cloud-based version.Â
This tactic of implementing a new applications strategy in coordination with a major refresh is not surprising and presents an opportunity for developers to help these companies “clean house,” reducing the technical debt of their legacy environments at this well-timed juncture. Â
As an analogy, think about how people typically move to a new residence. Homeowners sift through their accumulated possessions and identify what’s no longer needed. They pack what is still valuable and essential. A low-code application process can help clean up existing ERP environments prior to migration, reducing complexity and long-accumulated technical debt while leveraging the system’s unique business intelligence. The tribal knowledge inherent in any legacy system is critical to retaining market differentiation.Â
With so much at stake, IT departments and developers should give serious consideration to using pre-built, customizable business applications, efficiently and rapidly created through a low-code development process. Deployment-ready solutions can help developers move forward with modernization projects that have been hampered or shelved due to a lack of talent to implement those jobs. They can accomplish more with less.
With the right approach, ERP-based environments can be reconfigured to quickly establish more agile, streamlined and cost-effective business applications. Developers have a unique opportunity to help enterprises keep what sets them apart from the competition and surrender what no longer serves them. In this climate, this is not a nicety for enterprise customers. It’s about resilience—and even survival.
At an online SAP TechEd conference this week, SAP announced it has added additional low-code/no-code tools to the SAP Business Technology Platform (BTP) to enable both professional and citizen developers to build applications that invoke application services provided via the company’s cloud platform.
The effort to increase the number of custom applications invoking those services revolves around a no-code development and automation platform dubbed SAP AppGyver, launched this week, and an existing set of low-code tools dubbed SAP Business Application Studio that the company also enhanced. SAP Process Automation, a robotic process automation (RPA) platform for automating workflows, is also being previewed.
JG Chirapurath, chief marketing and solutions officer for SAP BTP, said the goal is to make it easier for organizations to build applications faster using tools that provide higher layers of abstraction through which they can invoke, for example, backend RPA and AI services via an application programming interface (API). SAP makes it possible to achieve that goal via an SAP BTP platform it provides to IT teams. The BTP platform allows teams to build applications that can be integrated with SAP application services running on a public cloud or managed by SAP on behalf of the customer. In either case, the goal is to make it possible for developers to spend more time building business logic versus building and maintaining integrations, he said.
As part of the effort, new capabilities were also added to the SAP Conversational AI service and the company has promised to launch a personalized recommendation service based on a neural network.
At the same time, the company also revealed it has updated the SAP Integration Suite for SAP BTP to provide access to additional prepacked integrations that are available on the SAP API Business Hub.
In addition, the company said by the end of this year it plans to make the SAP Integration Suite available on the Google Cloud Platform alongside support it provides for other public clouds.
Finally, a revamped training site, dubbed SAP Learning, will make it simpler for developers to advance their skills.
The challenge SAP application developers are trying to navigate is determining which business processes are best served using packaged cloud applications versus ones that require actual customer code. The number of processes packaged in a suite of enterprise resource planning (ERP) applications has greatly expanded over time. With each successive update, ERP platform providers such as SAP identify new processes that could be beneficial to the bulk of their customers. For example, the processes that organizations use to track invoices and issue payments are all pretty much the same. It doesn’t make a lot of sense to write a custom application to manage a set of tasks that are already well-defined within a packaged application.
Custom application development is typically where organizations have an opportunity to differentiate themselves. After all, if every organization is relying on the same core processes provided by a packaged application vendor, there is no real difference from one organization to the next. Custom applications, on the other hand, built using no-code or low-code tools or procedural code written by developers, should either be used to extend a workflow in some way an application doesn’t or should be used to create an application that provides a sustainable competitive advantage. That challenge—and the opportunity—is first identifying those processes and then finding the simplest way to build and maintain the applications that drive them.
IT organizations today are faced with the challenge of delivering new capabilities at higher velocity to enable digital transformation. While enterprise resource planning (ERP) systems provide a stable integrated foundation and emerging capabilities to meet business needs, their integration and deployment processes were built for a waterfall methodology.
As business agility is paramount to market success, Intel IT works to move to an agile and DevOps methodology to deliver new capabilities at high velocity while maintaining stability at optimal cost. This program built additional capabilities on top of SAP Solution Manager to enable self-service, continuous integration (CI) and continuous delivery (CD). The velocity of self-service has improved by 341 percent while decreasing deployment costs by 45 percent, with no change induced incidents. The quality of integration and deployments was improved, while the complexity of the integrated environment increased. The maturity level for DevOps adoption has been improved and 97 percent of our agile teams have L3 agile maturity with plans to reach L4 within a year.
The features designed to support DevOps included:
The Agile and DevOps Program Transformation team did an industry scan and conducted detailed vendor evaluations to meet these needs. Most of those tools available introduce redundant change management functions currently provided by SAP Solution Manager. Due to the lack of feature-rich tools to meet the demands of the DevOps culture, Intel created the Enterprise Deployment Automation Tool (EDAT). EDAT solves the problem by providing self-service continuous delivery capabilities to development teams and enabling high velocity while leveraging SAP Solution Manager.
EDAT is a custom-built ABAP Web Dynpro program that integrates Solution Manager with self-service capabilities with workflow automation. The design was reviewed and approved by our internal audit, security, SOX, change management, enterprise and platform review teams. To meet these requirements, strong authentication and tight controls were needed to perform directed steps while restricting access. EDAT automation performs validations of code, approvals and other checks at increased speeds and improved quality.
One feature that makes EDAT unique is the ability to support step releases. Step releases allow transports across multiple changes and systems to deploy simultaneously while providing the ability to pause and resume later. It enables the ability to resume by showing the list of changes in the release and displays the progress completed, which easily allows for co-shared deployment across multiple regions and resources.
The picture above depicts the workflow automation implemented in EDAT. Once a user story is created and work is assigned to an iteration, development begins. Unit testing begins in development. Once tasks are released, automated testing is completed in each environment. Before the change can proceed to the next environment, the testing must result in a pass. If there is a failure, the developer is notified so a fix can be created which results in a repeat test until it passes. An automated backup of objects is completed prior to landing to the next environment, so they could be brought back to the previous state should user testing and validation show issues. An automated workflow is orchestrated within each action and code movement, validating and advancing Solution Manager, the service management ticketing system, agile planning tools and automated testing tools. Automated synchronization keeps the environments in sync.
Three methods of deployment are included; One-By-One, Set-Order, and Import-All. One-by-one best suits releases that require many manual steps between transports. Set-order allows for proper sequencing and was designed to allow imports to sequence in serial, while pausing on any landing error. This is often used in releases benefiting from a faster release with on-error stops. Import-all allows transports to land all at once, which best suits releases where the transports do not share objects.
Both standard and custom validations are enabled within EDAT. A structure was set up that allowed for standard validations, which include the various SOX and audit requirements common across all release types. Another structure was set up that allowed for custom validations, which include architecture-specific setup, rule logic and configuration requirements. This dual structure introduced the ability to deploy changes across SAP pipes from within a single screen and deployment rule logic.
EDAT enforces these validations:
Release sequencing is a critical requirement for releases to maintain high quality and ensure a successful release, and is one of the top five reasons why additional resources were needed prior to EDAT. Allowing development teams to order transports and enable the system to import in this order alleviated resource constraints and helped achieve the self-service release capability necessary to increase velocity and improve quality at the same time.
Self-service ability to re-land transports is a key feature that is necessary. Some releases require re-landing a transport to ensure all objects are activated. The only caveat to this feature is to maintain a date check for production landing, to comply with change management.
Landing return codes are shown to the user automatically and full logs are also accessible to the development teams.
Plugin integration enables the ability to allow and support integration across various tools and provide these capabilities:
These capabilities allow EDAT to integrate with other technologies and other platforms through an open API.
EDAT automatically detects objects and platforms which require specific rule logic. Once detected, a summary is displayed to the user so there is an awareness of what will be completed prior to execution. In an upcoming iteration, predictive detection will validate inactive objects in target environments. This will detect issues in advance and initiate fixes automatically.
A single interface with integration across all platforms allows for increased quality, tool reduction and reduced confusion, and provides clear results. This benefit can be seen across multiple service groups and teams. With standard ERP release functionality, users had to use several tools and instances to complete releases. EDAT enabled synchronized and bundled releases from a single tool, where all platforms would import, whether SAP, ABAP or another platform. The ability to implement releases across all platforms is enabling our vision of integrated release across all platforms.
In an upcoming iteration, full test automation will be enabled, where tests will run and are automated. When these automated tests return with a pass, then EDAT will allow them to proceed to the next environment. When the automated tests return with a fail, then EDAT will not allow the code to proceed to the next environment. The development teams will be notified of the failure so a new set of tests can be run after needed fixes. These test results are updated in the SAP Solution Manager change screen for easy retrieval.
One key highlight, there were no change-related incidents and the cadence of releases significantly increased with continuous deployment compared to time-based sweeps. Self-service migrations from Q1 to Q3 2017 increased 341 percent over the same period in 2016.
EDAT made it possible to decrease migration management resources by nearly 45 percent. Migration and release managers are now able to move to higher-value activities. User feedback has been overwhelmingly positive. SAP has since performed a review of the tool and process and acknowledged the change control process has become very agile. The excitement and value realized are positioning the program to continue with improvements and advancing its DevOps’ capabilities.
This article was co-authored by Ramani Subramanian and Jeff Clancy
— Richard Dowdy
The Next Evolution of Software Delivery Automation
In the 1980’s and 90’s, the business software landscape was dominated by a diverse list of cutting-edge companies such as Best Software, i2, Brock Control Systems, Mapics, Ross Systems, Infinium, FBO Systems, Manugistics and MSA (of course I could go on and on). Now long gone, these and hundreds more really great companies have been gobbled up or rendered obsolete by the rising class of ERP giants. In this article I’ll explain why history will repeat itself leading to the extinction of most DevOps tools as leading ADLM platforms continue to assert their dominance across the diverse software development and delivery automation ecosystem.
History Informs Our Future and The Evolution of ERP
You already know that for the past twenty years, most companies have leveraged some form of ERP system to manage virtually every core business processes. One benefit of this tightly integrated solution is a powerful inter-functional data flow that enables corporate agility and provides the highest level of visibility. This super-integrated architectural model has become the standard adopted by virtually every enterprise around the globe. What you may not know is today’s “ERP model” is the result of four distinct evolutionary generations that I believe help predict the next major evolution of automated software delivery.
Phase 1 – Automation
Enterprise Information Systems (EIS) – In the 1960’s, early automation systems were developed to support important individual business functions such as general ledger, inventory management, billing, payroll, etc. These systems were architected completely independently of each other and added little value to the enterprise beyond their narrow scope.
Phase 2 – Core Data Model
Manufacturing Resource Planning (MRP) – Then in the 1970’s, the idea of a master production schedule was devised so that a few of these isolated systems could gain greater visibility into future inventory and product requirements of the organization. The big idea behind the master production schedule was the creation of an open data model that could be leveraged by other systems impacted by the manufacturing production schedule.
Phase 3 – Expansion
Manufacturing Resource Planning II (MRP II) – In the 1980’s, software vendors began to build and sell off-the-shelf packages that promised “best of breed” process design. These solutions provided tightly integrated versions of the key manufacturing processes required to produce products.
Phase 4 – Business Process Domination
Enterprise Resource Planning (ERP) – Finally, in the 1990’s, business software vendors expanded well beyond the manufacturing scope by creating highly-integrated solutions that now cover just about every standard business function imaginable. These systems leverage a unified data model to dramatically improve visibility, consistency, accuracy and planning capabilities enterprise-wide.
What Does ERP Have To Do With Automated Software Delivery?
The evolution of ERP has taught us how natural pressures forced the creation of a unified and comprehensive “business data model” spanning the entire enterprise. Those software vendors with enough influence to dictate that data model were the ultimate winners in the ERP space.
In the very first generation of ERP (EIS), software was leveraged to deliver a high degree of automation to many business processes that were previously manual. Over time, it became clear that these newly automated processes were interconnected and the evolution towards a tightly integrated and unified data model was underway. The business objective that fueled each successive generation outlined above was the need to design more efficient business processes that increased organizational visibility and agility.
As Marc Andreessen famously said in 2011, “…more and more major businesses and industries are being run on software and delivered as online services—from movies to agriculture to national defense.” (Why Software Is Eating The World). That statement resonates even stronger four years later. Today, virtually every corporate organization is seeing the familiar pressure to deliver software more efficiently and reliably. If history is indeed our guide, any highly fragmented and/or isolated process required to deliver incremental software change will face mounting pressure to be merged into an integrated end-to-end enterprise-grade platform that can deliver improved cross-functional visibility with even greater efficiency.
Why Application Delivery Lifecycle Management Will Win
In my view, there are really only two broad solution categories in the realm of automated software design and delivery – Application Development Lifecycle Management (ADLM) and the catch-all term DevOps (which I’ve hijacked here to describe any other type of process automation that assists the software delivery process).
DevOps tools are often narrow point solutions that have sprouted from open source projects, in-house development or commercial vendors. Organizations rely heavily upon a diverse collection of these DevOps tools to help document, validate and automate a steady flow of software change along its path to end-users.
Here’s the problem DevOps tools are beginning to face: Like the EIS systems of the 60’s, fragmented DevOps tools have little or no visibility into the overall end-to-end process; however, they do generate lots of important data that is often locked away and isolated. This isolation creates a clear barrier to efficiency, visibility and agility across the software delivery process. Because of the limited function each individual DevOps tool performs, none have the gravitational pull required to define the larger data model. As comprehensive enterprise software delivery platforms emerge elsewhere, standard DevOps tools will face ever-increasing pressure to fold inside them.
Currently, Application Development Lifecycle Management solutions provide a platform to manage development projects, team resources and all manner of development activities. ADLM platforms also contain the “master production schedule” for every development initiative – past, present and future. The data contained within ADLM is now at the core of a quickly emerging software delivery data model and leading ADLM vendors are expanding their footprint pwell beyond traditional use cases. When it comes to ownership of this software delivery data model, I see no other solution category across the entire ecosystem with enough enterprise clout to pose a serious challenge to leading ADLM vendors.
Unified Software Delivery Platforms Are Already Emerging
Each of the five current ADLM leaders (according to Gartner’s most recent Magic Quadrant) are now racing to bring to market an enterprise software delivery platform that integrates many key DevOps capabilities.
Here’s my two cents on each…
The Giants in the space – IBM and Microsoft both have plenty of muscle and IP today. Clearly both are moving down the path toward a comprehensive software delivery platform. IBM acquired DevOps vender urban{code} several years ago and is hard at work building their developerWorks platform. Seemingly everyday, Microsoft is adding some kind of DevOps capability into its Visual Studio product suite. Still, I don’t see either vendor gaining much traction outside of their traditional (albeit very large) customer base. Perhaps more importantly, neither seem to have bonafide credentials within the super-influential agile development community and I believe this kind of street-cred (at least for now) is a must-have to dominate this space.
Atlassian does enjoy wide support among the agile community and no doubt has the broadest adoption footprint of any of the current ADLM leaders. Atlassian is in a strong position to mount a serious threat. However, Atlassian’s core product (JIRA), is widely believed to lack heavy-weight depth in the ADLM feature spectrum and it is often implemented as a departmental or “team tool”. They’ll have to develop deeper strategic planning and multi-team project capabilities to beat the rivals.
This May, software giant Computer Associates announced a definitive agreement to purchase ADLM heavyweight Rally and its agile development platform. In its announcement, CA said it intends to leverage Rally’s capabilities to “complement and expand CA’s strengths in the areas of DevOps and cloud management”. With the crucial addition of Rally, CA is now in a strong position to assemble its diverse capabilities into a single unified and enterprise-caliber software delivery platform. Now… can they seamlessly integrate all of the pieces-parts into a cohesive solution with a unified data model? If so, how long will it take?
Finally, I believe VersionOne may have a slight edge over the other ADLM vendors in the race toward a unified software delivery platform. I may be a bit biased because of my direct involvement in a joint project currently underway – none the less, here are four reasons why they will absolutely be a dominant force to recon with:
Vision: Robert Holler, VersionOne CEO, is clearly buying into the “enterprise software delivery platform” vision. He and his team have a well thought out strategy and they are actively executing against that strategy.
DevOps Automation: VersionOne has partnered with ClearCode Labs and both teams have been hard at work integrating ClearCode’s Continuous Delivery Automation framework into the VersionOne core product. This integration provides VersionOne the ability to orchestrate virtually any DevOps tool or platform and (just as importantly) incorporate all related data across VersionOne’s product suite to fee its quickly expanding data model.
JIRA Integration: VersionOne has just announced a tight integration into the JIRA platform. This integration will give them the ability to fold fragmented JIRA installations across the enterprise into the unified VersionOne platform providing a more strategic and enterprise-grade solution.
Availability: VersionOne’s automated delivery platform is available now and they are demonstrating their comprehensive solution to the eager agile community this week at the sold-out Agile2015 conference in Washington, DC.
Summary
The top 5 ADLM vendors are already well on their way toward developing enterprise-grade software delivery platforms that will consume many of the current “DevOps” automation solutions. Soon, development organizations will benefit from a comprehensive platform that can deliver increased efficiency, visibility and agility when compared to the heterogeneous solutions that have been cobbled together today.
About the Author/Dennis Ehle
Dennis Ehle, is a pioneer and thought leader in continuous delivery automation and agile delivery methodologies. Â Dennis is passionate about helping agile teams dramatically reduce the transaction cost associated with delivering incremental change. His company, ClearCode Labs, does just that by helping organizations continuously deliver high-quality software releases more frequently merging proven methodologies with empowering tools and technology. Twitter:Â @DennisEhle