Scroll Top

GSA Increases Ceiling for Alliant 2 Contract

TAKE NOTE (Insights and Emerging Technology)

The U.S. General Services Administration is increasing the ceiling of its Alliant 2 contract by $25 billion, bringing the ceiling to $75 billion.

Alliant 2 is GSA’s premier enterprise Government-wide Acquisition Contract (GWAC) which provides customized information technology (IT) services and IT services-based solutions to the federal government. As a best-in-class contract, Alliant 2 provides agencies with access to more than 40 companies offering integrated IT solutions for evolving needs worldwide. Alliant 2 allows for the application of technology to meet business needs, including the ability to stay on the forefront of emerging IT services. More than 100 federal agencies have used Alliant 2.

Alliant 2 has surpassed expectations at every turn. With more than 465 task order awards exceeding $36 billion in estimated value already, it’s clear that this ceiling increase is critical to ensure consistent mission delivery for our customer agencies.

This increase, combined with the team’s efforts on Alliant 3, should signal loud and clear to our customers and industry partners that we are committed to ensuring the Alliant program remains the contract of choice for federal IT well into the future. This also benefits small businesses through additional subcontracting opportunities. Small businesses have already won more than $1.3B on Alliant 2, substantially surpassing small business subcontracting dollars won on the original Alliant contract at this same point in the contract’s life.

In addition to increasing the ceiling on Alliant 2, GSA is hard at work on Alliant 3. Market research is well underway, Alliant 3 has been approved, and the release of the draft Request for Proposals is slated for Q1, FY23.

Read More

Interested in learning more about RPA? Download our FREE White Paper on “Embracing the Future of Work”

UNDER DEVELOPMENT (Insights for Developers)

Demystifying the BTP (SAP Business Technology Platform) – Part 1


Back this month is Jon Andre with another great SAP blog. This time Jon gives an overview on the Business Technology Platform

The transition to cloud-based software solutions in the past decade plus has changed the ERP landscape forever. Many customers have ditched the more expensive on-premise system model for a more cost effective and scalable cloud-based ERP SaaS (Software as a Service) route. During this transition, it has become apparent to many that the old customization model of building large and complex custom application solutions directly on the ERP system needs adjusting as well. Tightly coupling the ERP solution with the custom code that supports it often creates headaches when it comes upgrade time. In an effort to address this issue, SAP began offering a new cloud-based approach to custom application development and deployment, the SAP Business Technology Platform.

Introduction to the BTP

The Business Technology Platform, or BTP for short, is a cloud-based PaaS (Platform as a Service) offered by SAP. The BTP provides application developers with a canvas where they can create applications and extensions to suit their customers customization needs. Best of all, they can do this without having to be concerned with wider impacts to the core ERP system, since their software solutions reside in a completely different system that only connects to SAP via approved APIs. But the BTP is much more than just a cloud-accessible development environment. The suite of available applications and nearly limitless integration scenarios covered allow the BTP to achieve and maintain a bleeding edge position in terms of innovation.

The BTP architecture is decoupled and open; customers are no longer forced to remain committed to an antiquated solution because of fear of overall system impacts. Solutions can instead now be swapped out on the fly, allowing customers to always have the latest and greatest custom solutions, even solutions prebuilt by third parties. This also applies to integration solutions, so system vendors can provide both the system and the prebuilt BTP integration solution at once. This approach allows third-party systems to be added to the enterprise’s ecosystem along with an integration solution that has been tested and is already fully supported by the third-party vendor themselves. Without having to worry about costly integration projects or ripping and out and replacing custom code, businesses can take a “plug-and-play” approach to which systems and applications they want to use. This creates an environment similar to the “composable ERP” that Tony mentioned previously in Composable ERP: What It Is and Why It’s Important.

What are the Components of the BTP?

SAP BTP Landscape

The BTP, with its many service offerings, enables developers to make cutting edge applications that are easy to configure and integrate with existing ERP solutions. The BTP can be broken into two separate service categories: the Extension Suite and the Integration Suite.

With Integration Suite, the BTP has access to many prepackaged integration solutions out of the box, for both SAP Developers can use these prepacked solutions to quickly jump-start development on a foundation that has been designed and tested by SAP themselves, or by trusted third-party vendors. For Integration Solutions that require a bit more customization, users can either extend prepackaged integrations or create new ones entirely from scratch using a graphical based design tool and a variety of open APIs.

The Extension suite, as the name implies, is the set of tools primarily used to extend core ERP functionality. However, the Extension suite is capable of much more than just that; the Extension Suite provides the tools necessary to create full-featured, end-to-end and modern applications. To serve as the basis for all applications, the Extension Suite comes with its own database and data management tools, including its own SAP HANA Cloud and data lake options. The Extension Suite also provides modern data analysis tools to produce business value from data, with products like the SAP Data Intelligence Cloud and SAP Analytics Cloud.

Many of the tools in the BTP can be used as-is without the need of anything beyond initial configuration. The best solutions, however, incorporate custom logic to suit the business needs while taking advantage of the suite of tools available. The Extensions Suite comes with multiple runtime environments that provide flexibility when choosing this custom coding solutions. This allows developers to use a variety of software languages, including SAP’s proprietary language ABAP but also including languages like Java and JavaScript. Finally, to bring this all together, SAP provides several low-code to no code options to expose these custom solutions, both internally to the company and externally to vendors and consumers. With just a few clicks, applications built in the Extension Suite can be exposed via OData or Fiori apps, with all of the most technical and tedious development tasks, such as designing the application or creating the service, automatically generated by SAP. Next, we’ll have a deeper dive into some of these services to see how these offerings are organized.

Lets take a closer look at the Integration Suite…

Read More

– Dig Deeper –
What is the SAP BTP?

Q&A (Post your questions and get the answers you need)

Q. I learned a term “ABAP strict” for first time in autumn 2021 during an openSAP course called Introduction to ABAP in the Cloud. So what is “ABAP strict” sometimes called as “ABAP strict mode”?

A. The ABAP strict is ABAP programming language version that uses only a subset of the Classic ABAP’s syntax. So, now if we think about ABAP in this context, there are now actually two versions of ABAP.

The first version is ABAP classic. It is the one that we all (hardcore SAP stack programmers) know from on-premise SAP solutions world like R/3, ERP, ECC including SAP S/4HANA on-premise as well.

Another version is ABAP strict. It is the one used in cloud based SAP solutions like SAP S/4HANA Cloud, ABAP environment as well in SAP Business Technology Platform (BTP) ABAP environment.

What are the differences between the two ABAP versions?

As both the versions are used in different environments (on-premise vs cloud), it naturally drives the language’s feature sets.

In case of ABAP strict access to repository objects is given only by released APIs. This means you cannot directly manipulate e.g. database tables with CRUD SQL statement. Instead there a whitelist of allowed APIs to do that. Allowed APIs are checked statically at compile time, as well as runtime.
Moreover, only ABAP Development Tools (ADT), based on Eclipse IDE platform, can be used as development tool. Remember it is about the cloud – SAP GUI is no more the ABAP developer IDE.

In addition, ABAP language keyword set is restricted if compared to ABAP classic. There are many ABAP commands that are obsolete in the cloud environment. E.g. access to SAP server OS, screen manipulation (no GUI, FIORI is the UI), no SQL for data in database tables manipulation, no more WRITE command, dynamic connections, client overrides, relative keywords are not supported, secondary database connection is not allowed etc… just to name a few. Naturally, there are a stricter syntax rules and checks applied to all elements, including ABAP classes and SQL statements.

Hope this helps…


Pin It on Pinterest

Share This

If you enjoyed this post, why not share it with your friends!