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 was at Software AG's SOA Governance Summit last week and got a chance to see Gartner analyst Frank Kenney give a presentation - on SOA Governance of course. As always, Frank did a great job - but there is one area that I feel he got wrong.
Frank said that you don't need governance products until you have more than 10-12 services (up to that point Excel will do fine to track things). Now, Frank was partly doing this because he wanted to show he was independent of the vendor sponsoring the event - so whether he believes this or not, I don't know.
But, here's an example to show why this isn't true: Let's say you have just one service but that service has 1000 different applications consuming it. Do you think can get by with Excel? Do you think Excel will help ensure you meet the service levels of each of your 1000 consumers? Of course not.
In the end, the number of services is irrelevant to whether you need SOA governance or not. What really matters is the number of relationships. Having 1 service consumed 1000 times is just as complex as having 1000 services each consumed once. But, it's definitely a different kind of complexity and so how you govern these two scenarios is very different (with 1000 services you need design time governance first but with 1000 consumers you need runtime governance first).
If you're with me so far, let's bring this to the next level...
Let's say you have just one service, and that service has only 5 consumers. Since it's well below the 10-12 threshold Frank gave, do you need governance? Don't answer "no" so fast... In reality it depends on how important those consumers are to your business. Are they mission critical applications? Do they require certain stability, uptime, or performance levels? If you answered "yes" to any of these questions, then the answer is "yes", you need governance infrastructure around them. You need governance to ensure you meet the expectations of your consumers.
OK, onto my last point. Let's say you have just one service, and you believe there are only 5 consumers, none of which are business critical. Do you need governance now? Here's the problem: without governance, how do you know there are only 5 consumers? We had a customer that thought they had only 5 consumers but when we plugged into their service, they found out (to their surprise) there were really 34 different consumers - some of which turned out to be extremely mission critical applications. So, even if you think you're below the threshold for needing governance are you really sure?
Last month I recorded a short SOA podcast about this topic. Take a little over 5 minutes to hear more about my thoughts and field observations.
For more podcasts, subscribe to our SOA Infrastructure iTunes podcast channel.
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 © 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.