If Your Org Uses a Big ERP or CRM Suite, Don't Build Everything For That Ecosystem
If you're using Oracle or SAP, don't implement everything in Oracle or SAP frameworks. Use open source too. Don't get locked in and don't let these suites halt your microservices plans.
Join the DZone community and get the full member experience.Join For Free
Today, in high-paced enterprise environments, you as the leader of the enterprise IT division, need to be fast. Simplicity is the key to speed.
What are the key factors to simplify your IT? Three different areas are very important to take care of: Technology, Organization and Environment (TOE Framework:
Here are some detail points for technology and organization:
1. Technology: in most enterprises there are already one or more ERP and CRM solutions: the so called Enterprise Applications. We need to manage them carefully as they support the business processes. In the context of the core compentencies, most enterprises customize the enterprise applications to fit their needs. We need to manage the customizations in detail as they represent the core competencies and at the same time the differentiation of our enterprise to other competitors.
2. Organization: working in a small team with different roles and functions is already proved as the best way today. Scrum or small cross-functional agile team - organized around business capabilities - for one domain e.g. Order Management with its own product manager or product owner, business analysts, IT architect, developers, testers and operation people can work more concentrate and deliver the best result for the business. This type of product organization is the key to the Microservice Architecture (http://goo.gl/wglXLp). A product organization does not imply that there is no need for an IT division in the enterprise anymore. IT division is becoming more important in this context since e.g. all the developers spread around the product organizations need to exchange their experiences and learn from each other. Sometimes they also want to move from one product to another product. Also development processes like model and source code versioning, continuous integration and deployment should be centralised so that not each product organization will have to build its own process. An IT division within the enterprise can be seen as the "home sweet home" of IT architects, business analysts, developers, testers and operators. As we know having a strong home is the base of strong, successfull and brave children.
In this article we will look into the detail of the customization and its relationship to the Microservice Architecture which represents the technology point above.
Enterprise Application Customization and Integration with Microservice
Every enterprise needs individual software, no matter how good your standard software is. In many business domains like human resources, accounting and customer relationship standard software like ERP and CRM already offer best practices in business entities, services, and processes. Using them are mostly enough since the key processes are similar all over the enterprises. Some of the components are different but only in the configuration of how the processes should be executed. Most of enterprise applications (ERP, CRM, CMS and DMS) offer customization by configuration for this purpose.
Before going any further we should define how customizations can be done. Each enterprise application has it own definition of what customization is. In e.g. SAP ERP customization means actually what we know as configuration. Here are the categories of customization:
A. Customization by Configuration: in this case we can use the internal function of the application to change the character of the application. Example:
- If you use JIRA you can define new fields of an issue as you need it without programming.
- If you are using SAP ERP you use the Implementation Management Guide (IMG) to configure the processes in SAP.
- If you are using Oracle E-Business Suite ERP you can use personalization to personalize your page.
In this customization type there are no problems if you upgrade your ERP installation because it uses the internal functions of the ERP.
B. Customization by Modification: in this case we make modification of the components within the ERP. To be able to modify we need to have the source code of the components. This customization type is in general not advisable because it will make the upgrade process complex and impossible. It is preferable to use the next customization type.
C. Customization by Extension: in this case we extend the functionality by creating a new component. Some enterprise applications offer the concept of plugins and exit points. In general an extension needs an integration point for example at UI (User Interface) layer, Business Logic and Entities layer and Data layer.
Back to the individual software, in other domains like Order Management the situation looks different. The order entities are very different in each domains. For example SSL certificates order entity has different characteristics than an order for shoes or an order for collecting waste. Also the order process looks quite different. The customization process is in general more complex and Customization by Configuration is mostly not enough. In this situation there are two alternatives as follows.
1. Customization by Extension using the standard mechanism from the ERP software.
Customization by Configuration is mostly not possible in this situation or at least not completely possible. Using the same technologies from the ERP software we can extend or modify the ERP software. This kind of extension is a tightly coupled integration with the ERP software. The deployment would be also done in the same container as the ERP software. Although this type of deployment is for Oracle E-Business Suite not adivisable (https://goo.gl/AJKbHh). If your IT division has no competence in software development this alternative would be mostly done by the company which introduces the ERP software. Figure 1 shows the architecture of this solution using Oracle E-Business Suite as an example. In this figure we can see an extension of iSupplier Portal (https://goo.gl/KWz7Pq) with a simple File Upload feature (File Upload Webapp) using Oracle Application Framework (OAF) (https://goo.gl/me4kT6).
Figure 1: tightly coupled integration Monolith Architecture of extension
- The extension is integrated and tightly coupled within the ERP software. Especially in the UI (User Interface) area this is a huge advantage.
- There are good integrated customization tools within the ERP software. In Oracle E-Business Suite you have the so called Customization Manager: http://goo.gl/qtoBFc. In SAP there is the Transport Management System: http://goo.gl/1sG6Jb.
- You don't need to take care of single-sign-on and security since the webapp is running within the context of E-Business Suite.
- In the beginning it is easier to handle one big "monolith", all in one place solution, as the First Law of Distributed Object Design says: don't distribute your objects (http://goo.gl/DFnUpG).
- It uses the technologies of the ERP software and this depends on the vendor of the ERP software. This means higher license cost, high dependency to the vendor, restricted resource to find for the compentence in the vendor know how. In the time that Open Source Software is already mature you are stuck with the vendor solution. Also with new findings like Microservice Architecture you will have to stick with the monolith solution from your ERP vendor.
- In some ERP software like Oracle E-Business Suite you still need to handle all the software development process on your own like versioning, continuous integration and deployment.
- Deployment in Oracle E-Business Suite shown in Figure 1 is not advisable. You can deploy the File Upload Webapp in an external OC4J similar what this article mentioned (https://goo.gl/AJKbHh). The problem with this approach is that we need to take care of the security and single-sign-on just like the next solution.
- Until certain point you are in a heavy weight situtation through the monolith architecture. It is difficult to extend and to rework, because you need to test everything in the monolith. You sacrifice flexibility and speed.
The difficulties of updating the ERP software because of the Customization by Extension or Modification cannot be seen as disadvantage since this type of customization always implies the same problem. All the extensions should be retested with the new version of the ERP software. This is just a simple problem as we already know everywhere in software. As a Java developer we know that before we upgrade e.g. our Eclipse IDE we should know whether all our plugins are still working with the newer version of Eclipse.
2. Customization by Extension using external standard and Open Source technologies.
This solution is loosely coupled integration to the ERP software. We don't need to use the technologies of the ERP vendor and can use the Open Source technologies available. Using the state-of-the-art architecure like Microservice Architecture is also directly possible. The deployment would also be done somewhere else and not in the container of the ERP software (see Figure 2).
Figure 2: loosely coupled integration Microservice Architecture of extension
- No tight dependency to the ERP vendor technologies. We can use the resources of our own and build the extension with internal knowledge Flexibility and speed is the key in this case.
- We can use general best practices and new architectural solutions without waiting until the ERP vendor introduces it.
- Thinking of your extension as a simple service (== Microservice) would decompose the complexity of your applications. This means that we can develop the extensions much more simple and get finished faster (http://goo.gl/Z9PyFE).
- As we still need to handle all the software development process by our own we can use already established internal mechanism.
- We still need an expert who knows the integration point to the used ERP software. Because at some point we need to integrate our solution into the ERP software (UI, business logic and entities or data layer).
- At the UI level this solution could look really different. This could be positive or negative for your user. For Oracle E-Business Suite 12.1.x users with an old Oracle forms look&feel a good looking state-of-the-art UI like Bootstrap has surely positive impact to the users.
- We need to take care of the security and single-sign-on, to be able to have a smooth integration with the Oracle E-Business Suite.
In this alternative we can introduce Microservices. Each extensions can be grouped as Microservice and mapped to the right product organization. How we implement the Microservice depends on the available know how. For the organization with modelling knowledge using BPMN, UML and Open Source products like Camunda and KissMDA could be very compelling to implement the Microservices. The typical advantages of Model Driven Development can be read here: https://goo.gl/CbvWb1.
Some interesting discussions about Microservices and BPMN Integration Platform can be found here:
- Microservices and the Integration Platform: https://goo.gl/4qQuYG
- Orchestration using BPMN and Microservices - Good or bad Practice?: http://goo.gl/CLHq43
- German language: Wie lässt sich Ordnung in einen Haufen (Micro-)Services bringen?: https://goo.gl/ibbxym
- German language: Wer Microservices richtig macht, braucht keine Workflow Engine und kein BPMN: https://goo.gl/NJQgbs
Using Java and Open Source frameworks like Spring Framework and NetFlix OSS - all together bundled in Spring Cloud - for building Microservice is definitely a standard way for enterprise computing today (http://goo.gl/l5zvWD).
The customization of your enterprise applications like ERP or CRM software by extension should be managed carefully. Under the condition that the knowledge is available in the enterprise using external and Open Source technologies are the best way for simplicity and speed. You can exploit the advantages of Microservice Architecture now, without waiting too long for the vendors to come up with the same solution. Your customization by extension is also independent of the vendor's technologies. If you don't have the know how, search for it and find it. Don't let the vendor lock your extensions in their technology:
- If you are using Oracle E-Business Suite, don't implement everything in Oracle Application Framework. Try to integrate Open Source frameworks and solutions to build your own Microservice Architecture.
- If you are using SAP, don't implement everything in SAP Java technologies e.g. Web Dynpro and SAPUI5 within Netweaver. Also try to use Open Source frameworks and Microservice Architecture.
One aspect you should not forget is the domain and the ERP integration know how you need to solve first, but for us as IT leader, this is just business as usual.
Dr. Lofi Dewanto is Head of Application Development at Interseroh Dienstleistungs GmbH, a leading environmental services company in Germany, and he is a long time native Java, Model Driven and Open Source speaker. He also writes for different technology magazins online and offline like heise Developer and Java Magazin.
Opinions expressed by DZone contributors are their own.