(Finally) My Notes from BEAWorld Santa Clara

Unless you are a reader of PSGroup’s research service, the combination of my last travel distressed post, and my subsequent blog silence may leave the impression I was still stranded in a connecting airport. However, I’m happy to report I eventually got out of Dulles, and made it to Santa Clara for BEAWorld on Tuesday and Wednesday.

At BEAWorld, I was in both of my roles, architect and industry analyst. As an architect, I sat in on sessions, and chatted with fellow attendees about their IT challenges, and their impressions of BEA’s (and competitors’) offerings.

As an industry analyst, I was able to meet 1×1 with members of BEA’s executive team. Not surprising, I was asking questions related to BEA’s architectural intent. In addition, I was curious as to any (early) insights on how the SOA vision/bet was going.

This (long) post starts with a high level analysis, and then drops into some quick notes/observations from the conference.

The Analysis Piece – BEA’s BIG SOA BET

As most know, BEA’s vision/quest is to become the real world leader in SOA. In such, BEA has devised (and is delivering on) an interconnected three-part strategy. The strategy starts with BEA’s SOA Domain Model and is supported by advisory services, and the (Aqualogic) services infrastructure. [For more on the specifics of BEA’s vision, check out BEA’s site and/or my April PSGroup report: BEA Answers the Vision Question(s).]

BEA is betting big that SOA achieves mainstream adoption in the next 3-5 years. And, that BEA can win the same proportional share of that mainstream SOA market, as they hold in application infrastructure. If this happens, BEA has an excellent chance of remaining independent. If not, then BEA will most likely be scooped up by an application vendor, infrastructure provider, or, as Phil Wainewright at Loosely Coupled suggests, a service provider.

A critical success factor for BEA is to guide their current customer base “up the stack” to SOA — SOA that is, on BEA’s Aqualogic Services Infrastructure. In such, I believe BEA needs to do three things (really well):

1. SOA Evangelist First, Product Seller Second.

First, BEA needs to be a “real world” SOA evangelist first, and the seller of SOA infrastructure products second. This evangelism should include: what SOA (the architectural strategy) really is, what SOA is good for, how to (incrementally)
get there, and the business and IT implications.

BEA did a pretty good job of this at BEAWorld. I attended some good “Making SOA Real” sessions hosted by BEA’s SOA Practice Leaders on Organization and Governance, and an SOA Roundtable. The messages were on target: SOA is an architectural strategy, SOA success requires collaboration, governance and service catalog/portfolio plan, SOA is incremental, SOA is not a “right click architecture” (service != java class), SOA does not require Web Services, and SOA does not require an ESB. Although on the last two points, Web Services and ESB, the BEA presenters (SOA practice and Aqualogic product) did state SOA would be easier and more sustainable using both Web Services and an ESB.

Also, Bruce Grahams, BEA’s VP of consulting, hosted an SOA from Pilot to Production Panel in the general session. The panelists were John Peebles, vice president, online marketing for Cendant Car Rental Group, parent company of
Avis and Budget; Doug Saucier, vice president of enterprise architecture services, Sony Pictures Entertainment; Vinny Carpenter, lead architect for the Wells Fargo Advantage Funds; and Patrick Holmes, senior principal engineer, IT
architecture group, Intel Corporation.

I was pleased to see this session on the agenda – I enjoy hearing real world (business-driven) technology stories. Most often, these folks (like myself), found themselves using SOA (although not labeled as such then) because it just seemed
logical for their business. For me, the best SOA evangelism is from IT professionals speaking in business contexts. You know the “Here’s what I did, and why. Here’s what happened. Here’s what I would do differently. Here’s what I’m thinking of next…” type of stories. Unfortunately (at least for me), there was only about 30 minutes for this panel, so a lot of great information went unsaid. Although, all is not lost, Vinny Carpenter posted what he would have shared, had there been time.

2. BEA’s SOA infrastructure must “work”.

As I wrote for the PSGroup September 29 research service, BEA has a fiercely loyal customer base. Without exception, every developer, administrator, architect, and IT manager I spoke with is looking to BEA as its first-choice provider of SOA infrastructure. Why is that? BEA has a strong track record of delivering application infrastructure (Tuxedo, WebLogic Application Server) that works. I use the term “works” as a developer, architect, or administrator would, in that BEA’s application infrastructure products focus on, and deliver, the “-ilities”–reliability, scalability, manageability, and performance. For BEA to win its bet, it must ignore the SOA feature/function foot race, and concentrate on receiving the “it works” stamp from customers for its services infrastructure.

3. BEA needs to keep its current application infrastructure customers (WebLogic and Tuxedo) happy.

Let’s face it, in an open standards-based world, the power shifts to the customers. If you adhere to the J2EE spec, you aren’t locked into any particular vendor’s application server. It is relatively easy to switch. And, the switch can be to open
source infrastructure, cutting out all the upfront acquisition costs. So, its only natural, IT decision makers are asking their vendors “What have you done for me lately?”

Innovation

BEA’s answer is continued technology innovation, and broadened appreciation/support of enterprise IT realities. On the innovation, BEA introduced performance improvements to JRocket (JVM), predictable garbage collection for WebLogic
(bringing J2EE to real-time applications, such as stock trading), and hot deployment (zero downtime) to WebLogic. The hot deployment demo – deploying a new version of an application, without breaking existing sessions – really got the audience’s attention. Having lived through my share of 3:00am implementations – to not interrupt the business – I could definitely see the feature’s appeal. There was also significant buzz on the real-time edition.

Enterprise IT Realities

On the broadened appreciation/support of enterprise IT realities, BEA gets (and supports) that IT environments are heterogeneous. This showed in a few ways. First, BEA’s SOA strategy has been devised recognizing that IT portfolios are (and always will be) comprised of assets implemented using a mix of technologies, platforms, and architectural styles.

Second, BEA understands that most enterprises will have some open source application servers in the mix. WebLogic 9 allows for the administration of Tomcat and Geronimo application servers from within the WebLogic Console.

Third, BEA understands that not every developer is (or should be) a J2EE expert.  In situations that don’t require the full complement of J2EE technologies, but still have J2EE implementations, enterprises are turning towards open source frameworks such as Struts, Spring, and Hibernate. Since the frameworks are part of the deployed code base, there is always the risk (if the community dries up) of having unsupported production code. In an effort to mitigate this risk, BEA has announced support for the J2EE frameworks (Struts, Spring, Hibernate, Beehive) being embraced by their customers. This move resonated strongly with developers at the show.

Ok, that’s way more analysis than I intended to write… Suffice it to say, BEA is working the odds to win its SOA bet.  Now, for the notes…

Quick Notes/Observations from BEAWorld

My Conversations with BEA Leaders

• When I inquired on the Tuesday morning Microsoft/JBoss announcement, it was shrugged off as a “non-event”. Not an attack by Microsoft on BEA or IBM, but rather a standard practice (product integration optimizations) in a heterogeneous world.

• Talking to Mark Carges, BEA’s CTO, it is obvious a huge part obvious BEA’s architectural premise, is in delivering stuff that “works”.

• Continuing on architectural premise, talking to Shane Pearson, BEA’s VP of Product Management, I learned that BEA thinks about services infrastructure in a service-oriented manner. The ESB packaging has services for mediation, routing, service composition, but not business process management. BEA sees business process management as a service that integrates with the ESB.

• I had the chance to meet with Rhonda Hocker, BEA’s CIO. Not only does BEA “eat their own dog food” (WebLogic App Platform: App Server, Web Logic Integration and Portal, and AquaLogic); the internal IT organization, as a customer, contributes ideas, requirements, and even code, to the product line. Rhonda described her organization’s SOA evolution, which like many early adopters, started a few years back. The problem Rhonda was trying to solve was a familiar one, freeing information trapped in packaged applications, without ripping and replacing. Not surprisingly, Data Services and Portals play a key role in BEA’s internal IT architecture. For more, read page 2 of this pdf.

• In my quest to find content for a unified (but reasonable) SOA methodology, I asked one of BEA’s SOA Practice Leaders what BEA was doing to help customers discover and define the right services. At first, I scared him with
  the word methodology – he thought I meant tomes of documentation. When I assured him that wasn’t what I meant, he told me BEA has exercises in their SOA workshops to get at the services catalog (my term). I hope to get a look
  at these exercises in a follow-up meeting.

• While squatting at a “reserved for PR table”, I had an interesting conversation with a principal player of the WebLogic Communications Platform. While I don’t cover telecommunications (and won’t try to fake it) – as an end consumer, I think some of the SIP enabled services (triple-play, find-me, follow-me) are cool. What I enjoyed most about this conversation was my fellow squatter was talking in use cases. He put the product in “what it can do for me” terms. [More coming on the use case thing in a future post.]

What I liked – Real World and Customer Loyalty

• A real world IT perspective to their strategy: IT is heterogeneous, SOA needs to be thought of holistically (see domain model), planned strategically, and implemented pragmatically! Don’t buy what you don’t need, but don’t box
  yourself in. Also, if you haven’t considered the organizational issues and governance, you’re doomed. So true.

• The attendees I spoke with (architects, developers, administrators, IT leaders) have a fierce loyalty to BEA, because, simply “the stuff works”.

What Frightened Me – An SOA Gray Area

More than one presenter referred to a future in which enterprises will have “thousands or tens of thousands of services”. Ok, sure they are trying to sell a registry and SOA management infrastructure, but 10,000+ services?

In drilling in on that point (with a couple of BEA folks), it became clearer that we had entered one of many SOA gray areas. This one had to do with granularity, compositions, and service types. Essentially, it came down to this: If future applications are really assemblies of scenarios (compositions of services, business process and events), and each of those scenarios is implemented as a service, then there could be 10,000 services. But…I think we (the industry) need to be clear about what we mean (when we say service), and offer rules of thumb on reasonable size service catalogs, by type, level of granularity, and perhaps logical versus implementation.

Interesting Asides

• During “The Enterprise Service Bus: Core to Creating a Liquid Vision for SOA” BEA didn’t come out and say, but I thought I heard “Java Business Integration (JBI)”. It was in the ESB roadmap plans as “Pluggable Extensibility”. As you’ll recall BEA abstained from the JBI voting. Of course, it could just be wishful thinking on my part – I like the idea of a backbone with pluggable services. When I leaned over to the analyst next to me and said “sounds like JBI”, he thought not. Mark Carges, BEA’s CTO, told me BEA is watching JBI, as is their practice on early standards.

• Jonathon Schwartz spoke (eloquently) on the participation age, power at the edges, openness, and inevitable choice. Jonathon then proceeded to pitch Sun’s Enterprise Java Tools and Application server – apparently providing “choice on the spot” to BEA’s developer community. (perhaps I should take a sales lesson from him)

• Burt Rutan’s presentation on his SpaceShipOne program was great! I’ve never had the inclination for space travel, but I’m glad there are people like Burt, pushing the envelope and pursuing their dreams.