- SAP Managed Tags:
Starting with "Why"
First of all, we need to answer the question: why a customer needs to modernise their SAP development practice?
Short answer: business paradigms are changing, enterprise digital platforms are changing, SAP development practices should change to become the leading edge for innovation instead of a lagging factor to only "keep the lights on" in this whole motion.
Background: Setting the Stage for Digital Transformation
Since a decade ago, "the Company" has been closely collaborating with SAP, starting with their first comprehensive ERP initiative. This initial partnership paved the way for further strategic planning, including the roadmap and S/4HANA conversion program from 2021 to 2023. It was during the 2023 S/4HANA program that the Customer Center of Expertise (Customer COE), keen to harness new technologies, consulted with SAP to develop a technology roadmap. This collaboration led to a deep understanding and adoption of Clean Core principles, which subsequently influenced the evolution of their development practices.
Business Needs: Articulating Value
This section highlights the key business benefits identified through our collaborative processes, emphasising the strategic advantages and benefits for the Company's management and stakeholders:
- TCO Reduction and Upgrade Simplicity: Understanding how to maintain a "Clean Core" helps reduce Total Cost of Ownership (TCO), facilitates smoother upgrades, and accelerates the integration of SAP’s innovations.
- Architectural Guidelines: It is critical to distinguish between suitable and unsuitable software architecture concepts and development patterns, especially in cloud environments.
- Empowerment Taskforce through Knowledge: Equipping the Customer COE team with knowledge of SAP's recommended programming models, such as the RESTful Application Programming Model (RAP) and the Cloud Application Programming Model (CAP), empowers them to adopt a cloud-centric programming approach.
Development Principles: Charting the Path Forward
The development principles section delineates the core guidelines our methodology adheres to, ensuring all practices align with SAP's strategic vision:
- Maintenance and Standards: Emphasising easy maintenance and the use of standard software/services.
- Upgrade Stability: Extensions should be designed to be stable through upgrades, reducing the need for frequent adjustments.
- Extension Strategy: Preference for Extensibility Tier-1 extension options to align with the 'Cloud First' strategy, and Tier-3 is only for exceptional cases.
- User Access Management: Ensuring that all user accesses are in accordance with the corporate SAP user profile definitions and controlled by centralised services.
- Familiar Interfaces: Adoption of interfaces such as SAP Work Zone or Mobile Start, which are user friendly to end users, facilitates smoother transitions and user acceptance.
Why SAP Application Extension Methodology was Chosen: Aligning Methodology with Vision
In the quest for a methodology that complements the Clean Core principles, SAP’s Application Extension Methodology (AEM) was chosen because:
- Foundation in SAP Guidelines: Provides a structured framework for sustainable extensions, aligned with SAP’s technology roadmap.
- Cloud Application Design Patterns: Supports common cloud application design pattern with consumption (presentation), business services (application) and data 3 tiers and provides the well-mapped extension technologies.
- Encourages a Shift in Mindset: Urges development and project teams to prioritise extensibility and sustainability from the start, reducing technical debt.
- Incorporated in SAP Activate: With the 2024 Q1 update of the SAP Activate methodology, it now includes AEM, reflecting its strategic integration with SAP’s latest best practices and objectives.
- Further Tip: AEM is one among the three methodologies can be leveraged to support the holistic Clean Core journey.
The Challenges: Navigating the Transition
Transitioning to a new development methodology, especially one as fundamental as AEM, presents several challenges:
- Cultural Shift: The primary challenge is altering the established mindset of SAP development teams — from traditional On-Premises based approaches (local extensions with modifications in the core) to the AEM model (flexible extensions and avoid changing the core). This transition is not instantaneous but a progressive journey aligned with ongoing technological advancements.
- Stakeholder Resistance: With diverse partners and contractors engaged in project deliveries for the Company, there is often resistance due to the learning curve and lead time associated with new methods. Balancing this with the constraints of time and resources within projects requires careful management and ongoing support.
The Steps Taken
An iterative approach was taken to elaborate the artefacts.
- Before diving into the details of AEM model, we zoomed out to review the current state of the design and development process. Instead of labelling different types of "custom development", we extensively used term of "extension" and built in the process of three major categories while the Company starts the "Analysis" process:
- Always Consider Standard: business requirements to go through the fit-to-standard process as a mandatory due diligence for the standard functionalities and business processes. Only the "delta" will go into the next step of designing the extension.
- UX Adoption: Some requirements are potentially relevant to the adoption of the functionalities or UX with extension requirements, in those cases the project may contain user enablement with certain extension tasks.
- Technology Updates: For technical requirements like the replacement of an expiring development kit, the focus should always be leveraging the proper extension patterns instead of a "copy-cat" in a new library.
- Once the analysis process is clear, we were focusing on the accelerators with leveraging AEM's artefacts in the Design phase:
- The extension technology mapping sheet. This is one of the core artefacts which focus on the extension use cases. We updated the AEM template through the exercise targeting on a Red/Amber/Green colour coding for the purpose that the COE and program teams can be on the same page about the technology choices. The rationale being: if a Green extension technology is chosen, then it will go through a "fast-track" through the architectural review board approval process. If it's in Amber or Red, then the program team needs to provide extra justifications on why those technologies are chosen to the review board. It also gives the COE team clear indicators to register the non-preferred extension technology chosen hence the Total Cost of Ownership (TCO) like extra regression tests and bug fixing can be tracked and calculated in the future.
- The most challenging colour was the Amber one, we spent time debating about why one item should be an Amber instead of Red, and for most of them is because we have to face the reality that the legacy wouldn't go away overnight, and the COE team will treat them as "transition options" but gradually switch them obsolete (to "Red") in the future mapping updates.
Technical Extension Mapping
- The development guidelines. The COE team needs to be equipped with guidelines that they can share across with all stakeholders, especially the architect and developers. Because we have had the technology mapping sheet, we kept this guideline light-weighted with a strict "1,2,3,4…" sequence of the technology priority based on the discussion of different real scenarios in the Company. This document provides a technical angle and also an easy-to-consume way by the experienced developers who used to develop the extensions in the widely used "WRICEF" model.
- To further "build the ramp" for experienced developers, we created the ABAP extension design reference guide. It can be regarded as a dictionary to translate the WRICEF model into the new AEM based model.
- Last but not least, based on the new model the specification templates were built and themselves became succinct because the details now can be found in all above references.
- We spent more time on the ABAP (RAP model) considering huge legacy both from the ABAP language itself and in the Company's code base. With CAP model the guideline like the "Golden Path" is available and we've included them as an integral part of the development guideline.
- There was a further aspiration to build an app to automate the full extension design, approval and delivery quality gate processes within an organisation. By the time of this blog, the good news for RISE customers is that with Clean Core practices being integrated into the Activate Methodology, there are out-of-box accelerators available for RISE customers already.
Closing and Way Forward
As a retrospective, the following steps taken for the Company may be referrable practices in the future:
- Alignment on the value. Highlight the opportunities and challenges for applying Clean Core principles and get stakeholder's support. This is easier said than done, I've seen a full spectrum of situations: some customers just take the "Clean Core" as yet another "SAP slogan" while others treat it seriously as they see the change is inevitable.
- See the full picture. The better way to use a system is probably only extend it when necessary. This goes both ways between business and IT: traditionally IT was the "Cost Center" targeting to fulfil business requirements with low cost, nowadays with IT becoming a potential business generator, bilateral conversations should happen, and the million-dollar question should be asked: "how much of the existing business processes can be standardised so as to be digitally agile?" This is why the "fit-to-standard" is put first in the Analysis phase to avoid the "unnecessary" build, before any development process in the Design phase.
- Simplify to be agile. The development artefacts were updated for the design phase with simplifications but also "backward compatibility" with the classic design patterns, we simply cannot dump the legacy: we built the ramp and not burnt the bridge (yet).
Looking forward, because it is crucial for the alignment between the technological advancements and business goals, the SAP development will continue to evolve and demand continuous effort and iterative updates. That's why we always say it is a "Journey", and the journey has just begun.
