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
Admittedly I have a bit of ADD and get distracted easily. I love to read, but can't read poetry, or even classics, where I have to pay attention and remember the beginning of the sentence when I get to the end. It's why I studied math... I got to learn by doing, not by reading (pretty ironic, considering I don't actually do anything here at Progress!).
That said, can someone please read and translate Animesh's post for me?
He's got a great topic (even discounting the poor grammar), but I'm not sure what he's saying. So, I'm going to glam onto his topic selection with some of my own advice on tool selection. Here it is, ready???
To select the right SOA Management tool, figure out what you need the tool to accomplish, then DO A PROOF OF CONCEPT in your environment.
That's right. You heard me. I work for a vendor and I'm advocating a POC. Why would I do that? Two reasons...
Let's really get under the covers. Why are POC's hard? Well, there is a lot of pressure because everyone's watching, and there are a lot of unknowns. I can't tell you how many times customers drew their environment on the board, but when we installed we found something different.
In fact, a funny one was at a company I can't name (but which carries the same name as an outspoken mayor of a large city that I know well), when they were using JBOSS and swore to us they were using the JBOSS SOAP stack. We go in, install Actional, can see traffic coming into JBOSS, but not out. We lost a day troubleshooting, looked at some log files, and sure enough, they were using the JBOSS stack only on the way in... they were using the AXIS SOAP stack on the way out. Hadn't configured it because they said they weren't using it! This is pretty typical, and in fact, one of the easy ones to track down.
In any case, long story short... it's much easier to sell without doing a POC, but it's not in your best interest to buy without doing one! Besides, without a POC, how are you going to validate a vendor's claims to functionality, performance, and scalability? How are you going to figure out if you're "missing anything" from your evaluation?
If you're interested, drop me a line or, better yet, leave a comment, and perhaps I'll write about some interesting things to add to your POC evaluation criteria.
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.