SAP Software and Applications are an integral part of some of the world’s largest and complex business processes that run today, enabling millions of transactions effortlessly.
Maintaining and enhancing SAP enterprise applications is considered an expensive effort and sometimes challenging, with known and hidden costs. Hence, a well-designed SAP Change Management is critical to maintaining the quality of the system and preserving the system integrity.
There are three dimensions to calculating the cost of change in software development:
- The effort required to plan, develop, configure, and test the change.
- The process of Change Management (with or without ITSM tooling):
- Creating change requests
- Review and approval for the request
- Change approval board meetings
- Audit
- Change verification and release approvals
- Documentation
- The technical implementation of the change
- Transport Management
- Migrating transports across systems
- Manual configurations after each migration
- Retrofit to the project lines
- Rollback Plan
This article focuses on the cost of Change Management that is involved in the technical implementation of change. (section 3 above)
Technical Implementation of a Change
Below is a quick snapshot of how SAP customers have been implementing the change migration for their applications. (The SAP BTP applications are descoped in this and only the applications built on-premise is covered)
Transport Management Using STMS (Manual)
Creating and importing transports through SAP Transport Management system continues to be an approach used especially by the customers who are running projects in maintenance mode, or who cannot afford the maintenance of Solman for the Change Management.
Challenges:
- Manual approach is not scalable
- Lowest ROI with too many manual repetitive tasks
- Difficult to enforce compliance, quality and audit
Solman and ChaRM
Solman and ChaRM continues to be a key tool for the management of transports used by SAP customers. Large customers have invested into Solman and continue to maintain it as it has been the best available option for years despite its challenges.
Challenges:
- Not designed as a DevOps tool, but more towards change approvals and importing transports.
- Expensive to setup, maintain and upgrade.
- Need dedicated Solman experts in addition to IT teams doing the change management.
- No clarity on road map for Cloud (BTP) applications, as there is no support for GIT or CPI deployments or MTAR artifacts.
- Hard to extend to third-party tools such as Jira, ServiceNow, WorkSoft, HCL OneTest, etc.
In-house Automation
Customers who favor build vs buy, often invest in in-house automation with scripts extending CICD tools such as Jenkins or implementing the Piper Project, etc.
Challenges:
- Hodgepodge scripts
- Difficult to maintain over a period of time
- Scalability and legacy issues
COTS Tools (Commercial Off-The-Shelf)
There are a few tools in the market place that are purpose-built for SAP DevOps and provide out-of-the-box capabilities for Transport Management.
Challenges:
- No road map for DevOps for cloud applications ( BTP / XSA / Integration Suite) etc.
- No rollback capabilities
The Cost of Implementing a Change
It’s a known fact that the cost of implementing a change in SAP is
expensive and customers spend a bomb out of their IT budgets for the Change Management, largely driven by the following factors:
- The installation, setup and configuration effort of the tools
- The infrastructure cost year-on-year
- The need for hiring experts in addition to the Change Managers from IT teams
According to the industry data, for a company with SAP application development team of 20 members, using tools such as Solman has an average of 6,000-10,000 transports imported to production per year.
The cost of implementation of a change comes to about $200–250, with an average spend of $1.5-2M
The total spend by SAP customers on Change Management is a whopping $2 billion every year.
The DevOps Conundrum for SAP Cloud Applications
The entire SAP DevOps initiatives, be it with Solman or the tools around, have all been centered around SAP on-premise applications.
With the rising success of SAP Business Technology Platform, the nuances of modern development methodologies such as version control, CI/CD pipelines, integration with enterprise ALM tools such as Jira / ServiceNow come to the foreground.
This cloud dimension of SAP has given new perspective for DevOps that was not yet envisioned by the current DevOps tooling infrastructure.
The Evolution of ReleaseOwl
ReleaseOwl has evolved as the ONE native DevOps platform for SAP applications that are built on-premise as well as on cloud.
ReleaseOwl is a SAAS application that is based on subscription model and avoids the input costs related to infrastructure, installation, and can be run by your Change Management teams.
Conclusion
With the surge of migrations from SAP on-premise to SAP Business Technology Platform, it is imperative for DevOps tooling to be able to support the application development on both cloud and on-premise.
ReleaseOwl is the only native DevOps platform that offers DevOps workflows and orchestrated deployments for SAP applications built on cloud as well as on-premise.
If you would like to understand more about ReleaseOwl and experience the platform, please write to sales@releaseowl.com
Leave A Comment