Oracle Corp. finally came up with an offer BEA Systems Inc. couldn’t refuse, but the sale is merely a prelude to a pile of “now what?” questions.
The next year in the application development software space will be shaped by this deal. How will BEA fit underneath the Oracle umbrella? What does this mean for open vs. proprietary tooling? Will BEA open new SOA arenas to Oracle or will this create an opportunity for competitors to win business as the Oracle-BEA assimilation takes place? Will SAP react? Will Microsoft react? Will IBM react?
I could go on all day, but I suspect you get the point: Oracle has agreed to buy BEA and the fallout promises to be massive.
Even though this deal has seemed imminent for months, the media and analyst community is trying to sort out the rationale behind it. Over at ZDNet, Larry Dignan’s blog entry notes “Ellison added that BEA will allow Oracle to instantly become a leader in messaging and ‘adds scale to our middleware business.'”
The Eye on Oracle blog from SearchOracle.com speaks with Forrester analyst Ray Wang, who says, “We expect accelerated consolidation along key battle grounds of middleware platforms such as Master Data Management, business intelligence, portals, business process management, and other information management tools. Don’t expect the competitors of BEA to sit still.”
Matt Asay at CNET flogs the conventional wisdom and asks if Oracle’s platform play will drive users toward open source offerings.
On his blog at SpringSource, Rod Johnson speculates that “the Oracle application server, OC4J, is history and Oracle will focus on driving WebLogic Server.” Yet that’s only the tip of the iceberg.
Here’s some of the other seemingly competitive products that need to be rationalized:
- Oracle Enterprise Service Bus, BEA AquaLogic Service Bus
- Oracle BPA Suite, BEA AquaLogic BPM
- Oracle Portal, BEA WebLogic Portal
- Oracle Web Services Manager, BEA AquaLogic SOA Management
- Orace Data Integrator, BEA AquaLogic Data Services Platform
- Oracle JDeveloper 10g, BEA Workshop
That last one is a real sticky wicket in that BEA built Workshop on the open source Eclipse IDE, while JDeveloper is still a fully proprietary offering. Where does the tooling go? Since Oracle bought BEA, you’d have to think this doesn’t bode well for BEA’s open tooling approach. If so, maybe Asay is onto something, maybe this is the end of the “commercial open source” path BEA was trying to navigate.
How well Oracle assimilates BEA and what decisions it makes about mixing and matching the two product lines could either give rise to an application development titan or send customer scurrying for alternatives. One thing it probably can’t afford to do is repeat what it’s done with the 2007 Hyperion acquisition, namely make a big money purchase and then remain mum on how it will fit long term into the Oracle Fusion product line. Hyperion was a complimentary acquisition, bringing business intelligence into the Oracle family. It can stand alone for a while. There’s too much redundancy with BEA for Oracle not to produce a fairly clear roadmap of how it all fits together.
Could growing fears of an economic slowdown in the U.S. be good news for service-oriented architecture?
While it’s morbid to consider, the answer might be yes. While most companies don’t have an operating SOA in place at the moment, many do (anywhere from 20 to 33% dependent on which poll you happen to be reading). If the U.S. economy takes a nap for a few quarters and money for new projects becomes tight, then SOA will be handed a golden opportunity to flash the agility it has long promised.
Can the SOA vanguard connect to new partners, assemble new applications and create new efficiencies without requiring piles of money be spent on new software? If it can, then it stands to gain a significant advantage over its competitors, who may need to shelve good ideas until they can afford to implement them. It really is the ultimate test for whether you’ve turned your app dev efforts into a profit center rather than a cost center.
In fact, recent events are making ZapThink’s Ron Schmelzer and Jason Bloomberg look like prophets for having penned “Service Orient or Be Doomed” back in 2006 — a potential recession representing the “be doomed” part of the title for those who haven’t become satisfactorally service-oriented.
Later in 2006 the authors of “Service Oriented Architecture for Dummies” echoed the same sentiment, calling SOA crucial for “the very survival of a business.” Co-author Judith Hurwitz emphasized that very point in a podcast with us last year.
In 2008 we might get to see that play out a bit. In any economic downturn there are winners, companies who thrive while everyone else is struggling. If we hear that SOA is a behind-the-scenes force for a lot of those winners, then it could move from the realm of fond desire to corporate necessity. A recession could be the ultimate good news for people who love bad news scenario when it comes to SOA.
We’ll lead off our news coverage this week with a story on how analysts think SOA will fare if the economy chills. Expect this to be a major topic as the year progresses, as 2008 may turn out to be the year that SOA proves its business value or the year where it fails to match the hype.
Over the past few weeks the media has been full of 2007 recaps and 2008 predictions. It’s not just the tech media or the service-oriented architecture space. The national and international media does it too, in every arena: politics, entertaiment, business, etc.
All in all, it probably counts as a good thing that we take the time to look back and then project forward. It gets our heads out of the routine of paying attention to nothing but what’s most immediately in front of our faces. Perspective never hurts.
At SearchSOA.com, we’ve listed our top SOA stories of 2007 – stories 1-4 and stories 5-8. We’ve spoken with two exceptionally smart people in the SOA space about what 2008 might hold in store for SOA. IBM WebSphere CTO Jerry Cuomo discussed SOA maturation and event-driven SOA. Layer 7 CTO Toufic Boubez targeted operational governance and virtualization. That’s certainly plenty to digest for anyone looking to fulfill his/her U.S.D.A. recommended yearly dose of SOA perspective. Yet there is someone important we haven’t brought into the discussion … you.
Often missing in this particular dialog is the end user. The analysts, pundits and vendors make their thoughts known in the media echo chamber, but it’s high time some users sounded off. What was big for you in 2007? More importantly, what do you see as the big things looming for you in 2008? We want to know. Feel free to e-mail me at email@example.com with your comments or post them in this blog (which, for those of you reading this in our newsletter, can be found through the hyperlink on the headline). If you want to write a full column, we’ll run it. If you just have a few quick points to make, we’ll collect those and get them up in the blog.
Users drive this bus. Ultimately, that’s how IT works. So where are you taking SOA in 2008? Is it along the same superhighways we all know about or have you found some shortcuts and interesting sideroads you plan to explore?
A wise person once said that when you set out to do something, a good place to start is at the beginning.
Service-oriented architecture is no different. Often would be practitioners of SOA start in the middle, trying to integrate two different applications. In many cases that serves a tactical purpose, but that doesn’t address how to build a truly loosely coupled service. When you attempt to tackle that higher degree of difficulty, it all starts with modeling. You’d be looking at a haphazard design process and slew of problems in its wake if you failed to do a proper job of modeling your intended service.
With that in mind, we’ve added a modeling lesson to our Service Orientation for Architects School. It offers a Webcast with noted SOA guru Thomas Erl, covering SOA design considerations and best practices. Erl ties design principles to the core principles of service orientation and delves into the relationships between various design elements.
Victor Harrison of Computer Sciences Corp. sat down for a podcast, giving five insider tips for SOA modeling. The final leg of the lesson is a report detailing what constitutes the SOA lifecycle and what architectural challenges arise as a result of this new development lifecycle. Do NOT miss this report. It features advice from numerous leading analysts in the SOA space and lays out the lifecycle considerations that need to be understood at the start of any SOA project. It qualifies as an essential resource.
Everyone claims to be #1, but we at SearchSOA.com believe that matter isn’t official until we make it official with our products of the year awards. The nomination form is now live.
We have eight product categories, spanning the whole of the service-oriented architecture marketplace. They are:
- Service design and modeling (including BPM)
- Service assembly and integration (ESB, orchestration)
- Service performance (testing, QA)
- SOA runtime management
- Data services/integration
- SOA security (including identity management)
- SOA governance (including registry/repository)
- Composite application assembly (portal, Ajax)
Products must have been released or significantly upgraded between Dec. 1, 2006 and Nov. 30, 2007. The deadline for submissions is January 25. Winners will be announced in late February. Vendors may enter in multiple categories, but each individual product may only be entered into a single category.
Criteria for judging includes:
- Ease of integration into environment
- Ease of use and manageability
- Service and support
Most importantly, products should enable the basic principles of service orientation. Submissions should highlight what exactly makes the product service-oriented.
Once again, here’s the nomination form. Only complete entries will be considered.
The purpose of service-oriented architecture is to better marry IT to business initiatives … or at least that’s what SOA proponents keep telling us. Yet what are the technologies that enable that? John Rymer, vice president and principal analyst at Forrester Research Inc., has laid out what he calls B3, the essential ingredients for creating dynamic business applications. B3 includes business process management (BPM), business rules and business intelligence (BI).
He recently sat down for a podcast to describe the architectural underpinnings of dynamic business applications.
Topics covered include:
- How SOA supports BPM efforts
- What kind of data BI needs to provide in order to enable real-time business agility
- What kinds of business rules need to be prioritized
- How BPM, BI and business rules can work together
- A sensible starting place for those looking to create dynamic business applications
Anyone interested in finding out more about this subject can get a free copy of Rymer’s report on Dynamic Business Applications from Forrester.
In a recent survey, our readers reported security is the top organizational requirement for SOA. All of the agility in the world doesn’t matter if you can’t provide it in a secure fashion.
Yet traditional security isn’t sufficient to lock down a services infrastructure. Applications aren’t being housed on single servers in a static network. Changes in the application domain necessitate changes in the security domain and it is incumbent upon the application architects to plan for the different types of security that service-oriented architecture will require.
With that in mind, we’ve launched our new security lesson inside our Service Orientation for Architects School. It provides essential resources for architects looking to bake in the security that is essential for a proper SOA.
Burton Group’s Anne Thomas Manes offers up a Webcast on a holistic approach to SOA security. It deals with network options, end point intelligence and identity management practices. Steve Craggs of Lustratus Research identifies the top 5 SOA security traps in a podcast.
Craggs also has a written tip on the flexibility-security tradeoff.
It is no secret SOA is creating new vulnerabilities. It will be the users who educate themselves about how to protect against those new vulnerabilities, the ones who don’t expect someone else in the organization to find the holes, who make the most successful switch to service orientation.
We spend a lot of time these days talking about governance and management when it comes to SOA. There’s a good reason to take that macro view, because far too many people get lost in the trees and fail to see the forest when it comes to service orientation. We are talking about enterprise architecture after all, so an enterprise-level view would be appropriate.
That said, you can put the perfect governance model in place and it won’t mean a thing if you don’t understand messaging. SOA requires a lot of integration work and integration, more often than not, requires messaging. With that in mind we created a messaging lesson in our Service Orientation for Architects School. It features a Webcast with WSO2’s Paul Fremantle on service-oriented messaging, in which he breaks down a slew of messaging alternatives, including JMS, HTTP, REST, SOAP, WS-Addressing, WS-ReliableMessaging and traditional message queues.
Yet more than that, Fremantle delves into messaging practices that will aid you on the SOA front. It’s one thing to boil up a big pot of integration spaghetti, quite another to architect a reliable messaging infrastructure. The lesson is focused on the latter.
The goal of mediation is to help create a flexible messaging backbone for your company. The tip covers a host of mediation techniques, including Web Caching, load balancing and message-based routing.
It’s an ideal chance to catch up on the architectural underpinnings of messaging as they apply to SOA. Even for those of you who feel fairly confident about your messaging skills, this lesson is sure to give you a few pointers to hone your skills.
It’s probably a sign of our times that we view BEA Systems Inc. as a little fish unable to defend itself against larger predators in the software industry ocean. According to its 3rd quarter financial report, BEA is on track to rake in $1.5 billion this year. It still needs to prove in the 4th quarter it hasn’t been crippled by Oracle Corp.’s $6.7 billion October takeover bid, which it rejected, but a conversation I had last week with a BEA customer proved enlightening.
The customer in question, a CTO whom I contacted on a totally separate matter and wished to remain anonymous, believes BEA’s approach to technology can help it weather this storm.
“They adhere to standards and their tooling is open enough that we see no reason to stay away,” he said. “If a change we didn’t like occured after a takeover, we don’t feel like we’d be locked in with BEA. They get loose coupling. We could unplug from them if we had to.”
His basic argument was that BEA has become open enough and embraced heterogeneity to the extent that it can continue to compete for customers based on functionality. It’s got a service-oriented defense system.
“We need technology that works,” he said. “This takeover drama might be interesting to Wall St., but it has nothing to do with my projects. From a user standpoint, BEA was in more trouble four or five years ago when we weren’t sure if they were going to embrace more open systems. They did and because of that we’ll continue to look at them.”
He reinforced what we already know, BEA has proven successful at selling software during the past decade and it shouldn’t be taken for granted that users will stay away from a vendor that has delivered for them in the past. This isn’t some overly leveraged wannabe without the means to support itself. BEA has been a viable player in the app dev space.
Here’s something I wrote in October about why Oracle might want BEA:
While there’s massive overlap between BEA’s offering and Oracle’s Fusion line, BEA does have three particular strengths that Oracle might be looking to leverage: data services, internal portals and external transactions. Those were the three most popular types of service-based applications our users reported they are either working on or plan on undertaking in the next year. Even more importantly, the demand for these types of applications increased sharply with respondents who reported their companies had achieved some measure of architectural maturity. In other words, the farther along users are with SOA, the more important those projects are likely to become.
BEA has its AquaLogic Data Services Platform, it has its WebLogic Portal product as well as the portal functionality it acquired when it bought Plumtree Software in 2005, and it has the Tuxedo transactional business on which it built itself. So the BEA goose might be sitting on a few golden eggs … and that’s not a bad pet for a would-be giant to have.
Yet if that’s a good set strengths for Oracle to buy, then it’s also a good set of strengths for BEA to have. If a user has a data services, portal or transactional project in the works, then BEA (which reports that more than 60% of its revenues are derived from services) stands to be a player.
While the Oracle bid surely staggered BEA, don’t be surprised to see BEA do a fair job of fighting back this quarter. The fact that it has enough going for it to be a takeover target also means it might have enough going for it to fend off Oracle’s advances.
I was reading a recent blog entry by Joe McKendrick in which he noted that service-oriented architecture can save money during hard times and add revenue during good times. It got me thinking about something I’ve heard fairly regularly over the years, namely that SOA often sounds like something out of an infomercial.
You mean SOA slices, dices, chops, cooks things to perfection, cleans up easily, prepares healthier food and has zero environmental impact? You almost expect Ron Popeil to pop out from around the corner and announce that, “But wait, there’s more.”
Let’s face it, SOA sometimes sounds too good to be true. It also leads one of the great misconceptions about SOA, that it’s a tidy thing you can buy. People want SOA to be tangible. They want to be able to point to it and say, “There’s my SOA.” It’s why so many glommed onto the enterprise service bus concept. The ESB is a piece of integration middleware that follows certain service-oriented principles, but many made the mistake of thinking that buying an ESB gave you a de facto SOA. It’s a natural reaction. When something new and compelling comes along, you want it in your hands, preferably now.
Yet SOA isn’t some secret spice that comes in its own box, something you can add liberally to every project. SOA is a consistent and sensible approach to architecting your business. It’s rigor and diligence more than technology.
This week we’ll get deeper into that issue with a podcast with esteemed IT analyst and co-author of “Service Oriented Architecture for Dummies” Judith Hurwitz, in which she directly addresses the whole faulty concept of “SOA in a box.”
That brings me back to the (fair) complaint that SOA sounds too good to be true. Critics are correct that no one thing will solve all your app dev problems. That said, rigor and diligence in building a modular, adaptable architecture is exactly the sort of thing that can help you in mulitple, often diametrically opposed, situations. When the bad times hit, it can help you with cost containment. When the good times hit, it can help you seize opportunities. That’s what an adaptable infrastructure does.
Just last week, we had a story that noted an SOA infrastructure had helped Sprint/Nextel speed up integration with new trading partners twentyfold. That’s a case of saving you money and making you money in one fell swoop. Doing things in a service-oriented manner creates business agility, which is the real goal.
Building a more agile business isn’t something that sounds too good to be true. Large numbers of companies are doing it right now and they are reaping the benefits. It may be hard work, it may require creative approaches to change the corporate culture, but it is not a flimflam promise. SOA is an approach to technology, which opens up a greater number of business possibilities. It can promise more because flexibility is at its very core.