Reading Time: 12 minutes

Part 1: The Challenge

Let’s imagine you’ve been working as an architect in a large company for several years and are very proud of the now mature Supplier Relationship Management (SRM) application you specified, formed, and delivered to the business, as it continues to provide value.

Functionally, the SRM is a web application that allows for managing relationships of suppliers and materials, maintaining hierarchical structures, uncovering unwanted dependencies and helping your clients significantly reduce supplier costs. Your department was chosen for this quarter’s highly visible and mission-critical innovation project: a new mobile application.

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

Luckily, one of your largest customers is building hydraulic excavators and is very interested in working with you to deliver this mobile application. Your customer wants to gain real-time visibility into the materials hierarchy for the field sales team. This will drive efficiency improvements as paper-backed catalogues can be eliminated and material price currency conversion and material data information can be made available in real time. On top of this, the field sales team will be able to better map supply chain dependencies and discover from their mobile devices the specific materials shipped by various suppliers, delivering a significant productivity boost against an otherwise manual and time-consuming process.

Thinking about the components that represent your solution you might come up with something like this:

solution-components

As you are an experienced architect, you’ve created a plan to implement these features within your application. Checking back with your company’s release management your next release is scheduled to take place in 8 months. The business, however, is demanding that the application be delivered in 2 months, and scaling the mobile application back is not an option.

In addition to these timeline pains, you also face the following challenges in delivering mobile functionality on your mature SRM:

  • The SRM was not designed nor built for mobile connectivity and scalability requirements
  • There are no general purpose feature hooks for data enrichment (e.g. Cloud or SAP) – besides probably a basic D&B or Equifax integration
  • There is no easy way to craft new APIs, have them mocked and parallelize mobile and SRM development
  • You are facing month long release cycles and the product team is already overcommitted to deliver promised features in the next version

The primary driver of these pains: the SRM wasn’t designed with these requirements in mind. Instead, it was built as a web application with very tailored business workflows. Looking at your current REST APIs the mobile app could partly be implemented, but it potentially wouldn’t scale as the application is backed by a relational database which would need to perform heavy join operations to craft the needed results.

Project requirements

So what are your requirements?

  • Mobile enablement of the existing solution
  • Fast running queries to retrieve supplier and material relationships without affecting the existing web app while it’s running
  • Add a real-time currency converter capability extending the limited DB schema of the app
  • The existing app can’t be changed for the mobile application
  • Maximum two month timeframe to ensure you and your manager reach the target (and get commission)

What do you need to deliver on these requirements?

First of all to enable mobile developers, you will need an API. Even more, to enable the guys to start immediately the API should be a mock up and easy to adjust, so you can react quickly to feedback and changing requirements

Secondly, there needs to be a way to easily retrieve the hierarchical structured information and that solution has to be extendable.

Thirdly, a manageable and simple way to develop and deploy business functionality such as queries, commands and synchronisation tasks as single runtimes.

CQRS

Let’s have a look how you can use the Command-Query Responsibility Segregation (CQRS) pattern and an agile approach to implement your solution.

Never heard of CQRS? CQRS suggests you:

  • Solve read heavy requirements
  • Scale reads and writes independently
  • A wire-friendly view model in contrast to your complex domain model
  • Don’t assume queried data is 100% up-to-date
  • Clients send Commands to the server, not state changing facts
  • Commands can be queued and processed asynchronously
  • Use CQRS only on specific portions of your systems
  • Think in domains (also see Bounded Context)

Consider checking out the following on CQRS for additional context and insight:

Let’s look at how we can use this approach to solve your requirements.

Query like this…

Supplier and material relationships fit cleanly into a graph database as all relationships are easily manageable. The graph data model you keep in the graph database makes it very easy to design new business features incorporating graph relationships and map that to your mobile apps view model.

So, let’s make Neo4j, the world’s leading graph database, responsible for delivering the high performance results on digging through your hierarchical data and therefore divide query and write responsibilities.

…and Command like that.

Write via the existing Web API of the SRM app or write directly to the database. For the sake of speed and missing Web API functionality, let’s focus on the DB only first.

Sounds good? Yes! But we also have a challenge. How do you get Neo4J and SRM synced so we can actually query current data from Neo4j?

The answer:  MuleSoft’s Anypoint Platform

MuleSoft’s Anypoint Platform comes equipped with ETL-like capabilities that will keep SRM and Neo4j in sync by running a background synchronization. For this synchronization task you could opt for Availability and Partition Tolerance (AP) as per CAP theorem instead of Consistency and Partition Tolerance (CP) between Neo4j and SRM.

This would mean there might be points in time where the data queried from Neo4j is not consistent with the data in the SRM app. An ongoing write operation in SRM might not be visible with a Neo4j query. For most use cases and as an assumption for CQRS this is an acceptable requirement as the out-of-sync time period is usually negligible and the data still fulfills business requirements.

Achieving 100% Consistency and Partition Tolerance, or CP, should be feasible but the significantly higher costs of doing it have to be justified with a realistic view of the requirements.

Logical Solution Design

logical-solution-design


The figure highlights three areas to attack:

  • data synchronisation
  • data query
  • data commands.

All of these can be implemented by following the Separation of Concerns (SoC) principle, meaning you use a separate and isolated runtime for every clearly defined business/integration function: namely Data Synchronisation, Data Query and Data Commands.

NOTE: To make this happen, touching the mature SRM application is not required, enabling us to move forward with new projects in the future.

Now that you have a plan the next step is to build the project leveraging the full power of  Anypoint Platform. Our upcoming posts in this series will cover these implementation details. Specifically, the next post will cover how to quickly enable mobile developers to begin building a prototype application with your Neo4j NoSQL database with API-led connectivity.

You best get started with our brand new whitepaper on API-led Connectivity!