Build, protect and deploy apps across any platform and mobile device
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
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-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
I don't know Tom, though I respect his accomplishments. I suspect he's a pretty smart guy, which would only mean that he'd be smart enough to have nothing to do with SOA, especially if he really were an astronaut stuck in space with a fraction of a chance to get back home.
Being a geek and a technical diver, one of my favorite movies/stories was the return of Apollo 13 after a fire and explosion crippled most of the ship. The part of the movie where they restarted things and new the exact amps required and the order in which to restart the equipment... man, that just rocked. And, I've been there myself, stuck inside a shipwreck at 200' searching for a missing diver and trying to optimize my bottom time knowing that once I ran out of gas, the situation would no longer be a search, but a recovery. In those situations, the difference between knowing and guesstimating is truly "mission" critical.
SOA What? Fortunately for us, and for Hollywood, SOA is not a life-or-death situation. I mean, those guys at NASA know their stuff, but most SOA Consultants can't tell the difference between JBOWS and SOA (here and here).
People wonder where to start when it comes to SOA Governance. There's all this talk about storing services in registries, or centralizing policies (that can't be shared by enforcement points anyways), or governing developer's activities... how about starting by trying to know what the damn thing is actually doing?
Imagine an SOA version of the movie Apollo 13. It would be a very short movie. Here's the script:
[Background: in 2007, The Bank, the largest bank in North America, did the equivalent of "walking on the moon" with 2007 earnings through the roof, while minimizing exposure to the worst credit crisis since the great depression.]
[Situation: One week into the new year, this darling of Wall Street has a catastrophic systems failure. Dan, on the trading floor has a single phone line to get advice, but physical help cannot reach the bank before it's too late. He's on his own, with only the advice of his trusty sidekick, David, who is in the command center in Houston.]
"[Background noise on the line] Hey David, it's Dan. I'm calling from The Bank. Trading floor's down! Power's out, and half our computers are fried. We need to bring up just the systems absolutely required to keep the bank from going under, but we need to bring up everything in sequence to maximize the use of power, messaging throughput, and CPU capacity that we have left in the computing grid, all within the context of our most important business processes. If we don't, the bank will go out of business and my bosses will shoot me, literally."
[David] "I'll tell your wife you loved her."
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.