Some business problems, never gets old. Interoperability among systems or application is one such issue that requires varying degree of treatment depending on the type of organisation and business stage. This article penned by Let's Kopi is most suitable for startups and SMBs.
A hybrid technology environment is inevitable for any business
Organisations depend on business applications to empower various capabilities to optimise operations, generate growth, enhance customer experience, and accelerate innovation. A typical enterprise technology architecture today delivers these
capabilities by cleverly balancing in-house solutions with a number of Saas services (e.g. Salesforce, Service Now, Box, etc). Though, most post millennial startups are built on cloud-first strategy, which means an internal datacenter does not emerge until business matures with a satisfactory level of solution adoption and customer base.
Business processes transcend cloud and non-cloud applications
In either scenario, businesses ends up with an enterprise technology environment that spreads across the in-house datacenter, hosted datacenters and various public clouds. Stringent industry compliance, data security, privacy, and call for other regulatory requirements will continue to push at least some parts of the business systems to on-premise deployment. This means critical business processes will continue to transcend several applications to invoke one another in completing workflows, share data, exchange messages, and push results to performance dashboards across a hybrid and multi-cloud environment.
Building integration between applications is necessary….
Linking and integrating applications residing in cloud and non-cloud environment is a common undertaking for businesses that depends on automated processes, mobility, data, and insightful predictions for superior performance, productivity, and production. For instance, a business may integrate a Saas CRM with on premise sales systems to trigger ‘billing’ and ‘delivery’ request when an order is received. A CSP may connect a cloud based customer loyalty mobile application with on-premise ERP and CRM to make offers and process purchases in realtime.
Plenty of tools and methods to isolate integration between applications
There are literally hundreds of tools and services to link on-premise applications with SaaS services to connect processes, orchestrate end to end workflow, ensure data synchronisation, promote data consistency, standardise business rules, enforce security policies, and achieve a seamless business façade (in terms of UI) for users.
Most SaaS service providers offer a range of APIs and even offer PaaS services to extend their SaaS offerings (e.g. Salesforce, Service Now). Pure play integration vendors focus on solutions such as SOA middleware, ESB, EAI and other GUI based tools which enables developers to create interfaces and APIs to suit respective business need and use case.
For instance elastic.io, WSO2 and Cloud Elements are pretty decent option for SMB and smaller companies (based on product and price) looking to isolate integration layers that connect the various technology environment owned by the organisation. While companies such as Mulesoft, Infomatica and Snaplogic may carry a much mature and extensive range of offerings, suited for larger organisation with much complex IT environment.
What approach and which solution?
Ultimately, developers can choose between performing a point to point integration or establishing a middleware integration layer that promotes fluid linkages between systems without changes or minimal impact to source applications. The later being the best practise of the majority. The selection of methods and tools however depends on three critical factors as stated below:
1. The use case – what the business intend to achieve with the integration? For instance data consistency, data exchange, message exchange, end to end workflow or a common UI to access all business app.
2. Requirements – the relevant systems may run on different operating systems, databases, libraries, and written in different languages. The selected tools must be able to support and mediate these environments.
3. IT realestate – how big is your environment? How many business applications? Where they reside? In a very small setup, point to point integration may prove to be fast and economical solution. A rapidly growing environment on the contrary, can benefit from a middleware integration layer.
Sizing up the above can help determine the level of complexities and resources, when it comes to integrating requirements in hybrid environments, switching Saas providers, and ensuring business compliance.
Recommendations - don't overpower integration requirements
There is no single silver bullet for enterprise application integration challenges especially in our current state where public clouds are gauging more of our datacenter and on-premise systems. Selection of tools rely heavily on the specifics of the use case, requirements, dependencies, existing IT landscape and even business strategies to avoid vendor lock-in.
Nevertheless, good decisions can be made by zooming into the problem in hand with a bit of foresight. For example if connecting two applications, then making use of available APIs will be sufficient without the need of any high end integration middleware. But if the this scenario continues to involve other systems and applications, then an integration middleware or tool becomes mandatory. In intermediate situations, the business can also custom build integration interface on-premise or on a PaaS platform provided by cloud vendors.
A final reminder is that to meet integration requirements sufficiently without the need to overpower the integration layer for tasks that has not emerged in the integration roadmap, just yet. A common mistake many small companies make, is to purchase tools that are sold as future proof and broader in application at higher premium. These tools end up under utilised while businesses continue to pay a premium year after year. Tools change radically as new technologies enter our environment and should only be selected based on known business requirements.
A hybrid technology environment is inevitable for any business
Organisations depend on business applications to empower various capabilities to optimise operations, generate growth, enhance customer experience, and accelerate innovation. A typical enterprise technology architecture today delivers these
capabilities by cleverly balancing in-house solutions with a number of Saas services (e.g. Salesforce, Service Now, Box, etc). Though, most post millennial startups are built on cloud-first strategy, which means an internal datacenter does not emerge until business matures with a satisfactory level of solution adoption and customer base.
Business processes transcend cloud and non-cloud applications
In either scenario, businesses ends up with an enterprise technology environment that spreads across the in-house datacenter, hosted datacenters and various public clouds. Stringent industry compliance, data security, privacy, and call for other regulatory requirements will continue to push at least some parts of the business systems to on-premise deployment. This means critical business processes will continue to transcend several applications to invoke one another in completing workflows, share data, exchange messages, and push results to performance dashboards across a hybrid and multi-cloud environment.
Building integration between applications is necessary….
Linking and integrating applications residing in cloud and non-cloud environment is a common undertaking for businesses that depends on automated processes, mobility, data, and insightful predictions for superior performance, productivity, and production. For instance, a business may integrate a Saas CRM with on premise sales systems to trigger ‘billing’ and ‘delivery’ request when an order is received. A CSP may connect a cloud based customer loyalty mobile application with on-premise ERP and CRM to make offers and process purchases in realtime.
Plenty of tools and methods to isolate integration between applications
There are literally hundreds of tools and services to link on-premise applications with SaaS services to connect processes, orchestrate end to end workflow, ensure data synchronisation, promote data consistency, standardise business rules, enforce security policies, and achieve a seamless business façade (in terms of UI) for users.
Most SaaS service providers offer a range of APIs and even offer PaaS services to extend their SaaS offerings (e.g. Salesforce, Service Now). Pure play integration vendors focus on solutions such as SOA middleware, ESB, EAI and other GUI based tools which enables developers to create interfaces and APIs to suit respective business need and use case.
For instance elastic.io, WSO2 and Cloud Elements are pretty decent option for SMB and smaller companies (based on product and price) looking to isolate integration layers that connect the various technology environment owned by the organisation. While companies such as Mulesoft, Infomatica and Snaplogic may carry a much mature and extensive range of offerings, suited for larger organisation with much complex IT environment.
What approach and which solution?
Ultimately, developers can choose between performing a point to point integration or establishing a middleware integration layer that promotes fluid linkages between systems without changes or minimal impact to source applications. The later being the best practise of the majority. The selection of methods and tools however depends on three critical factors as stated below:
1. The use case – what the business intend to achieve with the integration? For instance data consistency, data exchange, message exchange, end to end workflow or a common UI to access all business app.
2. Requirements – the relevant systems may run on different operating systems, databases, libraries, and written in different languages. The selected tools must be able to support and mediate these environments.
3. IT realestate – how big is your environment? How many business applications? Where they reside? In a very small setup, point to point integration may prove to be fast and economical solution. A rapidly growing environment on the contrary, can benefit from a middleware integration layer.
Sizing up the above can help determine the level of complexities and resources, when it comes to integrating requirements in hybrid environments, switching Saas providers, and ensuring business compliance.
Recommendations - don't overpower integration requirements
There is no single silver bullet for enterprise application integration challenges especially in our current state where public clouds are gauging more of our datacenter and on-premise systems. Selection of tools rely heavily on the specifics of the use case, requirements, dependencies, existing IT landscape and even business strategies to avoid vendor lock-in.
Nevertheless, good decisions can be made by zooming into the problem in hand with a bit of foresight. For example if connecting two applications, then making use of available APIs will be sufficient without the need of any high end integration middleware. But if the this scenario continues to involve other systems and applications, then an integration middleware or tool becomes mandatory. In intermediate situations, the business can also custom build integration interface on-premise or on a PaaS platform provided by cloud vendors.
A final reminder is that to meet integration requirements sufficiently without the need to overpower the integration layer for tasks that has not emerged in the integration roadmap, just yet. A common mistake many small companies make, is to purchase tools that are sold as future proof and broader in application at higher premium. These tools end up under utilised while businesses continue to pay a premium year after year. Tools change radically as new technologies enter our environment and should only be selected based on known business requirements.
No comments:
Post a Comment