Evaluating software for managing your distributed applications? Then this is a must read.

Evaluating software for managing your distributed applications? Then this is a must read.

Posted on December 05, 2008 0 Comments

At least, I think it is. Just because I'm the author of the recently released Software Buyer's Guide, doesn't mean my opinion on its relevance is biased, really. If you follow me on Twitter, you've already been notified of the Buyer's Guide. And, as I said before, if you join the conversation and direct message me on Twitter, I'll send you a copy without requiring you to register.

Personally, I get quite frustrated by the vendor-initiated confusion around the problem that Progress® Actional® solves. It's not really a management problem. I mean, you can say a pilot uses his instrument console to manage his airplane, but what he's really doing is flying the beast. Well, Actional and other competitive solutions are the equivalent to the pilot's instrument console. And, the pilot is... Well, I think the pilot is anyone who drives business and the technology on which it runs. But, the right persona is a bit more organization-structure dependent and a bit less obvious than the "pilot" analogy.

While this guide talks explicitly about managing distributed/composite applications in a mission critical environment, it was written in a way that starts by proposing a framework for evaluating enterprise class software. I define enterprise class applications as being:

  • Scalable
  • Performant
  • Resilient

Software that does not have the right enterprise architecture, should be disqualified before a feature-by-feature evaluation begins. I realize that's a strong statement, but I believe:

Architecture deficiencies are mortal. Feature omissions are easily corrected.

I think this simple rule is often overlooked by the whiz-bang of a pretty UI, or the easy sale-ability of a specific feature that touches the purchaser's hot button.

The guide goes on to discuss a few areas that are often part of "managing" a distributed application and tests for each that can be used in a POC. I've said it before, and I'll say it again... DO A PROOF OF CONCEPT BEFORE BUYING SOFTWARE. I've worked in the enterprise "plumbing" business since 1995 and the only consistency is that vendors try to avoid POCs. If we're trying to avoid them, you should be trying to do them. And, when you do them, take the time to do them properly. Little upsets me more than doing something so you can check it off a list somewhere. </rant>

We've also put out a brief teaser release highlighting the buyers guide. You can see it on our site, or over at SOA World Magazine (thanks to BusinessWire).

david bressler

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.


Comments are disabled in preview mode.

Sitefinity Training and Certification Now Available.

Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.

Learn More
Latest Stories
in Your Inbox

Subscribe to get all the news, info and tutorials you need to build better business apps and sites

Loading animation