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
Build, protect and deploy apps across any platform and mobile device
Automate decision processes with a no-code business rules engine
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
Have you ever related to a Dilbert so much, you just wish you could open it in an editor, change a character's name, post it over the water cooler, and wait for said person to wander by?
I've been struggling with messaging around registries, and their impact on SOA. I'm frustrated. And, it's your fault.
What is it about registries that everyone thinks is a panacea for all things SOA?
Not to pick on Joe McKendrick in particular, but his is the most recent reference I've come across to this disturbing belief (http://blogs.zdnet.com/service-oriented/?p=934). He writes, in the third paragraph down, "various pieces needed to make up SOA: governance and registries..."
So many cliches come to mind... "garbage in, garbage out", "it must be true, that's how it was designed to work", and, my personal favorite, "we know what's happening in our environment".
What makes creating a fancy database for service elements of the SOA any better at governing a SOA than using a spreadsheet and some procedural checkpoints as services are migrated from dev to UAT to production? Do you think we (the IT world in general) plan the problems that occur? They occur because we don't know they're going to happen. How does putting the things we know about in a registry prevent problems we don't know about from biting us later on?
Not that registries don't have their place (that's my placating statement for our registry partners), I just don't understand how/why they've become the cornerstone of SOA implementations.
That's why I need to thank Scott.
In his August 8th Dilbert, the Pointy-Haired Boss is chewing out Asok. PHB has decided to "manage by spreadsheet," and the spreadsheet tells him that Asok has been doing a bad job. Asok responds with the two key points I'd been searching for in my quest to explain why "governance by registries" is a faulty strategy for implementing SOA:
SOA What? I know you're probably wondering what this has to do with you and your SOA strategy...
Let me tell you two of the problems Asok has reminded me of that exist in "registry first" SOA implementations:
I know, as many of you read this you'll shake your heads and express sympathy for those companies without the rigid control processes in place at your company. It must be chaos at those organizations. But you're safe. Your IT policies hold back the chaos that threatens to bring your SOA infrastructures crashing down around your heads.
In my experience, it's exactly those who rest in the comfort of their policies that should fear registry most.
Years ago, a cornerstone of process re-engineering was to enter data only once, at the point of first contact. That simple philosophy would capture all data, correctly and consistently, and with the least duplication of effort by all involved. Even better was when the data could be captured automatically via bar-code reader or scanner.
Have we forgotten this simple nugget when planning SOA?
Why not a SOA Management solution that does the same? Automatically collecting information on first use?
Put it in a registry, put it in a spreadsheet, or just keep a pretty-picture on the screen. Who cares? As long as it accurately reflects reality, we can spend time on really important things... like figuring out the best way to edit co-workers' and bosses' names into Dilbert strips.
View all posts from david bressler 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.