When we spoke with MIT Systems Researcher Jeanne Ross, she pointed to Boston’s Big Dig as an archetypal muffed project.

This was a massive federal project to replace Boston’s Central Artery, which added a tunnel to the airport and replaced an elevated highway with a depressed one. It started in earnest in the late 1980s or early 1990s, depending on how you estimate “earnest.” Originally set for 1998 completion and budgeted at $2.8 billion, the eventual cost was over $15 billion (by some estimates, the final tag was $22 billion) and its completion occurred late in 2007.

From Ross’s point of view, The Big Dig was an example of classic underestimation of the kind that can happen in software development. How much are we spending on an existing system while we are laboriously rebuilding it? Some people don’t deal with those figures. Here is Ross’s take:

I highlight the Big Dig here in Boston because the thing cost over $15 billion dollars. The idea was: “We’re going to take this highway that goes over the city, and we’re going to put it under the city.” Brilliant idea! The main thing they underestimated was what happens to [existing systems] while you are building the new capability. They were just trying all kinds of new technologies and approaches to doing things, and they really had no way of estimating how long it would take or how much it would cost.

The lesson in it for architects in IT is that at least a third of the $15 billion was spent on just making it possible to continue to do business, for cars to continue to be able to navigate their way to the airport, to the office, wherever it is they’re trying to get to, even while this major transformation was taking place downtown. So, a third of the money is not going towards the new capability, it’s going towards being able to continue to exist while you’re building the capability. I think that’s a thing as a rule that architects would like to shy away from. It feels like such a bad use of your money.

To read the rest of Ross on business capabilities, go to “MIT’s Ross says exploiting IT business capabilities is next EA step.”  Ross, director and principal research scientist at the Center for Information Systems Research (CISR) at the MIT Sloan School of Management, spoke with us shortly after speaking at The Open Group Conference in San Francisco. – Jack Vaughan

In ”Learning about business architecture the hard way,” he takes a look at the role of business architecture in creating failures or, more positively, in promoting successful SOAs. Without business architecture, the best we may hope for is SOA silos, he writes. Business value has always been an area of discussion for the thoughtful IT leader, but business capabilities and business architectures seem to be discussed more and more these days by SOA thought leaders. What do you think? Let us know.

* Since SOA’s near-death experience a few years ago, it has gradually become part of mainstream development – but not to the extent that people don’t still argue first principles.  What is a service? More to the point – what is a good service boundary?  People are still working on that.

For some interesting discussion on boundaries and software architecture see Richard Veryard’s ”On Architecture” blog item on service boundaries in SOA and  Udi Dahan’s ”Software Simplist” musing entitled ”Service Boundaries Aren’t Process Boundaries.” This notion of boundaries is somewhat exacerbated as SOA’s and services’ soul mates BPM and processes come into play. How processes and services map or do not map is still a matter of conjecture. And yet another paradigm is heard from in the form of business capabilities.

* What makes for a good ESB? The formidable Service-Orientated Architecture discussion group has picked up that discussion of late. We take note of expert Steve Jones’ posting in which he says the ESB should do: one, security mediation; two, data transformation; and, three, end-point routing. ”And that is about it,” he continues. ”ESBs that contain functionality become a bottle neck and a massive challenge.”

* The job title “SOA Specialist” has been popping up on the Internet – there is even a small-as-yet LinkedIn Interest Group dedicated to the topic. This group and others are among those discussing SOA specialist certification. As with software engineering certification, there are differences of opinion over whether this is either a good thing or even doable.

Ed. Note: Speaking of SOA certification, one of the pioneers of SOA training, Zap Think, has become a wholly owned subsidiary of Federal and defense consultancy Dovèl Technologies. Longtime readers of SearchSOA.com know the ”Zap Think Boys” – Ronald Schmelzer and Jason Bloomberg – as two of those who helped ”write the original book” on SOA. Wishing them well.

These dual sides of integration – one in which SOA is prominent, the other in which SOA may be incidental or less-than-incidental  – each are represented by their own Gartner Magic Quadrants. These Gartner quadrants are now being formed around project types, as well as product types.

The Gartner Magic Quadrant Gartner rates technology vendors on completeness of vision and ability to execute, and is much watched in software circles. It uses quadrants to graphically represent leaders in a specific niche and time frame.

Gartner has a Magic Quadrant for Application Infrastructure for Systematic SOA-Style Application Projects and a Magic Quadrant for Application Infrastructure for Systematic Application Integration Projects. The difference is a difference in focus. SOA is a fundamentally different view.

“What SOA has done is it has changed the focus. Systems have to work together, but how they are tied together has more to do with how the business uses them together as a business capability,” said Jignesh Shah, VP of Business Infrastructure Products and Solutions, Software AG. When you start creating true software services, you can tie them together in more efficient ways, Shah said.

He noted that Software AG appears as a leader in both the Magic Quadrant for Application Infrastructure for Systematic SOA-Style Application Projects and a Magic Quadrant for Application Infrastructure for Systematic Application Integration Projects.

The difference in focus is often manifested in an interest in governance. Shah insisted SOA governance remains the big SOA differentiator.

“If you look at [the two styles of integration Gartner describes] from a technical point of view, the big difference is governance,” said Shah. “Because you are trying to create capabilities that span multiple applications and teams, and which are repeatable, governance becomes important.” Expect continued aggressive investment in SOA capabilities at Software AG, as well as additional attention to Master Data Management (MDM) for SOA and operational BI.