TAKE NOTE (Insights and Emerging Technology)
More companies have gone to the U.S. Court of Federal Claims with complaints over how the $50 billion IT vehicle is being managed.
The $50 billion CIO-SP4 contract has drawn more protesters at the U.S. Court of Federal Claims as four more companies have joined the fray this week.
Eight companies in total have now filed lawsuits and their cases are likely to be consolidated into one. While three different law firms are involved, all of the cases have been assigned to the same judge.
The attorney for the most recent two protesters to file has asked that they be consolidated because their lawsuits all deal with the CIO-SP4 vehicle coming out of the National Institutes of Health’s IT Acquisition and Assessment Center.
The eight protesters are:
- Analytica
- Futron
- HagerV3
- Inalab Consulting
- Mission 1st Group
- Objective Function Systems
- RCHP
- VetsConnect
All of the complaints are currently sealed. It could be several weeks before public versions of the filings are released.
Interested in learning more about RPA? Download our FREE White Paper on “Embracing the Future of Work”
UNDER DEVELOPMENT (Insights for Developers)
ABAP Custom Code Migration – An Overview
Intro
The journey from traditional ABAP custom code to a more contemporary digital landscape through SAP S/4HANA or the SAP Business Technology Platform (BTP) ABAP Environment represents a significant evolution for any organization intent on keeping pace with the rapidly changing business environment.
As SAP customer’s undertake this transformation, they must embark on a meticulous and multi-phased process. Initially, it requires a thorough delineation of the custom code elements that are essential for migration—a step that demands a deep understanding of the operational value and usage of the existing codebase.
Subsequently, a comprehensive analysis is critical to determine how well the current custom code fits with the new functionalities and architectural paradigms of the SAP S/4HANA or SAP BTP ABAP Environment.
After establishing what will be migrated and ensuring its compatibility, the actual migration phase commences, which involves moving code to the new environment—a procedure that is often fraught with technical challenges and requires careful planning and execution. The final, yet equally vital, stage encompasses the adaptation of the migrated code. This adaptation is not merely a technical necessity but an opportunity to refine and optimize code to leverage the advanced capabilities of SAP’s modern platforms.
This blog will be a high level overview of the process and phases. For a more detailed explanation, please see our blog post MIGRATING CUSTOM ABAP CODE TO SAP S/4HANA.
Understanding the Migration Landscape
Prior to migration, it is imperative to understand the contours of the landscape where this transformative process will unfold. For countless organizations employing SAP systems, custom code has been developed and refined over years or even decades to fit precise business needs, creating a tapestry of bespoke functionality that is tightly woven into the fabric of their daily operations. This custom code ecosystem, often sprawling into millions of lines, forms the digital backbone of an organization’s unique operational workflow, ensuring that nuanced business processes are catered to with precision.
Such a vast repository of custom-developed code, however, presents a considerable challenge when organizations want to upgrade their systems to the more advanced SAP S/4HANA, or when strategizing a migration to the cloud-native capabilities of the SAP BTP ABAP Environment. The shift to these newer platforms is not merely a technical upgrade but a substantial overhaul that necessitates a strategic and well-orchestrated migration plan. This intricacy arises from the fundamental differences in the underlying architecture of these modern systems compared to their predecessors, as well as the different operational paradigms they introduce.
Moreover, this transition is complicated by the fact that existing custom code is often deeply integrated with legacy systems and may rely on outdated technologies or database structures that are incompatible with the new SAP environments. The intricacy of these systems means that any migration effort must go beyond a simple ‘lift-and-shift’ approach. It requires an understanding of both the legacy and target environments to ensure that the custom code not only functions as expected, but also capitalizes on the performance and efficiency improvements that SAP S/4HANA and SAP BTP ABAP Environment offer.
– Dig Deeper –
Getting Started with Custom code migration to SAP S/4HANA
Q&A (Post your questions and get the answers you need)
Q. How can we implement a data mesh in SAP?
A. Implementing a data mesh architecture in an SAP environment involves integrating the principles of data mesh—a decentralized approach to data architecture and organizational design—with the specific technical and business processes of SAP systems.
Data mesh focuses on treating data as a product, with domain-oriented decentralization of data ownership and architecture, while ensuring interoperability, discoverability, and secure access to data across the organization.
While I’m still learning myself, here’s how I might approach this:
Understand Data Mesh Principles
- Domain-oriented Decentralization: Organize data ownership and architecture around specific business domains, enabling domain teams to act as data product owners.
- Data as a Product: Treat data with the same rigor and care as software products, focusing on the needs of data consumers.
- Self-serve Data Infrastructure: Provide a platform that enables domain teams to easily publish, discover, and consume data products without central bottleneck.
- Governance and Standardization: Implement federated computational governance to ensure data quality, security, and compliance across all data products.
- Foster a Data Culture: Encourage collaboration and knowledge sharing across domain teams to build a data-informed culture. Organize training and workshops to elevate the data literacy of domain teams and data consumers.
Once you understand the principles, we can look at implementing steps to get there…
Step#1 – Identify Business Domains in SAP
- Analyze your SAP environment to identify distinct business domains (e.g., finance, sales, procurement, manufacturing).
- For each domain, identify key data entities and processes that are crucial for domain-specific operations.
Step#2 – Decentralize Data Ownership
- Assign data product ownership within each domain, ensuring teams have the skills and resources to manage their data products.
- Empower domain teams with the autonomy to manage, share, and improve their data products while adhering to overall governance policies.
Step#3 – Implement a Self-Serve Data Platform
- Utilize SAP tools (like SAP Data Intelligence) or integrate third-party solutions that align with data mesh principles to create a self-serve data infrastructure.
- Ensure the platform supports data discovery, access control, data quality management, and interoperability between different SAP and non-SAP systems.
Step#4 – Establish Interoperability Standards
- Define and implement standards for data formats, APIs, and protocols to ensure seamless data exchange and integration across domains.
- Leverage SAP’s integration capabilities and APIs to facilitate data sharing and access across different SAP modules and external systems.
Step#5 – Implement Federated Governance
- Develop a federated governance model that balances domain-specific autonomy with enterprise-wide policies on data security, quality, and compliance.
- Use SAP’s governance, risk, and compliance (GRC) capabilities to enforce policies and monitor compliance across data products.
Step#6 – Monitor and Optimize
- Continuously monitor the performance and usage of data products to gather feedback and make improvements.
- Leverage analytics and reporting features within SAP and external tools to assess the effectiveness of the data mesh implementation.
Step#7 – Integration Tools and Technologies
- SAP Data Intelligence: For data integration, processing, and governance.
- SAP Business Technology Platform (BTP): Offers cloud platform services for integrating and extending SAP applications.
- APIs and Event Streams: Use SAP’s API Management and event-driven architectures for real-time data sharing and processing.
Implementing a data mesh in an SAP environment is an iterative process that requires collaboration between business domains, IT, and data teams. It’s essential to align the implementation with the organization’s strategic objectives and scale the approach as the organization evolves.
Cheers!