Build, protect and deploy apps across any platform and mobile device
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
John Radko of GXS had an interesting blog entry about SOA versus ESB - Conflict or Collaboration where he talks about whether ESB and SOA should always be put together. Since SOA is an architecture but an ESB is a product, deciding whether your architecture should depend on a specific product is an important question to ask yourself.
The interesting thing about this question is that answering it has little to do with technology. In fact, the right approach has to do with the existing power structure of your organization (whether "organization" for you means project, division, or even enterprise).
In a world where one IT group (in reality, not in theory) can dictate the technology standards for the entire organization, choosing a specific product -- an ESB -- as a core SOA infrastructure for the organization makes sense. In this environment the IT group has power to dictate the standard that everyone else must use, and you can easily deploy a single technology everywhere - across the enterprise. Asymmetrical organizational power leads to a symmetric technology deployment.
On the other hand, if you work in a world where different groups within the organization are equally powerful (or are even more powerful than the central IT group), then you'll naturally end up with a model where each group chooses their own infrastructure - regardless of what "central IT" believes is best. Symmetric organizational power leads to asymmetric technology deployment.
Of course, in a world of equal organizational power, two groups can work together to form an agreement. That agreement typically codifies, among other things, a set of common policies and standards by which the groups will communicate. This is one of the ways SOA management products are deployed -- to codify these policies and to act as a "gateway" between the groups (decouping each group from the technology choices of the others).
Of course, no enterprise has just one level in the organization. Within one division, decisions may be centralized (i.e. there's asymmetric power within the division -- someone can dictate the rules), which means that use of an ESB within that division makes a lot of sense. However, across divisions power may be symmetric (with on one division being able to dicate what another does). In this case you would think of deploying SOA management at the boundaries between divisions to decouple them from one another. So, in this example, you have a mix of both approaches - perhaps an ESB within the divisions and SOA management at the boundaries across divisions.
SOA What? In your organization, is power is distributed symmetrically or asymmetrically? Remember to ask and answer this question before you decide on your SOA architecture -- SOA won't be able to change the balance of power within your organization, but its success depends on understanding where the power lies.
View all posts from dan foody on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017 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 for appropriate markings.