Say, there is a legacy CRM system called CRM-Z which is offering below functions:
1. Customer creation
2. Amend details of an existing customer
3. Retrieve details of a customer
4. Suspend a customer

• A.Implement a system API named customerManagement which has all the functionalities wrapped in it as various operations/resources
• B.Implement different system APIs named createCustomer, amendCustomer, retrieveCustomer and suspendCustomer as they are modular and has seperation of concerns
• C.Implement different system APIs named createCustomerInCRMZ, amendCustomerInCRMZ, retrieveCustomerFromCRMZ and suspendCustomerInCRMZ as they are modular and has seperation of concerns

Comment: *

Name: *

Email: *

Verification: *

What is typically NOT a function of the APIs created within the framework called API-led connectivity?

• A.They provide an additional layer of resilience on top of the underlying backend system, thereby insulating clients from extended failure of these systems.
• B.They allow for innovation at the user Interface level by consuming the underlying assets without being aware of how data Is being extracted from backend systems.
• C.They reduce the dependency on the underlying backend systems by helping unlock data from backend systems In a reusable and consumable way.
• D.They can compose data from various sources and combine them with orchestration logic to create higher level value.

Comment: *

Name: *

Email: *

Verification: *

Refer to the exhibit.

Three business processes need to be implemented, and the implementations need to communicate with several different SaaS applications.
These processes are owned by separate (siloed) LOBs and are mainly independent of each other, but do share a few business entities. Each LOB has one development team and their own budget In this organizational context, what is the most effective approach to choose the API data models for the APIs that will implement these business processes with minimal redundancy of the data models?
A) Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities

B) Build distinct data models for each API to follow established micro-services and Agile API-centric practices

C) Build all API data models using XML schema to drive consistency and reuse across the organization

D) Build one centralized Canonical Data Model (Enterprise Data Model) that unifies all the data types from all three business processes, ensuring the data model is consistent and non-redundant

• A.Option A
• B.Option B
• C.Option C
• D.Option D

Correct Answer: A

Correct answer: Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.
*****************************************
>> The options w.r.t building API data models using XML schema/ Agile API-centric practices are irrelevant to the scenario given in the question. So these two are INVALID.
>> Building EDM (Enterprise Data Model) is not feasible or right fit for this scenario as the teams and LOBs work in silo and they all have different initiatives, budget etc.. Building EDM needs intensive coordination among all the team which evidently seems not possible in this scenario.
So, the right fit for this scenario is to build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.

Comment: *

Name: *

Email: *

Verification: *

Select the correct Owner-Layer combinations from below options

• A.1. App Developers owns and focuses on Experience Layer APIs
  2. Central IT owns and focuses on Process Layer APIs
  3. LOB IT owns and focuses on System Layer APIs
• B.1. Central IT owns and focuses on Experience Layer APIs
  2. LOB IT owns and focuses on Process Layer APIs
  3. App Developers owns and focuses on System Layer APIs
• C.1. App Developers owns and focuses on Experience Layer APIs
  2. LOB IT owns and focuses on Process Layer APIs
  3. Central IT owns and focuses on System Layer APIs

Correct Answer: C

Correct answer:
1. App Developers owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. Central IT owns and focuses on System Layer APIs

References:
https://blogs.mulesoft.com/biz/api/experience-api-ownership/
https://blogs.mulesoft.com/biz/api/process-api-ownership/
https://blogs.mulesoft.com/biz/api/system-api-ownership/

Comment: *

Name: *

Email: *

Verification: *

An Order API must be designed that contains significant amounts of integration logic and involves the invocation of the Product API.
The power relationship between Order API and Product API is one of "Customer/Supplier", because the Product API is used heavily throughout the organization and is developed by a dedicated development team located in the office of the CTO.
What strategy should be used to deal with the API data model of the Product API within the Order API?

• A.Convince the development team of the Product API to adopt the API data model of the Order API such that the integration logic of the Order API can work with one consistent internal data model
• B.Work with the API data types of the Product API directly when implementing the integration logic of the Order API such that the Order API uses the same (unchanged) data types as the Product API
• C.Implement an anti-corruption layer in the Order API that transforms the Product API data model into internal data types of the Order API
• D.Start an organization-wide data modeling initiative that will result in an Enterprise Data Model that will then be used in both the Product API and the Order API

Comment: *

Name: *

Email: *

Verification: *