TAKE NOTE (Insights and Emerging Technology)
The Navy is 27 months and more than $25 million into the development of a new electronic procurement system and the program is teetering on failure. The service recently decided to “pause” its work with CGI, which the Navy hired in August 2019 under a 10-year, $222.9 million contract to build the system.
An email from Kevin Allen, the Navy’s program manager for Enterprise Systems and Services on June 11, outlined just how problematic the electronic procurement system (ePS) program is after almost two years since the Navy made the contract award.
Allen wrote that problems ranged from vendor performance to implementing an unsatisfactory and inflexible product to significant cost and schedule increases.
For instance, the Navy said “100% of [limited deployment] requirements NOT met — 295 open defects (user acceptance testing (UAT) and IT) as of 6/3 (over 100 critical/high).”
Another issue was user feedback. According to the email:
- Users graded the system’s usability as an “F,” and said it was not an improvement to the system it’s intended to replace.
- Even after users were trained, they still needed “significant support” from CGI
- ePS can’t produce “legally sufficient” contract documents and doesn’t validate data when it’s entered
- 19 of the defects deemed “critical” or “high” would have still been in place when the system went live even after more than 18 months of development, a state of affairs Allen characterized as “unacceptable risk.”
Around cost and schedule, Allen wrote:
- CGI estimates delays the program has already incurred would cause cost increases of $1 million per month; and
- The Navy’s program management office estimates total costs would rise by 350%, and the timeline to deliver the first and second software release would be extended by 84%.
“The ePS program experienced several technical and schedule challenges that led the Navy to pause the current work,” Les Hubbard, the program executive officer for the Program Executive Office for Manpower, Logistics and Business Solutions (PEO MLB), wrote in an email.
“This pause will allow the Department of the Navy to review approaches, to include agile-based development constructs, to best meet the DON contract writing system requirements. Software capabilities consistently evolve and the Navy wants to ensure ePS remains a world-class contract writing system into the future. The pause will allow us to evaluate new developments, sources and capabilities that may improve future performance.”
The Navy isn’t alone with its challenges to develop a new contract writing system….
Interested in learning more about RPA? Download our FREE White Paper on “Embracing the Future of Work”
UNDER DEVELOPMENT (Insights for Developers)
Understanding SAP NetWeaver GateWay
Intro
Through SAP’s history, SAP has provided numerous methods for accessing SAP backend data by external consumer applications. SAP NetWeaver Gateway is their OPEN standards-based framework. SAP changed the name from SAP NetWeaver Gateway to SAP Gateway in the spring of 2014. SAP deleted the “NetWeaver” moniker in a number of products to illustrate these technologies “support platforms and deployments beyond core SAP NetWeaver.”
The SAP Gateway, is an open-standard-based framework. This technology provides a simple solution for businesses to connect their platforms, environments and devices to the SAP software they use. With it, you access your required web services, server functionalities and tools to assist you in a seamless application, data or system integration.
Simply put, SAP Gateway is a technology that provides a simple way to connect devices and applications to SAP software based on market standards (REST and OData). The framework enables development of people-eccentric solutions by exposing SAP business software data to new experiences such as social and collaboration environments, mobile and tablet devices and rich internet applications. It simplifies connectivity to SAP applications by allowing any programming language or model to be used without the need for SAP knowledge by leveraging REST services and OData/ATOM protocols.
Understandably, you might have questions about the SAP Gateway, so lets dig in
What are REST and OData?
You can connect to SAP applications via all programming models and languages using OData protocols and REST services. So let’s start by looking at some key points of these technologies as they relate to their use in this blog.
- REST (Representational State Transfer) is a software architecture style used for distributed systems like the World Wide Web. Owing to its simple style, REST has gradually replaced other design models like WSDL {Web Services Description Language} and SOAP {Simple Object Access Protocol}.
- OData (open data protocol) is a web protocol that allows data queries and updates. With this open protocol, you can query data sources over the HTTP protocol then get results in different formats like plain XML, JSON and Atom. It provides a uniform option for the display, structure, and query of data. Thanks to OData, there no longer is a communication barrier between non-SAP and SAP web developers. There is also no license agreement or cost required for using OData services.
Information exchange on eth SAP Gateway
The SAP Gateway {depicted as SAP NWGW in the below diagram} seamlessly connects your environments, platforms and devices to SAP Enterprise data via OData. The clients who consume the query service in the diagram are depicted as the consumers. The servers exposing OData services via their endpoints are the producers…
– Dig Deeper –
Overview of ABAP RESTful programming Model
Q&A (Post your questions and get the answers you need)
Q. What is SAP RAP and CAP?
A. SAP has introduced various programming models for development over the years. With changing requirements and technologies, these programming models have evolved from DYNPRO and list programming models for SAP GUI based applications to WEB DYNPRO model for web-based applications and thereafter to SAP ABAP programming model for SAP Fiori.
Lets look at each acronym, RAP and CAP, from your question and try to define what they are and how they are used….
The RESTful Application Programming model (RAP) is built on the top of the semantic data model (CDS) and the transactional services are exposed in behavior definition and implementation in implementing behavior class. It also allows adapting the existing applications to be modeled which is intended to be used over a long time. You can start from scratch (greenfield implementation) or you can reuse existing business logic (brownfield implementation). SAP ABAP RAP provides the intrinsic approach to build SAP Fiori based applications that are optimized for S/4 HANA and can run over on-premise as well as on the cloud.
SAP Cloud Application Programming Model (CAP), is a frameworks of tools, languages and libraries (both open source and SAP tools and technologies) designed efficiently with SAP best practices to help developers to minimize coding efforts, develop reusable code in the form of micro services and to focus on designing and implementing business/enterprise specific logic. Obviously this is only a cloud service platform.
To help organize the model differences, please see the table below.
Difference between SAP CAP and SAP RAP
Read more about SAP CAP on its official documentation: https://cap.cloud.sap/docs/
Read more about SAP RAP on its official documentation: https://help.sap.com/viewer/923180ddb98240829d935862025004d6/Cloud/en-US/289477a81eec4d4e84c0302fb6835035.html
Cheers!