Integrated Infrastructure Blog

SOA? What do you call it?

Some of you may have noticed that we renamed our blog from SOA Infrastructure to Integrated Infrastructure. This came about when our product marketing team wanted to create a new “Open Integration” blog – same authors, same topics. Admittedly, I wasn’t a proponent of it because I wanted more blogging activity here, and I wanted to leverage the audience (and SEO truth be told) that we've built up over the past two years. So, I recommended that we re-brand it and we did.

I have no doubt that one of the reasons we wanted to move away from SOA was due to last January’s post by Ann Thomas Manes, SOA Is Dead; Long Live Services. Lots of SOA evangelists commented about the post, including our VP of Products Dan Foody who agreed with Anne’s perspective. Me? I personally think that SOA in itself is just a marketing term for a number of fairly distinct things, including enterprise integration.

With that said, this wouldn’t be a post by me if I didn’t offer or promote something, so I’m going to let you fill in the blanks.

Our new white paper The Foundation of _________ Quality is now available! What does _________ quality really mean? This white paper not only answers that question but it also examines the many facets of _________ quality. Read it and learn how you can ensure that your _________ initiative, such as Web 2.0, cloud computing, and BPM, can deliver the visibility and operational responsiveness that your enterprise demands. Get the white paper.

If you’d like to learn more about how your enterprise can achieve operational responsiveness, visit the Progress Software website.

SOA Infrastructure - Back to Future, No. 1

The New SOA Maturity Model

Originally introduced in 2005, the SOA Maturity Model white paper and the Quick Reference diagram were co-authored by business partners Systinet, Amberpoint, BearingPoint and Sonic Software. During a 2005 live webinar an audience poll noted that 40% of the webinar participants were “currently developing a SOA project,” and 37% noted that they would “begin a SOA project within the year”. That same year, Gartner, Inc. predicted that by 2008, "SOA will provide the basis for 80 percent of new development projects." (1) But over the past few years, there has been much skepticism about the ROI and business value of SOA. That doesn't mean that SOA is dead or that companies should abandon their SOA initiatives, it means that it might be worth stepping back to review your original goals and best practices, and move forward to seek the right solutions that will help streamline and cut costs.

The players have changed—Systinet was acquired by HP, Sonic Software was brought back under the Progress Software umbrella, and Progress Software acquired Actional whose product offerings align with Amberpoint—but the goals of any SOA technology provider or practitioner are the same; software reuse, agility and the improved alignment of business and IT. (I like Miko Matsumura’s 2005 post, The Rise of the Software Architect in an SOA World.)

With that, I’d like share the New SOA Maturity Model white paper and quick reference diagram which were updated in 2007. The tone may have changed slightly but it still provides a framework for discussion between IT and business users about the applicability and benefits of SOA in an organization across five levels of SOA maturity, including: Functionality, Cost Effectiveness, Responsiveness of Business and Collaborative Services, Transformation, and Optimization. The benefit of these resources also remains the same… to not only to provide a means for organizations to benchmark current implementations, but to offer a source of inspiration as IT leaders successfully advance the value of SOA within their organizations.

Enjoy!

White Paper: The New SOA Maturity Model >

Quick Reference: The New SOA Maturity Model >

1 Hayward, S. "Positions 2005: Service-Oriented Architecture Adds Flexibility to Business Processes," Gartner, Inc. Feb. 2005.

Five Dirty Little Secrets of Highly Available Integration Infrastructure

Even some of the world’s largest, most demanding companies suffer from a hardware, software, or network failure. Learn more about how a continuous availability solution will protect you from lost transactions, and guarantees in-order delivery without the cost and management complexity of the 3rd party hardware or software add-ons.

Register to download our new white paper, Five Dirty Little Secrets of Highly Available Integration Infrastructure. Topics presented in the white paper include:

• Recovery Time
• Data Corruption
• Hidden Cost and Complexity

... and those are just three secrets. Download the paper >

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

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).