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
Anyone ever see David Letterman's stupid pet tricks? I think we should have a tech show called stupid IT tricks. I recently heard that one CIO's strategy for meeting user requirements was to forbid users to submit feature requests. Software would be installed, and the way it works out of the box is what the users get. His policy of "no more user requirements" ensures a 100% success rate of meeting his IT policy. I applaud his brilliance.
As silly as that sounds, check these two policies out...
These sound like pretty good policies, right? The former benefits everyone by preventing sick people from getting others sick. The latter, well, it saves lives.
But let's take a closer look... This first policy is totally unenforceable and really doesn't reflect user's realities. Whoever thought of this "marketing campaign" did nothing but waste tax-payer dollars. Most people would love to not come into work when they're sick, but that's just not a reality. If we wanted that policy to work, we'd have to make a realistic alternative for sick people. After all, what's their motivation for following a policy if it's not enforceable, especically when they may not have any direct benefit from following the policy?
On the subject of enforcement, let's look at the second policy. Clearly, this is an enforceable policy. Why then do people continue to drink and drive? There are realistic alternatives to drinking an driving, and would-be drunk drivers benefit directly. A sick person is already sick so not riding the subway doesn't help them, but a drunk who doesn't get behind the wheel is stopped from hurting themselves, or worse, others.
Unfortunately, as Mayor Rudy used to say, "common sense is, unfortunately, not all that common." I think, in part, it's because enforcement is subject to "user interpretation."
But apparently, people are more worried about being embarrassed by having their names/photos published if they are caught drunk driving, than they are about hurting someone, losing their license, or jail time. A new policy started on Memorial Day in Long Island that stated that people arrested with blood alcohol levels over the limit will have their names and photos published on Monday mornings. It's an effective enforcement procedure but has been called "controversial" - probably because it's a government program that works.
SOA What? I commend the person at the MTA who is trying to instill manners on subway riders (though I still think that they should be fired for wasting money/time). But it's a noble cause doomed to fail. And, for those officials on LI willing to risk controversy and continue to publish drunk's names and photos, you set a good example for those of us trying to police our SOA infrastructure.
What can we learn here? Again, it's about the carrot and the stick. Both need to be in place organizationally in order to make policing the SOA practical. You've heard it before, SOA (and SOA Governance) is as much about people and process as it is about technology.
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.