devopsy.kinsta.cloud

Tag: SAP

  • Bringing DevOps to SAP, With Basis Technologies

    Bringing DevOps to SAP, With Basis Technologies

    DevOps has not only reached mainframe groups in enterprise but also to large applications such as SAP. Organizations are moving away from waterfall methods and mega releases that take many months to deliver. What’s needed are many more rapid release cycles and deployments that support the accelerating pace necessary to do business.

    In this conversation on TechStrong TV, David Lees, CTO of Basis Technologies, joins MediaOps CEO Alan Shimel to explore how organizations implement DevOps into their SAP integration and deployment cycles. Having lived through this transition, David shares his unique perspectives on the necessity to break through bottlenecks and make changes in supply chains, finance and many other business processes needed to support the business.

    The audio file of our conversation is below, followed by the transcript. Enjoy!

    Transcript

    Alan Shimel: Hey, everyone. Thanks for joining us on another segment here for TechStrong TV. In this segment, we are joined by David Lees. David is the CTO at Basis Technologies. David, welcome to TechStrong TV.

    David Lees: Thanks, Alan. Great to be here.

    Shimel: Great to have you here. So, David, I don’t think we’ve done an interview here with Basis Technologies before, so I think we should start right there.

    Lees: Okay. So –

    Shimel: Go ahead.

    Lees: Basis is a company that’s been around for about 20 years. We are a global organization that works with hundreds of customers around the world, and the thing that they all have in common is that they run SAP software, as I’m sure many of your audience do.

    Shimel: Yep.

    Lees: We specialize in solutions around the application life cycle management space. We kind of started up the whole trend in terms of the DevOps for SAP by really helping people to manage their change in a much more Agile way than SAP is traditionally known for.

    Shimel: Excellent. And of course, you know, David we were talking off-camera before we got started, I’m doing devopsy.kinsta.cloud seven years, right? And when I first started everyone said, “Oh, DevOps is something for startups; I don’t know about large organizations.” And then sure enough every large – not every, but most large organizations in the world started recognizing the benefits of doing things in a DevOps fashion, and we fought this battle with DevOps in the mainframe, DevOps on things like SAP. How could something like SAP benefit from DevOps?

    But of course they can, of course they can, and I think SAP themselves has recognized it and they’ve come out with a lot of DevOps-related solutions, products, services, but also companies like Basis are recognizing that, hey, my customers are asking me about DevOps but they’re not going to throw away tens of millions of dollars and years and years of tribal knowledge that they’ve developed in doing things on SAP. It’s just impractical. And so, you know, they have to put a little chocolate in the peanut butter and it’s got to work together, right? I would imagine, you know, Basis has – this is a real specialty that the market’s calling for and Basis has a real role to fulfill here.

    Lees: Yeah. I think it’s as relevant in the SAP world as it is elsewhere for exactly the same reasons; customers are looking to become more Agile, they want to be able to deploy in kind of just in time, moving away from the whole annual or six-monthly mega release delivered in a very waterfall way in order to respond to market changes, customer needs, in order to drive more efficiency within their application development and application management space and to deliver that with quality that a business-critical system like SAP mandates, to be honest.

    Shimel: Sure. So David, I always like to ask our guests a little bit about their own personal background because people out here are wondering, right? So they look at David Lees, the CTO of Basis Technologies, they’ve been around 20 years in the SAP space, they deal a lot. David, what’s your personal background like?

    Lees: So I actually joined Basis only about 18 months ago, and prior to that I spent the majority of my career on the other side of the fence. I was with Proctor & Gamble, a large global consumer goods company, and pretty much most of that time was connected to SAP in some shape or form from implementations through support, upgrades, getting ready for transformation to things like S/4HANA, and it was in that role as a customer that I first came across Basis a few years ago and actually brought in one of their products into Proctor & Gamble. So I kind of first had that experience as a customer of Basis before deciding to kind of make the step in to working here as CTO.

    Shimel: Excellent. So you literally have a career in SAP that you bring to Basis, and as you said, from the other side of the fence; not as a vendor but as a user, a consumer, a customer of SAP.

    Lees: And like you were saying before, I think many of the customers of SAP that have been running with SAP software for now 10 if not 20-plus years have developed the knowledge, they’ve developed their solutions and their processes exactly how they like them, but that’s come with massive investment, massive investment in custom code, custom solutions, investment in the way they’re managing those developments, those projects and maintaining them on a going basis, and so I lived through firsthand this whole lifecycle, let’s say, plus the last few years where the old way of managing things was simply not going to be the right way to continue to manage in the future because at the end of the day, while the rest of the architecture around SAP is evolving at a much faster rate you can’t kind of retain the bottleneck image that SAP has and you have to find a way of breaking that bottleneck and being able to move at a similar pace to the other elements in the architecture. It’s not as easy as saying, okay, well let’s just not touch the back end and keep that totally frozen. It’s simply not possible. You need to make as many changes in your supply chain and finance and legal entity structure, et cetera, as you do in your ecommerce platform.

    Shimel: Fair enough. Excellent. Again, the parallels to what we saw in the mainframe space is also – but I think there’s something else you gotta remember. People don’t use SAP just because of their prior investment or just because it’s what they’ve done before, right? Organizations of a certain size use SAP because it offers real advantages and allows you to do things in such a way that you can’t have or you can’t get with just about any other solution out there. So it’s not just because this is what my grandpa did or this is what we’ve done for 10 years, 20 years; it’s because we are an organization of a certain scale that we require this.

    Lees: Yeah. I think they’re a market leader for a reason.

    Shimel: A reason, right.

    Lees: They have the products that, like you say, run some of the largest enterprises in the world; many of the Fortune 500 or FTSE 100 or what have you. And it’s in spite of that that we need to find a way of being able to manage that in a much more modern way. There’s certain elements of SAP that I’m sure some of your kind of more pure DevOps listeners or audience would struggle to understand in terms of, for example, the way version management is handled in SAP inside like a single database, hard to manage branches in terms of parallel developments, the way changes are deployed through the use of things like transports, create to some extent an ecosystem in SAP that is different than a lot of the cloud native and more modern applications, but at the same time we want to be able to help customers to manage the risk, to manage the agility, and to be able to move things through with confidence and with speed in keeping their changes across their architecture orchestrated in a controlled way.

    Shimel: Absolutely. So David, if you don’t mind, I think we’ve laid the groundwork here well, let’s look at, if you will, the anatomy of an SAP-DevOps engagement, right? We spoke about maybe it’s an existing SAP customer who – right? – doing that big yearly release or twice-a-year release is not going to cut it anymore. They need to be more agile – nimble agile, not necessarily Agile software development, though that too, but they need to be more nimble, they need to be more responsive, they need to – they want to utilize a modern CI/CD pipeline type of delivery system.

    Lees: Yeah. I think as with anything here you’ve got the three normal components. It’s about the people, the process, and the tools. So there’s no kind of silver bullet that’s going to say, yeah, I’m suddenly DevOps in my SAP space. You need to have similar best practices around automating as much as possible within that pipeline, and some of that’s available natively inside SAP to do things like automated unit testing, automated code inspection, but the piece of the jigsaw, let’s say, where we come in is to create effectively the pipeline portion for SAP using one of our products called ActiveControl, and that’s about being able to deploy in an automated way within the landscape to the point where the customer is comfortable and being able to kind of highlight and manage all of the interdependencies or identify where it is safe or isn’t safe to move changes in a more accelerated way.

    So I think some of the best practices I would say are common across the SAP and the cloud native world, and when it comes down to some of the tooling you need to start looking at SAP-specific tooling where it’s not possible to leverage some of the kind of off-the-shelf open source best practice tools like best-of-breed ones such as Jenkins or Git, but equally this is where we can integrate and we can help a customer in managing their SAP side of their estate, their architecture, in a coordinated or orchestrated way with the non-SAP world that they’re managing using some of these more traditional DevOps-based pipeline tools or CI/CD tools.

    Shimel: Yep. Agreed. So David, when Basis comes in – let’s talk about the engagement now, right? Is it more of like a classic consulting where we come in with bodies or is it more of an architectural and here’s the processes and kind of maybe software we’re going to introduce or both?

    Lees: Yeah. So we are primarily a software company in terms of providing the solutions, although we do recognize and we do work with some of our customers that they also need help on what are the process changes or architectural changes that they should make in order to go further, in order to become more Agile, what are some of the, again, best practices that they should be doing without switching on or without investing in? They won’t be able to go as far as they want to or need to. So whilst we are today primarily a software company and we will come in to help our customers activate those solutions and deploy them, we are starting to kind of branch out a little bit more into the consulting side to help customers on that journey, to define what that journey looks like for them based on where they are today and based on where they want to get to.

    Shimel: Fair enough. So I’ve got to kind of ask it only because you have to in these days – how’s COVID affected all of this?

    Lees: I think we’re affected to some extent like many companies; however, we are to a certain extent well insulated. We have a subscription-based model, so the companies that tend to deploy our solutions continue with those solutions. We have an incredibly high renewal rate which we’re very proud of, and that gives us a very strong cashflow and a very strong platform in which we can continue to invest in new products and solutions as well as to continue to invest in identifying and adding new customers. I think to some extent there is – some of the pursuits, some of our prospects have been impacted by budget restrictions, but I think at the same time COVID is accelerating significantly the pace at which companies realize they need to transform. So I think it’s probably as much as one side kind of slowdown and budget restrictions as it is kind of companies coming in saying we have to modernize, we have to change the way we’re doing things and we need our SAP application development to be as flexible as we have elsewhere in our organization.

    Shimel: Agreed. And, you know, I kind of suspected that but I wanted to kind of confirm it with you, is yeah, you know, on the one hand it definitely – everyone working remote and everything that went on you could see it slowing down, but on the other hand it becomes very much a catalyst for transformation, right? There’s no waiting for tomorrow; we’ve got to do this now, and so it happens in there. What about working remote though, David? I mean you’re obviously in your home office right now.

    Lees: I am and I [laughs] was always set up in a home office kind of gig here at Basis, so I’m based in Spain whereas the headquarters is in London. So even pre-COVID I was kind of used to working a few weeks from home and then going into the office for a week or so every month. Now it’s just all at home for the foreseeable future. We’ve had to adapt. Development teams that used to be very – used to kind of working together, whiteboards and daily standups and that sort of thing have found ways of doing that remotely like everyone else has had to do, and yeah, I think we’re all getting used to a very interesting new world, and I would be very surprised if we go back to exactly how it was previously.

    Shimel: I don’t disagree with you. But the good news is, you know what, you’re still able to do your work, stuff gets done, and it could be worse, as they say. Hey, we’re about out of time but I wanted to mention one other subject. You guys are doing a webinar here on devopsy.kinsta.cloud. It’s probably about a month from now, maybe even a little more than a month from now. It’s on SAP and DevOps.

    Lees: Yeah.

    Shimel: I’m not going to put you on the spot here and spill the whole beans, but who should be – you know, talk to us about it.

    Lees: I think the intended audience for that is people who are traditionally on the DevOps side of the fence who’ve grown up outside of SAP who need to or are realizing that SAP should become part of what they’re including in their plans and in their strategies. Now I would still say SAP kind of long-timers would get some value out of that webinar, but it’s more about helping people understand how SAP is relevant, why it’s relevant, and how we can help customers bringing the SAP world together with the more modern side of the application house for customers, and so I think it’s primarily tailored towards that audience.

    Shimel: Cool. More information on this will be available on devopsy.kinsta.cloud under our webinar section. David, I look forward to that webinar. I want to thank you for joining us on TechStrong TV today. Where in Spain are you based, by the way?

    Lees: Near Málaga on the South Coast, so a nice little town.

    Shimel: Oh, it’s terrible, terrible, terrible.

    Lees: Like yourself in Florida.

    Shimel: Yeah, I was gonna say, in Boca Raton I really can’t complain either. But anyway, hey, thanks for joining us, look forward to the webinar in October, and keep up the great work.

    Lees: Great. Well, thanks a lot, Alan. I look forward to coming back on, talking to you again in the future.

    Shimel: Absolutely. David Lees, Basis Technologies, SAP and DevOps. It’s real. It’s something you need to be thinking about, especially if your organization is already an SAP shop. This is Alan Shimel. We’ll be right back with our next guest here on TechStrong TV.

  • SAP Embeds Integration Services in PaaS Environment

    SAP Embeds Integration Services in PaaS Environment

    SAP, at its SAP Tech-Ed Europe 2018 conference, expanded the scope of the integration services it provides within SAP Cloud Platform, the platform-as-a-service (PaaS) environment it provides for building custom applications based on the open source Cloud Foundry project.

    Dan Lahl, global vice president of product marketing for SAP Cloud Platform, said SAP is now adding a Content Advisor service that makes use of machine learning algorithms and other forms of artificial intelligence (AI) to recommend what integrations should be created next based on those that have been previously deployed on the platform.

    In addition, SAP announced the general availability of SAP Cloud Integration Automation Service, which provides deeper integration with a standard set of metadata SAP is in the process of defining for all its packaged application software, and SAP Cloud Platform Open Connectors, a set of application programming interfaces (APIs) based on code SAP has licensed from Cloud Elements.

    SAP also revealed that it will start making an on-premises edition of SAP Cloud Platform available via partners including IBM and Atos beginning in 2019. Lahl said that decision was driven by customers that for either regulatory or intellectual property concerns did not want to deploy custom code on any cloud service. Those efforts become more feasible once SAP finishes porting its distribution of Cloud Foundry to run on top of Kubernetes, which presents a more efficient approach to deploying an application development platform using a cloud-native platform that can run anywhere. While SAP remains committed to Cloud Foundry, the cost and effort of standing up instances of a Cloud Foundry PaaS in its original form are considerable.

    Finally, a new SAP Business Partner service on SAP Cloud Platform, planned for general availability in November, will provide access to a set of master data services that simplify access to and orchestration of enterprise business applications. The master data services can be shared and reused for any LOB-specific intelligent business processes to ensures a consistent and comprehensive view of customers, sales and products. In effect, SAP is now providing compliance as a service, said Lahl.

    The integration additions to the SAP Cloud Platform should improve performance and help drive down costs, he said, because  collectively they eliminate the need to rely on an external integration service when building and deploying applications on SAP Cloud Platform.

    SAP has put considerable effort into building out SAP Cloud Platform as part of a strategy that provides a layer of isolation between SAP applications running on the HANA database and custom applications running on Cloud Foundry. That approach enables SAP to deliver a quarterly cadence of updates to both its packaged applications and HANA running on a cloud service without having to worry about the impact those updates might have on custom applications. One of the reasons why so many SAP customers are several releases behind on SAP packaged applications is because they have all been customized extensively in on-premises IT environments.

    As part of that effort, SAP is now also making available a series of best practices for implementing DevOps processes across its platforms. It may be a while before organizations that have standardized on SAP platforms master those processes. But modernization of those platforms is now more a matter of when rather than if.

    — Mike Vizard

  • Magic xpi Integration Platform Achieves SAP-Certified Integration with SAP S/4HANA®- Empowers customers

    Magic’s integration solution empowers customers to automate and optimize processes through interoperability with SAP® solutions

    Laguna Hills, CA, October 9th, 2018 – Magic Software Enterprises Ltd. (NASDAQ and TASE: MGIC), a global provider of end-to-end integration and low-code application development platforms and IT consulting services, announced today that its Magic xpi Integration Platform 4 has achieved SAP-certified integration with SAP S/4HANA, enabling Magic’s customers to optimize business processes through automation across leading ERP, CRM, finance, and other enterprise systems using a single platform.

    The SAP Integration and Certification Center (SAP ICC) has certified that Magic xpi Integration Platform 4 integrates with SAP S/4HANA to connect with any system or data source, and can expose SAP data on the web or via mobile devices.

    “SAP certifications for Magic xpi is part of our continuous commitment to provide vendor approved connectors to speed up time to market for software, while ensuring ease of maintenance and upgrades,” commented Yuval Lavi, VP of Technology & Innovation at Magic Software. “With today’s focus on digital transformation and continuous innovation, certified integrations are an important building block for ensuring a free flow of information throughout the enterprise for optimizing end-to-end business processes.”

    As a result of the certified integration, Magic Software customers can be confident that Magic xpi has been proven to smoothly integrate with SAP solutions. Magic Software provides a fast and effective way to automate and optimize business processes involving SAP solutions and other applications, systems or data sources. For example, Magic xpi provides the ability to integrate ERP, CRM and eCommerce systems for supporting business growth and creating differentiating customer experiences. In addition, Magic xpi is used to integrate ERP and MES systems for improved inventory management and quicker agility when responding to fast changing customer requirements.

    About Magic Software Enterprises
    Magic Software Enterprises is a global provider of powerful and versatile end-to-end, on-premises and cloud-based integration and low-code application development platforms.

    With over 30 years of experience, 24 regional offices, millions of installations worldwide, and strategic alliances with global IT leaders, Magic enables its customers to seamlessly adopt new technologies and maximize business opportunities. Magic collaborates closely with its customers and thousands of business partners in 50 countries to accelerate their business performance.

    SAP, SAP NetWeaver, SAP S/4HANA and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. See http://www.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices. All other product and service names mentioned are the trademarks of their respective companies.

  • EDAT for ERP Increases Velocity, Ensures Quality

    EDAT for ERP Increases Velocity, Ensures Quality

    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:

    • Enabled a complex SAP landscape
    • Enabled self-service by bundling needed dependent objects
    • Provides adherence to the orchestration of change and release management steps
    • Full audit traceability
    • Auto rollback capability
    • Architected with full DevOps CI/CD

     

    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.

    Workflow Automation

    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.

    Validation series include both standard and custom validations prior to allowing three methods of deployment

    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:

    • Rule logic based on system and objects.
    • SOD/SOX compliance checks.
    • Prevention of backdoor addition of unapproved transports.
    • Change Manager SAP pipe ownership.
    • Release date and the approval date to ensure change management process is adhered.
    • Target release systems availability check.
    • Lockout, for upgrades and support packs.

    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:

    • Agile planning.
    • Auto rollback.
    • Pipeline architecture.
    • Test automation.
    • Live undo.

    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

  • AppDynamics Taps into SAP Applications

    AppDynamics Taps into SAP Applications

    Application performance management (APM) is starting to be  employed more widely as more organizations embrace digital business transformation. As the number of digital business processes spanning multiple applications increases, so does the need to understand what’s occurring inside both greenfield and legacy applications. In fact, at the heart of many of those digital business processes are enterprise resource planning (ERP) and customer relationship management (CRM) applications from SAP. To make it possible to gain insights into those applications AppDynamics, a unit of Cisco Systems, announced today it is making available AppDynamics for SAP.

    Jonah Kowall, vice president of market development and insights at AppDynamics, said his company is now able to support ABAP, the proprietary language SAP developed to build its applications. That language also has been employed extensively by IT organizations to customize those applications.

    SAP currently is trying to transition its customers to building custom applications on a cloud framework based on the Cloud Foundry platform-as-a-service (PaaS) environment. Most of those applications are be written in Java or the new Jakarta platform that replaces Java. SAP has also provided a software development kit and application programming interfaces (APIs) for tapping into S/4 HANA ERP applications.

    But there is a massive installed based of ABAP applications running in enterprise IT environments. Much of that code is now being integrated with other applications as part of a larger digital business transformation initiative.

    Kowall said those extensions are now driving organizations to apply an agent for the AppDynamics APM to custom applications written in ABAP. Historically, enterprise IT organizations only applied APM to their most critical applications. But as organizations move to digitize business processes, they now need to able to track transactions spanning multiple applications. Given the reliance many organizations have on SAP applications, it’s inevitable those transactions will involve SAP applications that were customized using ABAP.

    In addition, Kowall noted that being able to discover precisely where those custom applications are involved in any transaction is pivotal when it comes to upgrading to the SAP S/4 HANA applications, which are based on the SAP in-memory database, or lifting and shifting a legacy SAP application into the cloud.

    Kowall said organizations that have used ABAP to customize SAP applications now will have visibility down to the code level, including queries being made to the underlying database. From a DevOps perspective, that capability will go a long way to breaking down yet another silo in the enterprise. AppDynamics expects the first order of business for many organizations will be simply to create a performance baseline for their ABAP applications, which in many cases are likely to be an eye-opening experience, he said.

    The focus on digital business transformation is likely to spur adoption of DevOps processes over a much broader swath of the enterprise. Rather than simply apply DevOps processes to new applications, many organizations soon will extend DevOps into the realm of legacy application environments as well. That may take some time to play out, given the scope of the cultural changes involved. But at this point, those changes are now all but inevitable.

    — Mike Vizard

  • SAP Cloud Price Changes Reflect DevOps Realities

    SAP Cloud Price Changes Reflect DevOps Realities

    To foster more application development in the DevOps era, SAP at the Mobile World Congress 2018 conference announced it is adding a consumption-based pricing option to its SAP Cloud Platform environment.

    Based mainly on the Cloud Foundry platform-as-a-service (PaaS) overseen by the Cloud Foundry Foundation, the SAP Cloud Platform provides a way for SAP customers to build custom applications that can be more easily integrated with SAP applications delivered as a cloud service using a standard set of application programming interfaces (APIs). The basic idea is to enable organizations to innovate in a way that doesn’t impact their applications every time SAP, for example, updates the SAP S/4 HANA application portfolio, said Dan Lahl, vice president of product marketing at SAP.

    SAP Cloud Platform currently is made available via a set of services an organization subscribes to for a defined amount of time. Under the consumption approach, an organization buys credits that can be applied within a specific amount of time. That makes it more economical for organizations to start multiple custom projects without having to know precisely upfront what services will be employed on the SAP Cloud Platform, Lahl said.

    In effect, SAP is creating a licensing model more in keeping with how developers consume services in the age of DevOps, he noted.

    SAP also announced an enhanced SAP Cloud Platform SDK for iOS, providing tighter integration with the Apple Xcode integrated development environment (IDE) and additional analytics controls that can be embedded within an iOS application. SAP has also made it easier to consume SAP Leonardo services for building internet of things (IoT) applications using APIs that can be accessed via the SAP API Business Hub.

    Lahl said in the coming months SAP also will share with customers best DevOps practices it follows to develop and maintain cloud applications. SAP is now seeing traditional IT organizations now starting to more aggressively adopt DevOps processes, he said, primarily because DevOps processes enable IT organizations to show a proof-of-concept (PoC) to line of business executives much faster. That, in turn, also serves to condense the feedback loop between business units and the internal IT team.

    Those projects now span multiple classes of runtimes, including SAP ABAP, Java and Docker containers—all three of which are being employed to create microservices. The challenge many organizations now face is determining when to build a microservice versus invoking a function via an API that already exists in an ERP application. Application developers don’t often have visibility into an existing function, which is why they run into resistance from business executives whenever they attempt to reinvent a wheel that already exists, Lahl said. The challengeis making it easier to discover the APIs that expose functions within an existing monolithic application, especially when it doesn’t make sense to reconstruct a general ledger function as a microservice.

    Whatever the ultimate approach employed, the one thing that is clear is that costs associated with either building or consuming a service keep coming down in the age of DevOps.

    — Mike Vizard

  • SAP Adds SDK to ERP Cloud Service

    SAP Adds SDK to ERP Cloud Service

    When most IT organizations think about DevOps it’s usually within the context of custom application development. But thanks to the rise of application programming interfaces (APIs), packaged applications are now becoming a much bigger factor. SAP, for example, just made available a software development kit (SDK) for SAP S/4HANA Cloud, an instance of its ERP software hosted in the cloud.

    Christian Pedersen, chief product officer for SAP S/4HANA Cloud, says the company is encouraging developers to integrate SAP and custom applications. The company is unable to address every potential use case on its own, he says, and it doesn’t make much sense for developers to reinvent functionality that already is an API in a SAP packaged application. The goal should be to deliver a unified application experience made up of packaged and custom components that all are accessed via a common user interface experience.

    That approach, he says, will be critical as SAP continues to invest in advanced machine learning algorithms and digital assistants. Rather than having to develop those technologies themselves, Pedersen says it’s going to be a lot more practical for many developers to leverage capabilities that SAP will expose via APIs.

    SAP’s approach to custom applications is unique in that it makes available a separate SAP Cloud service based on the platform-as-a-service (PaaS) environment developed by the Cloud Foundry Foundation and the Kubernetes cluster platform now overseen by the Cloud Native Computing Foundation (CNCF). The best part about the SDK, says Pedersen, is that it includes sample code that developers can reuse in their applications. As far as DevOps is concerned, SAP is not driving any specific approach, preferring to work with a variety of continuous integration and continuous delivery (CI/CD) platforms.

    Some developers have historically viewed SAP and other providers of packaged applications warily. There is a tendency for vendors that sell packaged applications to continually expand the footprint of their software. SAP isn’t promising not to expand the footprint of its applications further, but, Pederson says, when it comes to crafting a unified application experience aimed at specific use cases, the developer community is essential.

    The biggest challenge associated with combining PaaS environments with software-as-a-service (SaaS) applications is getting the updates to the respective environments synchronized. DevOps teams don’t have any control over when a SaaS application provider chooses to roll out new capabilities. In many cases, the pace at which the SaaS application provider delivers those updates often sets the pace for the whole DevOps teams. In some cases, IT organizations will prefer to run applications on-premises just to exercise more control over the upgrade cycle.

    Whatever the approach, there’s clearly greater need for more DevOps sophistication now that packaged applications have essentially become back-end services that are invoked as a service via an API. The first order of business toward achieving that goal, however, may be informing the owners of those applications they are now part of a much larger ecosystem that needs to be considered every time anyone wants to update a module or add a new service.

    — Mike Vizard

  • Tailoring DevOps to your IT: A case study for SAP

    Tailoring DevOps to your IT: A case study for SAP

    I am frequently asked if DevOps principles can be applied to legacy environments such as SAP. They clearly can, with some tailoring. But you should be aware of certain constraints.

    An agile transformation from conventional IT (where the SAP software delivery process is split between business analysts, development, the QA department and IT operations) towards an agile DevOps organization requires the following steps:

    1. Organize development teams by business capabilities rather than technology – when defining the structure, ensure teams can work as autonomous and independent as possible.
    2. Upskill business analysts to product owners.
    3. Organize development output by agile principles using SCRUM or KANBAN.
    4. Successively move QA into development teams – a separate QA team can take responsibility for automation of regression, security and performance tests, but should not be involved into day-to-day testing activities.
    5. Successively augment development teams with job scheduling know-how.
    6. Introduce automation tools to ease the promotion (transport) process for changes into upper environments and, ultimately, production.
    7. Add unit test and static code analysis (e.g. for security and performance checks).
    8. Automate regression, security and performance tests.
    9. Focus responsibilities of the SAP platform team on managing the platform (monitoring, patching, upgrading, environment provisioning and refresh, performance testing) and leave the transport of changes (“deployments”) to development teams.
    10. Use automation tools for environment clone and refresh.
    11. Move the SAP platform team towards KANBAN.

    While these steps are similar to agile DevOps transformations in other technology contexts, the specific automation tool chain is very different.

    Instead of using Git, Jenkins, Ansible or Chef, you are dealing with tools from SAP and third-party vendors for code inspection and analysis, transport management, test automation, environment refresh, performance testing and more. This requires skills that can be hard to find. In addition, different tools may be used to cover different SAP platforms (the “ABAP-Stack” and the “Java-Stack”).

    There is another peculiarity for SAP: Although new technology supports fast cloning of isolated SAP environments and their continuous refresh with current data, this is constrained to certain infrastructure. The costs and lead times to provision and manage a single SAP environment remain relatively high.

    Therefore, several teams will often have to share a single SAP environment for development, testing or release purposes. This requires coordination and sets limits to continuous delivery. In the best case, daily production deployments can be achieved by opening the pre-production environment for transport and application tests over a couple of hours, then locking it for another couple of hours for regression, performance and security testing (including batch) and production delivery.

    In summary, many principles of DevOps can be applied to SAP application delivery, if peculiarities are taken into account.

    While continuous deployment for SAP environments remains an ambition, daily releases can be achieved today.

    DevOps Dozen Awards! Automic is currently nominated for a DevOps Dozen Award in the Release Management and Continuous Delivery categories. Vote for us today!