SOA governance

Taking the long view of SOA and cloud computing

By Jack Vaughan

What were the problems with Grid computing? Basically, it was too complicated and of too narrow use. But, let’s be frank and earnest, its biggest problem was that the term ‘Grid’ was too rigid and inflexible. That problem of Grid computing has been easily solved. Its name was changed to ‘cloud computing,’ a light and airy term with flexible connotation. Of course, I am kidding; cloud will not solve all the problems of Grid just by the change of a name. Continued »

Parasoft SOA package addresses business process/system integration testing

Application Life Cycle specialist Parasoft moved recently to expand coverage of critical aspects of complex transactions extending - using the company’s terms -  “through web interfaces, backend services, ESBs, databases, and everything in between.” The result is a considerable update to Parasoft’s SOA Quality Solution line. Continued »

Where SOA ends

By Ted Neward
In the rush to embrace new technologies and demonstrate “cutting-edge awareness”, companies (and individuals) sometimes create mountains out of molehills. Such was the case with XML a few years ago, relational databases before that, object- orientation, Java, graphical user interfaces…. in fact, it’s hard to name a recent technology trend that hasn’t spawned this kind of “rush to embrace” that leads to nonsensical claims, bizarre architectural suggestions, or blatant bald-faced attempts at capturing clueless consumer dollars.

One of those more recent trends has been the SOA bandwagon. Originally, though it’s hard to remember in the frenzy around SOA, the whole point of services, at least in their original form, was about designing distributed systems to be loosely-coupled and thus easier to interoperate with. Consider these original classic “four tenets of service-orientation”  http://msdn.microsoft.com/en-us/magazine…):

1) Boundaries are explicit
2) Services are autonomous
3) Services share schema and contract, not class
4) Service compatibility is determined based on policy

Nowhere in here do we find reference to SOA governance, SOA enablement, or any of the other elements that have been attached to the SOA name. In fact, it’s gotten to the point where CTOs and CEOs are talking about SOA as a general strategy for running their entire IT department.

I always thought CTOs and CEOs had something… I don’t know… *better* to do. For some reason, I always thought it was the job of the architect to think about these things, rather than let the CTO or CEO sit around and think about how their various software systems should be designed.

Don’t get me wrong: any organization that spends time thinking about how their various software systems are going to interact with one another is already a huge step above those that don’t. Too many CEOs and CTOs just assume that their back-end IT systems are capable of talking to anything at any time–in fact, one CTO once told me, to my face, “The only reason you’re saying it’s hard is so that you can charge me more money as a consultant. Well, I’m not buying it, and I’m not buying you.”

Said CTO went on to buy a “service-oriented” software package that he claimed would solve all their integration problems. The company went under about a year later. I won’t suggest it was anything to do with my inability to convince him that he really needed to invest more in thinking about his software infrastructure instead of just buying something “service-oriented”, but I can’t help but wonder….

So what are we to make of all the “service-oriented” bells and whistles currently being hung on every product, language, or release? In the end, the same thing we eventually made of objects, XML, Java, relational databases, XML, and every other technology that’s been put in front of us.

It’s useful, but it has an “end”. There is a point in the IT implementation, where the technology simply can’t help. Consider object-orientation, for example: back in the heyday of objects, various vendors, including one three-lettered vendor who was seriously looking to displace their rival in the operating system market, slapped “object-oriented” around everything, with the full expectation that not only customers *think* the product was better, but that the product really *would* be better. Another company, headed by a would-be jazz musician, tried the same thing for its office suite, and almost jazzed itself out of existence.

Moral of the story? We learned that objects are a useful way of structuring the way programmers think. Nothing more.

Another look at the “four tenets” makes it pretty clear that services aren’t much more than that, either–it’s a way of structuring the way programmers think, and has nothing to do with “governance” or “enablement”. Service-orientation describes an approach by which we create distributed systems, and that’s all.

When a CTO starts thinking about objects, or services, or other low-level activities, she may as well be conducting code reviews, too.

CTO-driven refactoring, anybody?

Ted Neward - blogger, teacher and speaker- is principal consultant, ThoughtWorks.

SOA Software Portfolio Manager builds on Logic Library purchase

SOA Software earlier this month entered the world of SOA Governance planning with SOA Software’s Portfolio Manager. The objective is to help companies plan and prioritize services creation. Continued »

Jeff Papows in at SOA governance house WebLayers

Industry veteran Jeff Papows will take the helm at WebLayers, the Cambridge, Mass.-based maker of SOA governance policy enforcement and automation software.The move comes at the same time the company announces it has secured a new $3-million round of equity funding from Ascent Venture Partners, Cedar Fund and Veritas Venture Partners. Continued »

New AmberPoint suite links to WCF and Dublin

Last month Microsoft re-confirmed aspects of its BizTalk server roadmap, which includes a specialized Windows ‘SOA’ server known as ‘Dublin.’ Included in the announcement was word of ESB and SOA guidance from the company that takes the form of patterns, or best practices, for customers going the SOA route.

A bit overlooked at the time was word that governance software maker AmberPoint had followed a demo at Microsoft’s November PDC expo with a formal announcement that it would extend its governance and management capabilities for the Microsoft platform.

Dublin represents Microsoft’s latest enhancements to its Windows Server application server, according to Ed Horst, Chief Marketing Officer, AmberPoint. “Like the latest version of WCF, Dublin is built from the ground up to support distributed composite applications,” Horst told SearchSOA.com in an e-mail message.

AmberPoint’s part is to govern the resulting composite applications to ensure they are compliant with management policies for such things as security and service levels, as well as to manage the transactions flowing across these federated systems, Horst said. New links with Microsoft’s WCF means developers won’t need to hand-code SOA management capabilities as they build WCF apps.

Policy and contract focused architecture

Perhaps architects are paying too much attention to the services when they work on service-oriented architecture implementation, writes Neil Ward-Dutton. He suggests that they might focus on “contract-and-policy-oriented architecture (CPOA).”

Continued »

Test SOA for the unexpected

Testing service-oriented architecture requires thinking outside the box to the point that your test cases hit an application with totally unexpected input, argues Thomas Fredell, CTO of IntraLinks. Continued »

HP builds ‘culture of governance’ for SOA

HP solidifies leadership in SOA governance with Systinet 3.0, which now covers services lifecycle, business process, and IT service management, writes analyst Dana Gardner in his blog this week.

“The newest market leading Systinet UDDI registry forms the cockpit for managing not only services, but with the newly added Business Process Execution Language (BPEL) support, takes the helm for business processes, too,” Gardner writes. “HP plans to further push the envelope on a master management value even further into IT operations and IT Service Management, as well as a PPM role with the registry.”

The addition of a configuration management database (CMDB) sets the stage for a wider “culture of governance” to emerge in enterprises, Kelly Emo, SOA product marketing manager at HP Software, tells Gardner. 

Gardner also points to a comprehensive assessment of HP’s governance products and strategies by fellow analyst Brad Shimmin posted on the Current Analysis Website.

In SOA provides a test for QA, HP finds, SearchSOA covered HPs expansion of governance to cover quality assurance. And in an earlier article, HP integrates design and runtime SOA governance, SearchSOA covered the design time / runtime integration in Systinet.

So how SOA are ESBs?

Last week we at SearchSOA.com ran a story about how ESBs aren’t as interoperable as users might expect them to be. The story prompted a response from StrikeIron CEO Dave Linthicum, basically wondering if the bigger problem here is bad architecture. He wrote:

Call me crazy, but would it not make more sense to have a centralized plan as to what the SOA should be, based on the requirements of the business, versus people dashing out and shelling out the dollars for an ESB for some one-off tactical reason, or more likely just acting out of reaction to the hype? Now, you’re left with a dysfunctional mess that’s not easily corrected, and clearly costly.

Joe McKendrick over at ZDNet picked up on that and put together a brief history of ESB criticism. Linthicum’s blog entry also drew a lot fire down in its comments section (be sure to check them out as iTKO’s John Michelsen, the interviewee in our original article, makes a few points on the unavoidable nature of multiple ESBs). The response in fact spurred Linthicum to write a follow up entry addressing some of the critics of his first entry. After pointing out many of the dysfunctional things he’s heard over the years, he wrote:

[W]hat I’m asserting is that there has to be some architecture forethought behind dragging any technology into the enterprise, and I suspect that’s not occurring.

To be fair, he doesn’t suspect it. He knows that’s the case. We all know that’s the case. As Software AG’s Miko Matsumura put it in another article we ran last week, “People are addicted to messed up IT.”

Anyway, Linthicum finished his latest post with a request:

So, in the spirit of having an open mind, send me your reasons for leveraging multiple ESBs, and why that’s a good approach for your enterprise architecture. Also, while you’re at it, make sure to send me the reasons you’re using an ESB to begin with: your requirements and the reasoning behind the solution. I won’t post them unless you say it’s okay.

It’s an interesting topic, so make sure to send Dave your reasons, if you’ve got some. For my part, I know a lot of people who despise ESBs. During one interview I did with an analyst back in 2005, he referred to ESBs at “methadone.” This was actually praise for the ESB, making the case that it was better than EAI. Yet I know others who just as adamantly argue that at some point you’ve got to implement a service or pull together applications after a corporate merger, and at that point you will find yourself wanting an ESB.

Earlier this year, I actually did a podcast with Mulesource CEO Dave Rosenberg about why he maintains that enterprises will need to accommodate multiple ESBs inside their SOAs.

I would argue the larger point here, and this is where Michelsen was focused in the original article, is that multiple ESBs are a fact of life. No matter if it may be sub-optimal in terms of architecture, a good architecture should be able to tackle this kind of problem, or at least good governance should help ameliorate it. Mergers and acquisitions will happen. You will need to combine services with outside entities. Different divisions will buy disparate products, even if they shouldn’t. This doesn’t even touch on technology creep from the open source arena.

So it’s really two questions. The first is do you even need one ESB let alone many? It’s a fair question and one that every end user ought to put serious thought into answering. The second is, how do you deal with multiple ESBs in your infrastructure? Because no matter how you answer the first question, you will need to manage this situation for at least the near term.