Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
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
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
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
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
I participated in a SOA roundtable the other week. End-user organisations were present – in banking, automotive, logistics and other sectors. It was chaired by Butler Group, the analysts. The topic of the roundtable was how SOA technology and principles were being adopted in end-user organisations. The participants were invited to talk about what had worked and had not worked in their own organisations and how they saw their initiatives evolving. As usual many topics were covered including the usual yawn-inducing argument about whether “it’s about the technology” or “it’s about organisational change” (why can’t people just accept that it’s about both). Fortunately, this led us onto the much more interesting territory about how to incent members of the IT organisation to share the services they build. After all, two of the usual arguments trotted out to support SOA are reuse and the help SOA gives to cut across organisational silos to achieve greater efficiencies.
The issue that came across a number of times was that trying to encourage or force organisation silos to be generous with the services they produce was very difficult. There are a lot of good reasons behind this. An organisational silo is generally a (slightly pejorative) term for a business unit. Business units often have revenue and cost objectives. The function they perform may well be significantly different to that of another business unit – different products, customers and quite possibly a different culture (just think of the way the front-office and back-office staff think and behave in your own organisation). Business units want to be in control of their own destiny as much as possible. All of this puts barriers in the way of organisations sharing IT resources. A business unit, for example, may have put investment into giving partners better access to my product data with a view to helping them sell more and therefore increasing revenue. What's the inducement for the business unit to help its colleagues along the corridor? To be better corporate citizens? To show leadership in the use of IT? Neither of these sentiments is going to count for much when the numbers are down.
All the above arguments were cited by roundtable participants. Many had met such resistance in their own organisations, and some compelling suggestions arose. Let's say that enterprise SOA is equivalent to enterprise software-as-a-service (SaaS) (they’re pretty close). No SaaS vendor would ever put effort into creating a service that they couldn’t sell, whether on its own or part of a package. So organisations should create an environment in which there are financial incentives for services to succeed - a marketplace. Let services live or die by their success. Enable a successful service to become a revenue generator in its own right. Create joint ventures between corporate IT and business unit IT where both parties invest in services that can be used by more than a single business unit. If successful, corporate IT achieve their goals of SOA adoption - service reuse and cross-unit efficiency - and the business unit can earn more resources for future projects. Whether or not one measures success in monetary terms or some other unit is not really the issue. The point is that a team who builds something successful is rewarded and has more resources and more authority to build more.
SOA What? Others are thinking along the same lines. Joe McKendrick at ZDNet, for example, was arguing in a similar way a few months ago. We at Progress have been arguing that CIOs should pay attention to the "SOA tax" for some time. For organisations to bootstrap their SOA infrastructure initiatives, the overhead, or "tax", of creating more generally useful services should be borne by the organisation as a whole rather than a business unit.
There seems to me to be something in looking at things with an economic model in mind. A marketplace, with appropriate regulation in place, is often an elegant model to encourage certain behaviours. It would be fascinating to try such an approach for real. Perhaps you have already?
View all posts from Giles Nelson on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 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.