The first time this term has been coined was by Evan Evans which is in essence an extension of Object-Oriented design where it aims at creating software abrasions named Domain Models. The idea is that this abstraction tends to help the developers who are not experts in the domain context. Ok, now one might question what is the domain object?

Domain Objects
Domain objects are anything that you work with, usually an area of knowledge or expertise. In short, the domain represents anything that you want to model. The enterprise application requires a complex relationship across various entities, this abstraction would become handy and useful as this complexity would make the modelling a tedious task.

Another element talked about in the DDD is the ubiquitous language. Ok, another jargon, basically, the ubiquitous language is the language understood by everyone (one of that generalisation, perhaps by. perfectionists). Okay, this is too vague, but let’s put it this way this is the language or terminology used by the common users of the system.

Common jargon’s for the DDD

Context: The setting or the line of business the domain is discussed. Such as Shipping, Education or Lending. This is the zone that a domain is modelled and explained.

Model: A way to illustrate a domain and it’s interaction with object domains in the same context. You can use UML but ultimately any system which would work.

Ubiquitious Language: A language understood by the developer and the subject matter experts in the business context.

Out of the top items, the domain and the language tend to reduce the complexity of explaining how different domain objects are related. During this process, don’t be afraid of suggesting new names as this process tend to be iterative. That’s it, no big bang approach, small pieces.

Building Blocks

The DDD is based around the followings

• Entity
• Value Object which has no identifier
• Aggrgate: groups the entities and the value objects
• Service
• Repository : this would be similar to the Services in the Spring Boot
• Factory: the same factory pattern for constructing complex entities or value objects

The concept of service mesh has recently become more popular and the idea is to observability, the security and reliability features of the API Management Platform rather than the services. This is an abstraction technique for solving the complexity of API Management issues.

Why has the Service Mesh become more popular? Well, recently the containerised deployment, for example, Kubernetes, is advocating for this approach as a part of the cloud-native adoption process.

In this space, there are two projects to watch Istio and Linkerd. the pattern in question is called Sidecar, where a bunch of proxies are deployed along with the application (microservices). The role of these sidecar proxies is to facilitate the communication between the microservices., the control is done at a layer, called the control plane where the management of data flow on the data plate is done.

The Cloud-native applications usually consist of numerous microservices which are interlinked, each service might have multiple instances managed and controlled by Kubernetes. The challenge here is to provide a reliable and secure end-to-end performance for the intra-service communication within the service network, or the application network as referred by MuleSoft.

Products to Look

• MuleSoft API Management
• Zule ( Sprintboot)
• Linkered

Service Mesh and Kubernetes
In another article, I am going to talk about this topic in more detail. Stay tuned!

author: Pooyan Farahani, Data Integration Architect for financial services.

The digital age has changed the boundaries of retail businesses as more people are adopting new digital lifestyle and this has been a driver for many brick-and-mortar businesses to invest in developing their digital channels and ecommerce platforms. Perhaps one key characteristics of digital age is the importance of building a personal relationship between customers and brands. 

Since 1990’s The Internet boom, many ecommerce businesses emerged few been successful but many disappeared. Moreover, over the course of last three decades there has been a shift in customers’ perception about online purchases. In particular in the last decade many brick-and-mortar retail enterprises found themselves in a catch-up game with the latest trends; saying that they often found themselves integrating their existing channels with the ever new emerging sales channels, to name a few Facebook, Instagram, Pinterest or Twitter.  

The competition in the retail sector is fierce, hence the speed of delivering new features matching the customers’ needs is the turning point. On the other hand, as the demand for IT resources grows the ability to keep up with the demand diminishes. The key drivers for the changes are the large volume of data generated through IoT, various systems involved including CRM, Supply Chain and ERP systems and increasing number of sales channels and touch points.

This situation put a heavy burden on IT resources in terms of having to many reaching deadlines and a slow rate of delivering solutions to the business. This is not an ideal situation for a business as slow changes in the business means losing their market share to rivals due to unhappy customers switching over to rivals. 

Building A Deeper Relationship

Acquiring a news customer is much more expensive than keeping the existing customers. So, it makes sense businesses to employ the best tactics to keep their customer happy and make personalised offer to them. Often retail businesses over the course of multiple M&As end up with silos of CRM systems which do not work as effectively as they should be. The lack of integration across systems means hidden information are buried in silo systems and not utilised for fostering a richer relationship with the customer.

In below, we have prepared a common list of challenges we found in retail businesses:

• Silo systems which are not synchronised and lots of functional overlaps and data duplication across the IT landscape,
• Integrations are done to solve tactical problems,
• Channel-focused marketing exercises which are split across online and in-store divisions,
• High cost of developing integration projects and a time consuming process,
• The customers wants and demands are growing at a higher pace than IT resources can keep up
• The old way of adhoc integration overtime is expensive to maintain and scale.

One of the elements of brand loyalty, as referred by Digital agency Wunderman, is the concept of wantedness. The wantedness is not about how appalling a brand for the customer, but contrarily is about how brands care about the customers. A study in US consumer marker shows that %79 of customers strongly responded to how brands pay attention to their customers had an impact on their purchasing decision.

Brands demonstrate their care towards customers all along the customer journey from the point customers engage with marketing emails, throughout the purchase and collection of their desire products. The role of technology in this space is to deliver a smooth purchase experience for the customers.

Building A Personalised Relationship With Customers

Building a long-lasting relationship with the customer is not easy; often businesses try to employ the technology to add a human-like relationship with customers. The goal here is to go beyond a transaction and develop a personal relationship. Gaining insight about customers’ preferences requires capturing data from an ever growing number of touchpoints which a customer might engage with brands, and build a cohesive view of customers’ wants and desires using that data. Often smaller players in the market rely on best spoke vendors, and it helps to foster a deeper relationship with the customers; however as the organisation grows so as the number of departments. In this case, there will be an increasing number of sale channels, and it will be costly to the keep asking vendors for integrating with other third parties and hard to maintain.

Steps to Transform Your Retail Landscape towards a Network of Retail Application Networks

The above issue sounds complicated, but an API-led approach could help you to build a Network of Retail Applications with two tangible benefits:

A) Reduce the development cost of integrating applications

B) Bring on the agility into the business by faster delivery of projects.

Reusable Digital Assets with Self Service Functional Point

This is a strategy to define reusable assets as self-service assets in which different partners can create new “Composite Enterprise” Applications. An excellent example of self-services are the Amazon core services which enable multi-vendor shops to integrate with Amazon e-commerce platform and encourage the business to build innovative services out of existing reusable services.

Developing a network of retail applications which can scale and adopt quickly with the latest customer trends.

Once, the core services are in place, the new services can be developed using the core services. The emphasis is to avoid top-down approaches where requires investing heavily to build all services from the scratch. The idea is to use the existing services to compose new applications/services.

Deliver a Unified Customer Experience across Online and In-store

The challenge most of the retail businesses are facing is about delivering a unified experience across in-store and online platforms. In the retail industry, the most challenging task is to come up with differentiating elements for products, while delivery a subpar customer experience would lead to a market share loss and potentially bankruptcy.

MuleSoft conducted a survey of retail customers and interestingly they found consumers’ purchase decision in the past were based on cost, choice and convenience. Whereas now the technology assists consumers to constantly compare and contrast different brands for the same product. Platforms such as TrustPilot, CompareTheMarket or Confused.com help customers to gain valuable insight about products and the quality of brands. Hence, customers value brands who care most about their customers experience as they constantly check for reviews and compare brands.

A good example for monetising customer engagement through APIs is Amazon. Amazon has delivered a better customer experience by allowing customers to choose colours, size of the order and returned the product as they wish. Additionally, the delivery process in Amazon provided a transparent experience for the customers where they can track the delivery of their products as they want to. It is evident that the “True Customer Obsession” is still at the centre of Amazon business. More importantly, Amazon’s strategic shift to a Platform-based model helped them to align with the latest trends in customer demand and becoming more customer-centric. The lesson learned from Amazon and RadioShack is rather than focusing just delivering an e-commerce platform focusing on providing a consistent digital experience that aligns to modern consumer’s consumption behaviour. As the World Economic Forum stated e-commerce level of communication stands at 10% of current trades, and it is expected it will reach 40% by 2026. Retailers recognise they should focus on building a unified omni-channel experience to improve customer loyalty to brands.

Many successful implementations of ecommerce platform solutions have employed APIs to gain deeper access to the customer data across an organisation i.e. customer 360 views, and use this data to form a deeper relationship with their customers through marketing and promotional means.

The main question comes to mind is how to build an API ecosystem with limited resources.

Working across many industries, we have seen situations in which there is a strong need for an agile set of tools to implement APIs and more importantly have governance around it.

First Steps:

1- Identify the core systems, in other terms core system of records. These systems are the most reusable services or assets within your organisation. In terms of a retail business, the core systems could be CRM systems, Supply Chain management systems, Fulfilment and Logistics and e-commerce systems. This way, we have core services exposes, so we can compose them to build new processes or move data around across core systems.

2- Once the core services are identified and exposed as System APIs, the next tier of APIs are Process APIs. Process APIs are effectively orchestration APIs to define data journey across multiple APIs, and most likely, the Process APIs involve some elements of enriching data using third party data or internal APIs. An example of orchestration API would be onboarding a new customer for a multi-vendor store in which customers’ credit score are checked to identify his/her segment, e.g. economy, middle class or affluent.

3- Having processes encapsulated into APIs, the next step is to let other third parties or clients use those services. This is done through experience APIs where each API is explicitly designed for a client. The client can be a mobile application, an event-driven process triggering a process API upon receiving a particular event, or simply a website or a POS system.

At this point, you might question what the benefits of this approach are. The main advantage is creating a set of highly reusable digital asset/services. The IT managers would look at it as a cost-saving opportunity. The second benefit of using this service is the lower cost of development and better scalability. MuleSoft out of the box comes with a blend of different connectors, facilitating a reliable data exchange with different software vendors. This alone has a massive saving in learning curve a developer go through to get familiar with APIs of a sophisticated system like Salesforce or SAP. In most cases, they need to know which query they should use to access a specific dataset; the rest of technical matters are dealt internally with a robust connector.

When the organisations’ API footprint grows, the governance of APIs become very important. MuleSoft has invested massively in providing the best of its class API management solutions along with other vendors like Apigee. The API Manager allows the developer to define a set of policies and SLAs for each endpoint. Having the API manager integrated with IAM solutions, you can define security policies for each endpoint along with usage policies such as resource-level policies, e.g. rate-limiting.

As stated by MuleSoft some retail businesses achieved their integration goals at the reduced price of 30% of traditional methods.

Conclusion: Using API-led connectivity could bring many benefits to a retail business. This consist of aligning customers’ wants and demands with the provided features in the market. Agility is another factor to take into account where the time-to-market of new products or features, can be reduced significantly. At XAGROSE we are keen to hear about your integration requirements and help you to improve your customer experience throughout your business. Stay Connected!