Today businesses are changing faster than ever. Business models are evolving and being transformed every day. There are greater expectations in terms of innovation, business performance, results, and effective use of resources. All this is putting greater pressure on the organizations to find new ways to streamline their processes and share information effectively and seamlessly. In other words businesses today need to be more flexible and responsive than ever before to their customers, suppliers, partners, vendors, and most importantly changing business models.
As ERP systems are at the center of enterprise business model, they need to provide a way for the business processes to participate and collaborate with external applications, partners, and information. Enterprise applications are moving from being monolithic and self-contained to the being more and more flexible and collaborative.
Whats Wrong with Traditional EAI?
Traditional integration focused on solving some of the above-mentioned requirements by enabling data flow between silos and external applications. It helped to a certain extent but over the time the complexity and of the integrations started posing serious concerns. The issues were proprietary technology used for integrating applications was a gridlock and it was not easy to easily orchestrate business processes between the disparate applications using the traditional eai.
What is Service Oriented Architecture?
SOA as it relates to software paradigm is an agile architecture approach that is based on service-oriented principles of composition, abstraction, loose coupling, discoverability, and amalgamation. SOA inherently empowers scalability, evolution of services, interoperability, re-usability, and modularity.
Do we need SOA based Integrations?
Using SOA principles while designing application integrations results in SOA based application integration. Simplicity is desired for the traditional and complex world of integrations. Better and common sense approaches such as Service interactions and amalgamation supported by Open Standards should be enabled. SOA is needed for the following main reasons:
- To provide seamless agility to business
- To improve business process visibility
- To simplify the current rigid and complex state of IT
- To enhance efficiency and provide cost-effectiveness
- To enable re-usability factor
- To provide better quality of service
But you are still doing integration?
Yes. Besides the obvious advantages enumerated by everyone, the key advantage of this approach is that you are contributing to the future of the SOA of your enterprise. The integrations with service-oriented approach are loosely coupled with the infrastructure components and more flexible and refactorable. Logical end-points for integration services provide far more decoupling and is implementation agnostic. The components and integration services can be used for creating a composite application or business process later. The benefits of adopting SOA grow with time. Once you have these reusable components from across applications, application modules, and other enterprise software components, creating a new application is relatively easy and thats when the full potential of SOA is realized.
Design your SOA Integrations
Most of the design depends on the requirements. But before applying the very same approach you took for your earlier integration project, you need to keep in mind is that the goal here is to come up with integration components that are designed for interoperability, re-usability, and modularity. The key to designing your SOA integrations is remembering that they are SOA based. Using and adopting SOA principles is the key. Always try to apply SOA principles composition, abstraction, loose coupling, discoverability, and amalgamation to your services and integrations.
Architecture Perspective: Guidelines for SOA based Integrations
Based on my experience, considering the following guidelines can help you realize the SOA vision for integrations with EBS. Most of the following guidelines are generic and can and have been applied to other ERP integrations as well.
Use standards: Using standards based technologies for your service-oriented integrations will help eliminate lock-down with products and companies. This is one of the biggest challenges with traditional EAI. This will enhance easy evolution, enhancement, and composition of business processes that may use services related to integrations.
Classify Integration Requirements:
Categorize requirements into data integration and business process integration. Identify message exchange patterns and use ESB functions (transportation, mediation, and routing) to model data integration processes. Use BPEL for modeling your processes that involve anything more than what can be satisfied with ESB functions. Many times it is hard to classify and try to fit a particular integration process in one of the two buckets. In such cases it will be a good idea to use layered approach and use ESB functions for data integration and use BPEL for future extensions to the business integration process.
Introduce Extensibility:
To deliver on the high hopes for soa based integration architecture solution, it is very important to do some forward thinking for the desired flexibility and agility in your integration architecture. To deliver on that, think hard early on ways to introduce extensibility and forward compatibility into the architecture and all the components including individual integrations and messages.
Service Enable Enterprise Application Functions:
Enterprise applications have many business functions and technology components that are application specific and depend on proprietary technologies. These components or functions should be service enabled before they can participate in the service oriented integration architecture. Using resource adapters is a way of connecting and interacting with the application specific components. It is important that the resource adapter is implemented using industry standards such as J2CA, WSIF, and WSDL and can provide a web service interface to the application specific functions.
Inject Resiliency:
Build resiliency into the individual integration processes. This may be easy to miss as even with the best architecture in place. Always think about all the what if scenarios and try to inject process level resiliency into the individual integration processes.
Exception Handling:
Despite all the forward thinking there are things that might and will go wrong. Define reusable, extensible, and agile approach to handle exceptions at process level and other unknown exceptions. Using a common exception handler service with extensible interface can provide the flexibility, re-usability, and extensibility.
Simplify Support Functions:
Any one who has worked with application integration can relate to the great deal of time and energy waste involved when troubleshooting integration issues. With asynchronous messaging and multiple services, the idea should be to ease the pains of traditional EAI support functions. This can be done by thinking ahead about how can support functions be empowered with better ways to provide information visibility and take actions. Notifications and human work-flow are some of the ways to empower your support team.
Human interaction and intervention:
Business processes inevitably will involve human interaction in some or other form. If your integration process involves such role based people interaction, plan ahead and use standards based mechanisms to have human work-flows.
Separate Business Rules:
The integration process probably is not a good place to embed and hard codes the business rules. Identify the rules and provide loosely coupling between your process and rules. This would provide the flexibility to change business rules dynamically without modifying or redeploying your integration services or processes.
Business Process Visibility:
Plan for providing visibility into your so integration or business process. This is very important because today enterprises have heterogeneous systems and applications and with integrations spanning multiple systems, it becomes very hard to have visibility in run time. Users (IT and Business) should be able to monitor and have visibility into your business processes and integrations.
Service Composition:
Provide the capability to provide business functionality that is composed of disparate and/or independent services. The composite solution may cater to an integration solution or a new future business process. Service composite architecture is the relevant standard that addresses service composition. It provides the specifications to describe the model for building applications and systems using a Service-Oriented Architecture (SOA).
SOA Governance:
In simple terms, plan for the capability to manage and apply policies for the services within the service portfolio of your integration services. This is critical for SOA and needs to be planned well to ensure better management and control of services.
One thought on “SOA Factors in ERP”