Wednesday, September 12, 2007

More obvious misgivings about Microsoft and SOA

InfoWorld blogger and MuleSource CEO Dave Rosenberg has some thoughts on Microsoft and SOA in light of, and in advance of, the recent spate of BizTalk announcements and partnerships. Like myself, he takes exception to Microsoft's claims of SOA support and affinity.

Here are some excerpts from an interview Rosenberg did with ITBusinessEdge:
Question: So. You're among those who feel Microsoft doesn't "get" SOA? Why do you say so? Do you think they don't get it -- or don't want to get it?

Rosenberg: I would say that not only does Microsoft not get SOA, they purposely are trying to usurp the whole concept for their nefarious doings. Microsoft offers nothing in the way of architectural development tools or infrastructure that supports the ideas behind an SOA. The Microsoft architecture of .NET is not designed to be service-enabled and when you try to service-enabled it yourself -- when you try to build the infrastructure so you can take advantage of reuse, you find yourself in a very customized system having defeated the purpose.

If you look at Microsoft infrastructure, it's all about trying to lock people into their hegemony and SOA is all about giving control to the user.

Question: Did you see Microsoft's 100-something page thesis on SOA, titled "SOA in the Real World?"

Rosenberg: I can't tell you I've sit there and poured over every word. It's not unlike their "Get the Facts" anti-Linux campaign -- it's simultaneously interesting and full of crap at the same time.

What's interesting to me about Microsoft's approach is the obvious thing to do with SOA is to say, "Of course we have a strategy -- here's what you do now and here's what we'll do in the future." What should've been very easy for them to say, "Yes, we'll be a part of this and we want to start to think about our way of doing [SOA]" -- that would be acceptable. Instead they take this bizarre approach.

There's no clear answer from Microsoft on what their vision for SOA is or how their products or things you'd buy from them would participate in a SOA. For that matter, there's nothing from Microsoft that would say to someone, "I should use these products for my SOA."

All of the sudden .NET went from being a language, to an application framework, to being a "Windows platform" again.

Developers are quick to shun things that they don't trust and I think Microsoft sets the tone for how their development community thinks about larger scale concepts and so far they've succeeded in making SOA confusing.

Question: So, is Microsoft's talk about SOA a barrier to its acceptance among developers?

Rosenberg: From what I can tell, they're not doing themselves any favors. The whole sort of wait-and-see approach is not great. What's interesting is developers do eat that Microsoft dogfood pretty fiercely. They wait for Microsoft before they make choices.

It's a challenge for architects in terms of being flexible and having agility in their work. If you look at IBM or BEA, it's very clear what their vision of SOA is. With Microsoft it's just not clear.

I think some of that is related to the fact that .NET was not built to be a SOA or a services platform. They don't want a heterogeneous environment, they want the entire Microsoft suite everywhere. For instance, a couple of months ago they were calling it service-oriented infrastructure. What is the rationale with not going with the industry standard terms?

Before I started this company [MuleSource], I was the CIO of financial services firm. Initially we had an all LAMP and Java infrastructure. Prior to my getting there, they outsourced the development of a .NET application. We went from having a highly scalable, flexible infrastructure that was able to consume data and services across the enterprise and added a .NET application into the infrastructure -- it was a complete and utter silo.

It was built around this framework that was not meant to go in a services direction, and we basically had to adjust everything else in the enterprise for this one application that couldn't align itself with the rest of the business.

And that is the unfortunate side of what .NET has done to development. Conceptually, Java guys are more likely to understand the SOA model than the .NET guys are -- developers are not trained to think about other applications in .NET. They aren't trained to think about wanting to consume or expose a service to another application. That has so far been a barrier to using .NET as a platform to do SOA.

For better or worse, this development style is what .NET developers live and breathe. If Microsoft doesn't have a component, it doesn't exist. But in the real world, you still need to solve that problem.

How can a company that in-the-know be so clueless about as an important concept as this? This is the world's largest technology company and it's proven to be completely impotent and useless with SOA so far.

Question: So, do you think this is a sort of marketing ploy by Microsoft or just because they didn't anticipate that SOA would take off?

Rosenberg: I think it's a bit of both. What I'd tell you is that they should embrace SOA. Open source, you can see why they don't embrace it -- but SOA, they should say it's awesome and encourage it. It doesn't make a lot of sense.

In the real world, we see people who have similar situations to the one I described, with one or two .NET applications that they want to get on the [enterprise service bus (ESB)]. Does Microsoft give you an obvious answer? Kind of, but not really.
My take is that inside of Microsoft its aggressor A-types are all about dissing SOA and promoting .NET ad nauseam. At the same time the Microserfs and developers must understand the inevitability of SOA for at last a portion of the most advanced and innovative enterprises' and service providers' architectures.

And so, as the world turns toward SOA, Microsoft will fight quietly inside of itself about what it really is as a company -- a partner to its customers, or a parasite on the hide of productivity.

Ultimately the marketplace will determine Microsoft's end-game role. If there's an advantage to SOA for those that embrace it broadly and effectively -- and I believe without question that there is -- then there will be a penalty for those that do not embrace SOA principles. This will become apparent first as SaaS and hosted, on-demand applications providers.

For those IT shops that throw their infrastructure fates to Microsoft's software development and business development competencies (where the latter is the strength), they may encounter cost and agility disadvantages.

If I and Dave Rosenberg are wrong on SOA benefits and n Microsoft's lack of general support for SOA, then the more purely .NET shops should demonstrate market strength via lower TCO and greater business agility over time. The .NET-based businesses should play better amid complex, global business ecologies, and be able to take advantage of mixed sourcing across a waterfront of available services.

Under the dictates of comparative advantage, .NET and its Microsoft-oriented progeny should not create greater value and higher productivity for its customers than more general alternatives, such as open SOA. A choice of the best service for the job will dominate a choice over only the .NET service available.

I'll be waiting and watching, though my risk is an observer is much lower than the architects placing their bets in the coming years. The ante, incidentally, is the very survival of their companies as we enter an "flattened world" era of increased globalization, lower barriers to entry, open trade, and lightening fast market disrupters.

For those with an inclination to hedging bets -- banking on general SOA while supporting service-enabled .NET might be more secure and auspicious than banking on .NET while trying to support SOA objectives from a comparative disadvantage.

Tuesday, September 11, 2007

BEA, Adobe flex their muscles in pushing toward RIAs on the enterprise desktop

BEA Systems Inc. and Adobe Systems Inc. are teaming up to give enterprise customers a design environment for rich Internet application (RIA) development. The two companies announced Tuesday that BEA will bundle Adobe's Flex Builder 2 software with BEA Workshop Studio. This move will let developers build cross-platform RIAs that integrate with services oriented architecture (SOA) and Web 2.0 infrastructures for enterprise mashups.

Under Tuesday's agreement, announced at BEAWorld in San Francisco, the BEA-Adobe bundle will include Flex Builder 2, as well as the Adobe Flex SDK, which operates under the Mozilla Public License.

In April, I predicted that Flex -- especially operating under open source -- could become an industry standard for RIAs, and this latest announcement might be an indication that prediction is coming true. What I said back then was:

"With Adobe bringing its Flex and possibly Flash into open source — and perhaps creating unassailable de facto global standards as well — then the Web 2.0 red shift to RIAs and away from other models could be complete."

Using the Adobe Flash Player, which is nearly ubiquitous in home user applications, developers will be able to build interactive data dashboards, customer and employee self-service applications, and B2B applications that will be agnostic as far as platforms or operating systems.

The applications created with Flex can then be integrated with other BEA products -- including those from the WebLogic and AquaLogic families -- and to deploy the applications with Adobe's Intergated Runtime, a cross-operating system app runtime that allows developers to extend RIAs to the desktop.

As part of the agreement, Adobe will distribute an evaluation license of BEA's WebLogic Server with Adobe's LiveCycle Enterprise Suite (ES) software, giving customers a turnkey infrastructure to deploy LiveCycle applications using WebLogic characteristics.

In other news from BEAWorld, BEA released the AquaLogic Registry Repository 3.90, the first product component of WorkSpace 360º, which in turn is a building block of BEA's newly announced dynamic business application platform initiative -- code-named Genesis.

Genesis is expected to converge SOA, business process management (BPM), social computing, and other technologies to better manage the service creation lifecycle across the enterprise. Tony Baer has some good thoughts on Genesis and BEA's actions this week.

The goal of Genesis is to allow businesses to adapt to changing market conditions without the constraint of old IT models, allowing the enterprise to assemble, change, and deploy dynamic business applications. Look for BEA to unveil the roadmap for Genesis at BEAWorld in Shanghai in December.

Registry Repository 3.0, which was announced Tuesday is designed to improve the management and governance of SOA deployments, combining the governance capabilities of BEA's AquaLogic Enterprise Repository and Service Registry, providing governance throughout the SOA lifecycle.

Among the features of the new repository are:

  • A central repository for sharing and managing metadata to enable a more seamless flow of information across the stages of the lifecycle.
  • Embedded workflow to provide a structured process for managing assets as they are developed.
  • Unified tooling to create a seamless navigation.
  • Open metadata interoperability framework for integration by third-party technologies.
  • Embedded governance and control throughout the lifecycle to help ensure that dynamic business applications are defined, designed, built and run in alignment with business goals and objectives.

Monday, September 10, 2007

Analysts 'debate' to focus on SOA management issues and outlook

I'm really looking forward to this Friday, Sept. 14, in Boston when I join up on the podium at the Harvard Club with Jason Bloomberg, senior analyst with ZapThink, to dig into the current and future landscape of SOA management.

Jason and I will be examining such questions as:
  • What should management look like in the world of service-based applications?
  • Can traditional monitoring tools be effective at managing tomorrow’s SOA deployments, or is something new needed?
  • What standards are needed to make SOA adoption a success, or do they already exist? What role do they play, and what are the alternatives?
  • As enterprises increasingly deploy SOA-based applications and infrastructure, the lingering question remains: how do current plans and approaches to application management stack up to managing these mission-critical deployments?
Tidal Software is hosting the lunch gathering -- they're calling it debate -- and then sponsoring the production of a BriefingsDirect podcast from the discussion. Tidal CTO Martin Milani will be the moderator. We'll point to the podcast here when it's available.

Tidal, incidentally, provides IT managers visibility into, and offers control over, how newer SOA-based composite solutions perform. This means management for both packaged applications and custom components in Java and .NET. I'm very interested in how SOA management interfaces (or not) with other forms of business management. That is, what are the next steps?

Can we go from SOA management to larger-abstraction management with a language and interfaces that appeal to both business managers and IT planners/operators? Is there, after all, a larger architecture of management in the offing, one in which SOA management acts as a catalyst toward business management and operational change management? Also, are we in need of standards, or a commercial best-of-breed approach, to begin this process?

I don't think that IT as a corporate resource can continue to avoid the huge opportunity for providing value to the corporate leadership by being the automated and integrated means to execute on the outcomes from various disjointed facets of business management. Some day, perhaps, to manage the SOA is to invoke change and agility across IT resources comprehensively, top-down and bottom-up.

And perhaps SOA management will therefore be a valued steering wheel on the dashboard that actually runs and changes a business. CEOs and COOs, I'm quite sure, would rather use technology as the rudder to business agility, rather than consider it a high-cost handicap to change.

The launch into this topic, by the way, began with some seemingly opposing quotes from Jason and myself in a article earlier in the summer.

So, if you're in Back Bay and care to dive in with us on all things SOA management, come on by. The luncheon event is at 11:30 a.m. on Sept. 14 at the Harvard Club of Boston, Estabrooks Room, Main Clubhouse, 374 Commonwealth Ave., Boston.

You can RSVP at 650-475-4645, or via See you there.