This is an analysis of integrating an Order Management System with a third party older system that does not meet current requirements such as omnichannel customer experience. We decide to put the legacy system downstream from the user interface and behind the new order management system. We explore options to leverage existing without writing code such as with data migrations to the legacy system so that the bulk of the processing continues to be done by the legacy. In this exercise, we get to know the shortcomings of the older system that we can mitigate with the newer system. The older system may impose restrictions in how the data is handled and may have quirks that will need to be scoped before the integration. Some edge cases such as a single order with large number of items and a large collection of smaller orders might serve to study the old system’s behavior. These can be alleviated in the new system but the integration can happen across any or all of the three tiers of database, services and user interfaces. It would be prudent to integrate them at the service layer so that the customer experience does not suffer from any of the legacy interactions. Even if the cost is slightly more for UI development, it will help to give a newer more studied experience to the user than anything from the legacy system because we will find it hard to change the experience given that the legacy is third party. In this regard, a service based integration of different domains seems prudent. We will discuss this shortly but let us take a moment to see data integrations. The legacy third party system should be checked for bulk upload and processing of data. If such an option, were available, we can perform extract, transform and load operations that will remove the burden from the online expectations of the customer and the delays and latencies imposed by the third party legacy system. Offline or batch processing options with the legacy system may also help with reducing cost and streamlining the user online interactions. Wherever possible, even the new system could handle asynchronous processing to provide better online Service Level Agreement to the customers of the Order management system. Since the service provides a convenient business layer for the integration, all interactions between the the third party and the Order Management System may be captured at this layer. A microservice model that targets different aspects of the third party services such as inventory, fulfilment and payment separately, will help with the integration testing at the interfaces. This lets the services be hosted separately so that the services can be cloud-ready. The service layer may use these microservices to compete the user requests. This is also helpful to the user interface which can be written new and made available on the browser or devices because they now interact over the http with a single service endpoint. A sample order for an item from the user may involve the following steps: the item will be queried from the inventory to see if it is in stock. The order may then be fulfilled by locating the item by its identifier and changed to sold. When all parts of the order are completed, the order may be marked as completed and closed. Given that we have to integrate with a third party system that can inject failures at anytime during the above workflow, we discussed two options to process the orders. Each order may be put in a transactional scope so that it fails entirely when any of the failures occur. The second option was to allow incremental progress with retries by maintain state during the workflow. Both options do not necessarily change the customer expectations because the failures can be managed internally as much as possible. That said, the customer experience might improve with the system giving more status information on the order placed. When the customer wants to check back on the status, the downstream systems activity updates would have found its way to the customer. As long as the states gets updated in the forward direction from the initialized, pending, fulfilled, acknowledged and closed/canceled, there will be minimal errors introduced. Moreover offline processing for those states may also be enabled. The application may require offline processing for such things as email notifications to the customer. Even though the user interface may be user driven targeted for 100% satisfaction, the offline notifications such as emails will bolster the customer experience for easy reminders and follow-ups. Emails also help with continuous acknowledgement throughout the fulfillment process. Customers orders are also useful history to have so if the legacy system is not handling these operations then the data may be captured in transit and augmented with statistics. Components such as payment services may be streamlined and externalized so that the role of the legacy system is reduced and it may gradually be phased out or replaced. Payment services also need to adhere to compliance policies because the cloud is generally not used for sensitive data until safeguards and compliance checks are complete. Vendor Management services may also be enhanced over time separate from the existing ones supported by the legacy system. The design would be more flexible when the dependency on legacy system for vendors is reduced and the corresponding mapping is maintained in the order management system. Inventory and catalog service may require a database different from the orders in that the catalog may be very large and the operations on it may be very different from the order management database. The interactions with the other systems may be better managed in the service layer without directly querying the data sources. Services may also be across gateway or enterprise service bus especially if they are legacy. Address, binding and contract for these services may need to be defined for the integration. A microservice model instead of service oriented architecture for all components will greatly help with deploying the services in the cloud. The ability to load balance and rotate the hosts for the applications will help with resilience on server failures and it will be seamless to the users. Each service logs may flow via syslog to an index which can tremendously help with troubleshooting and diagnostics. Similarly, authentication, authorization and auditing need to be enabled for all services. This is different when the order management system is external rather than internal because there may be a different authentication and authorization service. Also, the external facing applications will have more stringent compliance than internal systems. Cloud based services in general lend themselves to be easily moved from internal to external.
#coding exercise
Find the diameter of a tree
In the diameter (node root )
{
If (root == null) return null;
Int lh = height(root. Left);
Int rh = height(root.right);
Int ld = diameter (root.left);
Int rd = diameter (root.right);
Return max (lh + rh +1, ld, rd);
}

Int multiply_with_minimum_additions (int a1, int a2)
{
Int res =0;
Int count = 0;
While (a2)
{
Int add = 0;
If (a2 & 0x1){
Add = a1;
}
For (int I =0; I < count; i++)
{
Add <<= 1;
}
Count++;
Res+= add;
A2 >>= 1;
}
Return res;
}