Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop 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-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
The other day someone mentioned that people are afraid of SOA… well, BOO! I think that's just plain crazy. People should not be afraid of SOA.
On the other hand, I can certainly understand why they might be. SOA can result in distributed architectures, which can, in turn, result in implementation complexity. While SOA can deliver the benefit of agility, that doesn't necessarily mean it's easy to implement. We have all seen our share of projects fail… not just SOA projects. When you are trying to adopt a new technology, be it part of a SOA infrastructure project or not, lets face it, it just might fail.
I think one of the challenges people have is that they haven't taken a step back to really look at the big picture. What are the elements (e.g. technology) and the aspects (e.g. process) they are going to need to make their SOA implementation successful? One of the biggest things that people don't think about ahead of time is how they're going to deal with data. How are they going to manage the semantic alignment of the information (or data) that is flowing through their service-oriented architecture? How are they going to deal with the aspects of change.
We’ve been told that SOA provides an agile infrastructure that is able to accommodate change, but if the data infrastructure that is supporting that SOA isn't designed to accommodate change too, then the SOA project team is digging themselves a really big hole. And that, I'd say, may be the source of some of this fear.
SOA what? Never fear, semantic integration is here! Building SOA doesn’t need to be a frightening experience if you’ve taken the time to select the right SOA infrastructure tools and you’ve designed an architecture that is prepared for change – any change. Take time to think about the data, not just how it flows through your SOA, but how it is represented at each point within your SOA. Make sure that the data contained within each service or event that occurs is “common” to every other application and service it interacts with.
View all posts from ken rugg 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.