Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Host, deploy and scale Node.js, Java and .NET Core apps on premise or in the cloud
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built 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 © 2016, 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 or appropriate markings.