Interface Development Lifecycle

This article is about application/enterprise integration, not user interfaces. It explains the typical steps from the requirement/change to a phase post go-live.

Interfaces are not static and might show a unexpected behavior at production runtime. Thats why the interface design/development is not a one-way street!

1. Change: A change can be initiated by a new project (e.g. the usage of an application like SalesForce or Workday), a new law (e.g. Chinas PIPL – Personal Information Protection Law) or any other event which leads to a new integration between applications (internally-A2A or externally-B2B/B2G).
2. Interface Requirement: The change request is typically formalized by a document/form, which contains the request from a non-technical perspective, such as “I want to replicate the creation of sales quotes in real-time between SalesForce and SAP S/4HANA”. Any helpful information should be added into the document, such as the availability of standard APIs, the frequency of the data transfer and if the integration is expected to run tightly (synchronous) or loose (asynchronous, which can also mean real-time).
3. Integration Platform Decision: To categorize an interface and decide which component of the Integration Layer (aka Integration Platform, Tech Stack) is to be chosen, an integration team is performing the analysis of the integration demand and selecting the best fit. This process can be supported by the principles of ISA-M and the Integration Assessment capability of SAP Integration Suite.
4. Build: During the development of the interface, the appropriate APIs have to be chosen or built in the applications and the choreography of the messaging is defined. Buffering/Queueing, retry- and error handling are defined as well as a proper usage of naming conventions and best practices. Message transformations are typically defined together with the team who provided the SDD to be precise on the definition of field (names, structure) and value mappings (content, e.g. code lists). Before the Build Phase is completed, a quality gate should be passed, where typical errors are checked (ideally automatically), before the tests can start.
5. Tests & Monitoring take place after technical unit tests were successful (connectivity, syntactical mapping execution works) and sample data was provided. During integration tests the applications are running in an integrated mode and are expected to exchange messages properly. The integration expert should monitor the system and observe the interfaces, if they are running robustly or if the error resolution strategy must be reviewed.
6. A Technical Documentation is key to provide the knowledge for other team members and allows a hand-over to new colleagues. Ideally this step is done automatically and always kept in sync with the as-is situation, even after some months or years post go-live.
7. The Transport moves the integration from Development/Quality into Production and starts formally already after the Build Phase (in Development) by moving to the Quality Assurance (Test) Environment. It is recommended to have a segregation of duties here by allowing to perform transports only selected team members or a dedicated operations team.
8. The Go-Live is the event where the first messages are flowing in the Productive environment and is followed by a hypercare phase, where the integration expert (together with the operations team) is checking the correct execution.
9. During the first hours and days it is essential to perform monitoring and alerting to keep an eye on the integration flows to ensure a robust behaviour and follow-up on unexpected situations (not anticipated during integration testing).
10. After a couple of days or week(s) it is recommended to review the performance and robustness of the integration flows to confirm a correct behaviour.

---

How do WHINT Solutions support the Interface Development Lifecycle?

1. When the change/demand enters the integration team, the current landscape is transparently available in the inventory and any reusable interface artifacts can be identified. – Inventory with WHINT Interface Catalog
2. We provide consulting services to define the workflow for integration demands and support with the setup of the Integration Assessment. Please have a look at our integration requirement demand form here.
3. Quality Checks are an important element of the Build phase and are generated from our WHINT Interface Documentation.
4. Testing is key and has to be performed by the integration developer and by the key users for an end-to-end integration test. You can also automate tests using external tools later on, but the initial development and integration test is mandatory.
5. The technical documentation is done automatically and periodically by our WHINT Interface Documentation.
6. Landscape checks are an additional quality gate to verify the correct transport and deployment of the version and included in our WHINT Interface Catalog.
7. The definition of alerts and automated check of error situations for different e-mail receivers is configured in WHINT Interface Monitoring. You can use SAP Cloud ALM for Operations – Integration and Exception Monitoring in addition as well.
8. The check for anomalies is also part of our WHINT Interface Monitoring to identify unexpected traffic situations.
9. A regular analysis of your traffic is important to verify the robustness. You can find statistical error situations, retries and other delays in our WHINT Interface Catalog.

Please note that not all features are available for all SAP middleware products, you can see our complete feature list here.