Skip to main content

18.13 HANA, Cloud & Non-SAP Integration Playbook

Discovery​

  • Source owner identified.
  • Source technology identified.
  • Data volume measured.
  • Freshness SLA defined.
  • Consumer workload understood.
  • Security classification documented.
  • Source constraints documented.

Pattern selection​

  • Federation evaluated.
  • Replication evaluated.
  • Data flow / ETL evaluated.
  • Open SQL push evaluated.
  • Existing enterprise integration platform evaluated.
  • Duplicate persistence challenged.

Engineering​

  • Initial load defined.
  • Delta strategy defined.
  • Delete handling defined.
  • Idempotency defined.
  • Schema evolution defined.
  • Reconciliation defined.
  • Recovery defined.

Performance​

  • Remote-query workload measured.
  • Source protection tested.
  • Statistics evaluated where relevant.
  • Filtering applied.
  • Unnecessary columns removed.
  • Persistence used where justified.
  • Concurrency tested.

Security​

  • Technical identities separated.
  • Least privilege implemented.
  • Credentials or certificates lifecycle managed.
  • Network path documented.
  • Audit requirements defined.
  • Data access controls validated.

Enterprise architecture​

  • System of record identified.
  • Integration ownership identified.
  • Semantic ownership identified.
  • Data product boundary identified.
  • Failure domains identified.
  • Cost model identified.
  • Retirement strategy identified.

Architect interview framework​

When asked:

"How would you integrate a non-SAP cloud platform with Datasphere?"

Answer:

  1. Understand source ownership and workload.
  2. Define freshness, volume and latency requirements.
  3. Evaluate federation, replication, ETL and push.
  4. Validate the connection's actual supported features.
  5. Design security and network boundaries.
  6. Design initial and delta processing.
  7. Define reconciliation and recovery.
  8. Measure source and target performance.
  9. Establish semantic ownership.
  10. Expose governed data products.
  11. Define cost and operational controls.
  12. Document the retirement or change strategy.

Final architect test​

You should be able to defend:

  • why data is federated or replicated,
  • why persistence exists,
  • where transformation runs,
  • how the source is protected,
  • how failures are recovered,
  • how freshness is measured,
  • how security crosses boundaries,
  • how cloud platforms coexist,
  • how duplicate data is controlled.

The objective is not maximum connectivity.

The objective is a reliable, governed and economically sustainable enterprise integration architecture.