Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Host, deploy and scale Node.js, Java and .NET Core apps on premise or in the cloud
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built in the cloud
David Linthicum touched upon a very prevalent problem of technology not living up to its expectations set during the hype curve! He says, "With cloud computing, SOA, or whatever we come up with next, we still need to figure out core issues within our enterprises that no set of technologies or emerging trends can solve." In the service-oriented architecture (SOA) case, we all know that the widely professed use cases of systems "automatically" looking up service registries on the web/intranet, locating the required services, getting the interfaces, picking the right one, and actually making a service request is just a pipe dream! The reality is nowhere close! It is difficult to even find enterprise wide service buses, much less the dynamic on-the-fly service-look up-and-use!
I recently came across a scenario where even a large international bank has SOA infrastructure solving regional problems - and not necessarily as a corporate backbone! I was at this tech discussion with the regional technology head of a large bank, exploring how Apama (Progress' Complex Event Processing (CEP) engine) fits into a biz requirement they have. Specifically, he wanted to understand how Apama works and how it is a good fit for their biz problem. They were trying to build a business performance tracking solution (a la GRC) that involves tracking key biz activities, ensure due process is followed, and then proactively detect potential service-level agreement (SLA) failures so they can be averted. A classic use case for Apama!
Now, when we started to see where the business events information came from and how they could be "wired" to emit the required events into Apama, we suggested that they could just tie into their enterprise service bus (ESB)we knew they had standardized on one. As we dwell further, it turns out they are using an ESB to solve departmental integration requirements, and there are multiple instances and no central ESB that can help integrate these "departmental integrations".
Now that was a revelation. (I am not complaining because suddenly our opportunity now included Sonic ESB, along with Apama). While we have been reading (and I myself have been blogging and talking) about how SOA failed to live up to its expectations, I still expected at least a large number of banks to have standardized backbones. But not to be! I guess, like in many large enterprises, even here SOA adoption has started purely to solve departmental integration problemsmore as localized islands of "integration". And its nothing like the enterprise-wide integration platforms or service bus that we have so much noise about since 2004. This reality check at this bank was a clear validation of this failure! It seemed clear that the technology promise was something, and the actual on the ground realization was something totally different!
Come to think of it, it does seem like a good model for use cases such as BAM or GRC - to have a complete platform that in addition to the CEP engine and dashboard, it also includes a "local/embedded" ESB. Now, embedded is not about being lightweight or smallas it is about being available out of the box when you get the platform. In this case, the ESB is available along with CEP, well integrated - so no surprises as you start using it. And the purpose is to "wire" exchanges from existing ESBs or applications in the enterprise to the CEP environment.
Not a bad idea at all! Embedded ESBs!
View all posts from Ramesh Loganathan on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.