What’s in a name? Grid computing and Cloud computing advocates will soon be asking this question. Growing out of academic and open source software efforts, the Grid was represented as a virtually distributed architecture where vast computing nodes worked on jobs as needed. Grid was an outgrowth of Utility computing. Both terms were efforts to find analogies in the electrical power industry for hardware-software combos in the world of distributed computation. Grid never quite caught on. Continued »
Microsoft Nick Malik recently blogged on “Inside Architecture” about features that would have to be included in a comprehensive framework for enterprise architecture.
There would have to more communication and sharing between models, he writes. A published taxonomy is another recommendation that would particularly benefit smaller businesses.
Like most MSDN blogs this comes with a disclaimer. This is not the corporate line, necessarily. But, with the company’s moves toward OSLO model unification, Malik’s thinking on EA may have special interest.
Some of the challenge to architects these days comes not from the server side where so much integration effort has been placed, but from the client side. There, Ajax has arisen to improve users’ interactions with multiple application services.
But, as Richard Monson-Haefel told SearchSOA.com’s Rich Seeley, the unending proliferation of thinly supported open-source Ajax frameworks may cause architects for proprietary RIA-alternatives to Ajax. The long-time Burton Group analyst recently took a spot in the Curl brain trust.
Rich writes of his conversaion with Monson-Haefel in How to sort out Ajax and RIA frameworks. Monson-Haefel cites Curl, Flash and Silverlight among RIA choices some individuals are now considering. What do you think?
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.
We’re officially into the dog days of summer, that time of year when you’re mind strays to thoughts of cooling off in a body of water. As it turns out, we’re also into the dog days of many SOA implementations.
A recent Burton Group study found that many SOA initiatives have stalled, mainly due to an inability to involve the business in the effort. In a more general sense, stalls are to be expected in any 20-year initiative. Faces change, acute problems arise, the funding pipeline temporarily goes dry. Surely you didn’t expected that achieving enterprise agility, automated business processes and streamlined data access would be a quick or easy process.
If you’re fighting through a corporate lull or battling your own ennui, take heart – you’re not alone. During a long haul you will need to take some rest stops and SOA is an extremely long haul. Here’s some thoughts from Burton Group’s Chris Howard concerning SOA fatigue:
- “You can build something that is absolutely spot on perfect and it will still be wrong.”
- “Reusability is always over-promised.”
- “What do the executives care about? They care that the SLA holds and they don’t care how you do it.”
- “SOA fatigue is setting in because SOA success is tenuous, but when SOA succeeds, it really succeeds.”
- “What does it mean to be 100% SOA compatible? Is that like good fiber or something?”
- “SOA needs to be part of something bigger and if it’s not, then you ought to ask yourself why you’re doing it.”
The good news for Oracle Corp. is it seems to have acquired a happy BEA Systems Inc. customer base. Yet the bad news for Oracle is that it seems to have acquired a happy BEA customer base that isn’t particularly thrilled with the Oracle purchase, according to a SearchSOA.com poll taken last week.
As Oracle prepares to announce its plans for the BEA acquisition tomorrow it may be facing a customer revolt if it’s not careful. What follows is a summary of the survey findings. The raw numbers are available here.
In all, we received 431 responses. Most of the respondents were BEA WebLogic Application Server and Oracle Database customers (94.90% in each case). Respondents also used a a healthy number of other BEA products (WebLogic, AquaLogic, Tuxedo, etc.), while only a small percentage used non-database Oracle products. Part of this is to be expected as the survey was geared toward the BEA user base. This group indicates that Oracle indeed bought itself a customer segment into which it had little penetration. Of particular note is that not many of the BEA customers were using Oracle’s packaged applications (e.g. financial, CRM, human resources).
Most (58.70%) came from IT shops with 250 or more employees.
75.56 of respondents reported they were either somewhat or very satisfied with their BEA products. That confirms something this industry watcher has heard anecdotally over the years, namely that BEA customers, if not teeming in numbers, were a generally contented lot. 61.26% reported they were somewhat or very satisfied with their Oracle products. The main difference is that 24.83% reported they were neutral in regard to their Oracle products, which is perhaps understandable given that most were database customers and almost 75% of the respondents were either architects or developers, not the sort that falls overly in or out of love with a relational database.
87.94% reported they have not yet been contacted by Oracle concerning their BEA products and six months of relative radio silence has seemingly made them nervous. 29.47% reported that they lack confidence that Oracle will continue to support their BEA products and another 44.55% aren’t sure whether that will happen. Oracle has managed to allay similar fears when it has acquired packaged app vendors, but “support” in the development community will mean not only continuing service and support for existing products, but also making sure they keep pace with new advances in the marketplace. This brings us to where Oracle stands to alienate this new customer base if it doesn’t announce and follow through on aggressive plans to move the BEA product set forward (principally WebLogic Application Server).
Potential customer revolt
62.18% of respondents report they will not look to move to comparable Oracle products if their BEA products are discontinued. Another 25.06% report they are unsure on that matter. 77.26% say they do not feel Oracle has a strong offering in the areas where they are using BEA products. Additionally, 70.77% report they will look to replace their BEA installments rather than keep them as legacy if those products are discontinued. It creates a thorny situation for Oracle. It does not have a strong reputation with these, largely, app dev users and they have expressed a clear willingness to jump ship should they not like the course Oracle charts for them. While Oracle surely will look to allay these misgivings in the BEA user base, competitors just as surely will be looking to woo this potential pack of free agents.
Perhaps it can be chalked up to people not liking change or to unhappy customers being more likely to respond to a poll, but 52.43% of those polled reported they have a somewhat or very negative view of Oracle’s BEA acquisition. Another 32.48% voted neutral. The poll indicates that Oracle has a ton of work to do if it wants to win over these BEA customers. This is indeed a new market that Oracle could penetrate in its quest for global software domination, but these users are not rolling out a welcome mat. It may takes years of continuing and advancing key BEA product lines before Oracle can establish itself with these customers, making tomorrow’s announcement only the first step on a political tightrope that stretches beyond the horizon.
431 total responses
1. Which BEA products do you use? (check all that apply)
Weblogic application server–94.90%
Other Weblogic portal—12.06%
Aqualogic service design and development tools–18.10%
AquaLogic governance tools–7.89%
Other AquaLogic products–11.14%
2. Rate your level of satisfaction with these BEA products:
3. Which Oracle products do you use? (check all that apply)
Human resources software–2.09%
4. Rate your level of satisfaction with these Oracle products:
5. Has Oracle contacted you about ongoing support for the BEA product(s) you use?
6. Do you feel confident the BEA product(s) you use will be given the proper support by Oracle?
7. If the BEA product(s) aren’t part of Oracle’s roadmap, will you look to move to comparable Oracle product(s)?
8. If Oracle discontinues your BEA product(s), will you maintain it as a legacy system or look to replace it?
Maintain as legacy—29.23%
Look to replace–70.77%
9. Do you feel Oracle has a strong product offering in the areas where you have BEA product?
10. As a customer, what is your overall impression so far of Oracle’s acquisition of BEA?
You wouldn’t know the mergers and acquisitions market on Wall Street was in the doldrums if you were just watching Progress Software Corp. this week.
First, Progress snapped up IonaTechnologies Inc., adding Iona’s Artix ESB technology and CORBA legacy customer base. Then on Friday Progress announced that it has also purchased Mindreef Inc., the privately-held vendor of testing and service validation tools for service-oriented architecture (SOA), for an undisclosed price.
The Progress acquisition of Mindreef almost got lost in the hoopla surrounding the purchase of Iona, wrote analyst Joe McKendrick on his ZDNet blog on Thursday. He pointed out the importance of Mindreef’s philosophy of reaching out with its tools to practically everyone involved in SOA development.
“Mindreef’s emphasis has been on enabling professionals from all sides of SOA – architects, developers, and managers – to better collaborate on service design and implementation,” McKendrick wrote.
Jason Bloomberg, senior analyst, ZapThink LLC., who earlier in the week said the Iona deal made good sense for Progress, also saw value in the Mindreef acquisition.
“Both the Mindreef and IONA deals are great moves for Progress,” Bloomberg said. “Governance, quality, and management are more important to SOA success than middleware is, so it’s a great sign that they’re adding SOA quality to the mix.”
Change management is a crucial piece of SOA that appears to be missing in many vendor offerings, the ZapThink analyst noted.
“After all, unless you enable broad-based service consumption and composition in environments of continual change, which is what SOA is all about, you can’t have effective SOA. It’s surprising that more SOA infrastructure companies haven’t made a deeper investment in SOA governance, quality, and management solutions, since they will rapidly realize that the success of their SOA initiatives depend on successfully addressing those issues.”
This week’s acquisitions of Iona and Mindreef were a win-win for Progress in Bloomberg’s view.
“Progress is doing a great job of rounding out its SOA offerings by adding Mindreef’s SOA quality solutions to the mix,” the ZapThink analyst said.
In a statement released on Friday regarding the Mindreef acquisition, Progress said it was adding three Mindreef tools to its Actional SOA Management product line:
- SOAPscope Server
- SOAPscope Architect
- SOAPscope Developer
Progress and Mindreef are planning a Webinar in mid-July to further explain how the products will fit together, according to McKendrick.
Next Tuesday Oracle will announce its plans for how it intends to integrate BEA inside its corporate walls. While we probably won’t get too many specific product roadmaps, we should get an idea of how Oracle intends to handle the product overlap in the areas of SOA and Java development.
Yet there’s a difference between what Oracle intends to do and how BEA users view the acquisition. In advance of the announcement we at SearchSOA.com are conducting a BEA user quiz to take the pulse of that community. We know that we have a large number of BEA users in our readership and we’re looking to get your input concerning Oracle, BEA and how this deal affects your development plans. It’s a quick that should take only a minute to fill out.
The poll closes at noon EDT on Friday, June 27. We will publish the results next Monday in advance of the Oracle announcement.
Dan Blankenhorn at ZDNet has posted some provocative thoughts about the Java CAPS 6.0 SOA suite announcement from Sun Microsystems. His basic take is that Sun fails to live up to its self-generated open source billing. He writes:
A true open source SOA strategy would embrace support for competing alternatives, rather than try to push everyone into paying for (and building) on a Sun-only platform.
True enough, Java CAPS, based largely around the former SeeBeyond ESB, is pretty much all Java platform all the time. I’ve spoken with no small number of people in the SOA space who routinely point out that the Java platform at best is only part of an SOA strategy. Those laments are nothing new. Sun’s approach here is interesting because it’s the opposite of what JBoss is doing. For instance, Sun’s bragging that you get the NetBeans IDE and GlassFish app server with Java CAPS. Yet what if that’s more than you want or need? Maybe you’re not looking for a platform. While JBoss certainly can’t be accused of collecting open source purity points by pushing significant amounts of non-JBoss technology, it is pitching a modular SOA platform.
It gets to the question of how much technology and complexity do you need to pursue service orientation? This is where I repeat the old saw that SOA isn’t something you buy (or download), it’s something you do. Has Sun stuffed too much into Java CAPS or maybe users would be better served to skip the middleware and just use GlassFish? As Blankenhorn points out, in an open source world the app server and service bus ought to focus well beyond each other.
Also, the big SOA-related buzz at JavaOne was around the session on Apache Tuscany. Tuscany is an open source project put together well outside the auspices of the JCP and users at the biggest Java show of the year flocked to it. Apparently there’s healthy demand for open source functionality beyond the Sun platform.
That brings us to the newsiest part of the Java CAPS announcement: Sun is adding MDM tools via a project called Mural. XAware, Talend and Apatar (and others) are already out there offering up open source data integration. Is Mural necessary or does it aim to reinvent the wheel? Eclipse has its Data Tools Project as well. Data integration would seem to be an area where Sun could follow Blankenhorn’s advice and bring some outside technology into the fold.
Sun seems to be stuck in an odd place at the moment where it espouses and embraces many of the laudable benefits of open source software, but it has not yet embraced the concept enough to satisfy the purists or to perhaps even leverage open source to achieve notable innovation.