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
A complete cloud platform for an app or your entire digital business
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
I've been following a series of posts, most recently one by Todd Biske from Momentum SI, discussing what the phrase, "It's not about the technology," means in the context of SOA, since so many people use it.
The discussion has centered on whether this means "it's not about the technology alone" or whether it means "the technology doesn't matter" (i.e. you can architect without thinking about implementation).
Frankly, though, when I talk with people about SOA infrastructure, neither of these explanations fits the bill. What I'm told is that "It's not about the technology... it's about the organizational change" -- that is, the hardest thing about succeeding with SOA isn't the technology (not even close), it's about the organizational transition that's required to truly embrace SOA.
Said another way, even if you get the technology perfect, if the organization isn't structured to be successful with SOA your SOA initiative will fail. On the other hand, if you get the organization changes right, any technology failures will only be transient -- the organization will rebound and adapt.
This, of course, immediately leads to the next question: What organizational transition is needed to be successful? Here's my take on it...
Many organizations are treating building SOA services the same way they treated building applications: As a product delivery. That is, you roll out a service, and at a later date (6, 9, 12 months later) you roll out the next version, and the software development lifecycle continues.
These types of organizations haven't adopted SOA as core to their culture, and so their SOA initiative will either fail completely or hit an early "glass ceiling" (where they barely achieve a small fraction of the benefit they assumed). Why? The issue is that these organizations are getting confused about what the "S" in SOA means. It doesn't mean "service" as in "SOAP interface" or "web service" or "technical service"; it means "service" as in "customer service" or "service industry" or "software as a service".
If you only take away one thing from this posting, it should be that in SOA you don't build services, you deliver services.
This is the difference between Siebel and salesforce.com. Product delivery is very different from service delivery. To truly achieve the benefits of SOA requires that an IT organization change its culture from a construction culture to a delivery culture. Unfortunately IT organizations are used to building applications for the business, shipping them, and going on to the next (typically) unrelated thing to build. This is, no doubt, a hard change and not every organization is going to be able to make the change.
The organizations that have been first to break through the SOA glass ceiling are ones that already have a service delivery culture; whether it's information service providers like Standard & Poors, or travel service provides like Starwood Hotels they have one thing in common - delivering services is in their blood and so more easily filters down into IT.
SOA What? The nature of a service delivery culture has many side effects that do impact IT and your technology choices of course. For example, how do you measure the value you deliver to others (by customer revenue impacted, by number of transactions, by number of users, etc.), how do you ensure you are providing the quality of service they expect (availability, performance, etc.) and how do they pay you for it (e.g. cross-charges, transfer payments, etc.) -- but your technology choices here will be irrelevant if you don't get the organizational transition moving along the right path.
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.