Press release by Oracle:
"Oracle
Corporation (NASDAQ: ORCL) today confirmed that it delivered a letter
to the Board of Directors of BEA Systems, Inc. (NASDAQ: BEAS) on October
9 in which Oracle proposes to acquire BEA for $17.00 per share in cash.
The $17.00 per share offer is a 25% premium over yesterday's closing
price of $13.62."
If I did not know anything about acquisitions, I would think that this is Larry Ellison's reaction to the Business Objects acquisition
by arch rival SAP (don't get mad.... get even). But as these
acquisitions and offers usually take quite a long preparation time, I do
not think this is a reaction to the SAP activities.
Leaves me
wondering though what the rationale is for Oracle to make the offer for
BEA. Oracle states in its press release that "the acquisition of BEA by
Oracle will enable an increase in engineering resources that will
in-turn accelerate the development of our [Oracle's, LB - sic]
world-class suite of middleware". Which might mean that Oracle is facing
some challenges, maybe even problems with its current Project Fusion
program. Putting it all together is one of the key challenges Oracle
faces in its Fusion endeavor, and the acquisition of the brightest
engineers from BEA could be considered a way to face this challenge.
This should not come as a surprise as I have said before that one of the key drivers for Oracle's acquisition wave was "acquiring the people who created the technology".
Also, the potential acquisition of BEA supports my prediction and observation
that increasingly pure-play vendors are disappearing, as the
functionality of their products is incorporated into enterprise
applications, OS and hardware.
Maybe this is the moment to say: integration middleware is now officially commoditized.
Friday, October 12, 2007
Wednesday, October 10, 2007
Why SaaS will make and why ASP didn't
I picked up blogging again last week when I wrote
that the acronym SaaS does not ring many bells yet with decision
makers. Maybe ASP does, but that is something many decision makers do
not want to get involved with as that is so 90's.
Still there are many people that think that SaaS is the same as ASP. Take this definition for instance which I found on the web site of the Dutch research firm that concluded that SaaS is not known by many decision makers:
"SaaS (Software as a Service) is software provided as a hosted service which is accessed over the Internet, and which is billed through a subscription structure. This is also called ASP(Application Service Providing)."
Let me explain why I think this makes no sense. To start with, the delivery model is completely different: with ASP, you pay a monthly fee for a fixed period (sometimes even for the duration of 3 to 5 years), while with SaaS you only pay for the usage ("pay as you go"). This may sound trivial, but it has consequences for the customer orientation of the provider: because a subscriber is not tied to a fixed (maybe long) period arranged by a contract, which is the case with ASP, it is easier to make the switch to another provider. This implies that the SaaS provider must do more for client retention, hence deliver great customer service.
The architecture of products is usually also very much different between an ASP and a SaaS provider, mainly because SaaS products have been developed from scratch to be used over the Internet (take Salesforce.com as an example). The ASP versions of products have usually been "web-enabled", but still have a typical client-server architecture. In the past, the ASP model therefore never fully delivered what it promised, because of the lack of bandwidth, or because of a performance degrade resulting from the web-enablement of the application.
In short: both the delivery model and the architecture of SaaS and ASP are different: SaaS solutions are generally speaking better prepared (optimized) for usage over the Internet, and its delivery model is more flexible than the ASP delivery model. So, we are dealing with different animals (that live in the same Zoo though, named Outsourcing). The key advantages of SaaS over ASP make that I believe that SaaS will succeed, as these are exactly the reasons why ASP did not succeed.
Still there are many people that think that SaaS is the same as ASP. Take this definition for instance which I found on the web site of the Dutch research firm that concluded that SaaS is not known by many decision makers:
"SaaS (Software as a Service) is software provided as a hosted service which is accessed over the Internet, and which is billed through a subscription structure. This is also called ASP(Application Service Providing)."
Let me explain why I think this makes no sense. To start with, the delivery model is completely different: with ASP, you pay a monthly fee for a fixed period (sometimes even for the duration of 3 to 5 years), while with SaaS you only pay for the usage ("pay as you go"). This may sound trivial, but it has consequences for the customer orientation of the provider: because a subscriber is not tied to a fixed (maybe long) period arranged by a contract, which is the case with ASP, it is easier to make the switch to another provider. This implies that the SaaS provider must do more for client retention, hence deliver great customer service.
The architecture of products is usually also very much different between an ASP and a SaaS provider, mainly because SaaS products have been developed from scratch to be used over the Internet (take Salesforce.com as an example). The ASP versions of products have usually been "web-enabled", but still have a typical client-server architecture. In the past, the ASP model therefore never fully delivered what it promised, because of the lack of bandwidth, or because of a performance degrade resulting from the web-enablement of the application.
In short: both the delivery model and the architecture of SaaS and ASP are different: SaaS solutions are generally speaking better prepared (optimized) for usage over the Internet, and its delivery model is more flexible than the ASP delivery model. So, we are dealing with different animals (that live in the same Zoo though, named Outsourcing). The key advantages of SaaS over ASP make that I believe that SaaS will succeed, as these are exactly the reasons why ASP did not succeed.
Saturday, October 6, 2007
Are we dealing with GAF(general acronym fatigue)?
Two recent news items have made me wondering whether we are dealing with GAF: a General Acronym Fatigue.
The first news item is from a Dutch IT newspaper, which quotes research from a Dutch IT research organization: 73 percent of all IT decision makers do not know spontaneously what SaaS (Software as a Service) is. Only after an explanation of what is meant by SaaS (a formal definition), 69 percent say they know SaaS. Which leads to the conclusion that only 4% of IT decision makers really have no clue what SaaS is about, and 69 percent are just confused by the acronym / terminology. An ASP (Application Service Provider, not Active Server Pages) expert in The Netherlands says this is due to the fact that companies, vendors and end-user organizations all have different names for the phenomenon: "Web 2.o", "internet-accounting" or "online services". Some people have even called it "ASP 2.0", which is really silly as there are substantial differences in the delivery models as far as I am concerned.
The second news item has been not on a single source, but in fact has been heard among many blogs: more and more people are seriously questioning the ESB (Enterprise Service Bus) is worth using. I have answered this question already some time ago: it is not! It is just replacing one low viability solution (CORBA or brokers) with another (service buses). I have plead before to use Apache for instance as a service bus (or rather I would name it service intermediary), and obviously more people have come to this conclusion. But then of course, we are talking about the design pattern, and not about the commercial product type some people considered to be the next generation application server. I suggest to drop the name ESB, and instead to name it what it is: a service intermediary.
The future does not look toto bright for people confused with acronyms, in particular because the aaS letters are pasted to any random technology or product category you can imagine: PaaS (Platform as a Service), CaaS (CRM as a Service), AaaS (Accounting as a Service) well, you get the idea... the good thing is that we run out of options at 26 acronyms...
If we (yes, everyone in IT is responsible for this GAF situation) are unable to come up with good names for new concepts, patterns, technologies or products, we should not blame those poor IT decision makers for not understanding our value proposition. In 9 out of 10 times we are not dealing with an ignorant decision maker, but just with someone suffering from GAF.
OK, I am off for now, I am going for a BLT.
The first news item is from a Dutch IT newspaper, which quotes research from a Dutch IT research organization: 73 percent of all IT decision makers do not know spontaneously what SaaS (Software as a Service) is. Only after an explanation of what is meant by SaaS (a formal definition), 69 percent say they know SaaS. Which leads to the conclusion that only 4% of IT decision makers really have no clue what SaaS is about, and 69 percent are just confused by the acronym / terminology. An ASP (Application Service Provider, not Active Server Pages) expert in The Netherlands says this is due to the fact that companies, vendors and end-user organizations all have different names for the phenomenon: "Web 2.o", "internet-accounting" or "online services". Some people have even called it "ASP 2.0", which is really silly as there are substantial differences in the delivery models as far as I am concerned.
The second news item has been not on a single source, but in fact has been heard among many blogs: more and more people are seriously questioning the ESB (Enterprise Service Bus) is worth using. I have answered this question already some time ago: it is not! It is just replacing one low viability solution (CORBA or brokers) with another (service buses). I have plead before to use Apache for instance as a service bus (or rather I would name it service intermediary), and obviously more people have come to this conclusion. But then of course, we are talking about the design pattern, and not about the commercial product type some people considered to be the next generation application server. I suggest to drop the name ESB, and instead to name it what it is: a service intermediary.
The future does not look toto bright for people confused with acronyms, in particular because the aaS letters are pasted to any random technology or product category you can imagine: PaaS (Platform as a Service), CaaS (CRM as a Service), AaaS (Accounting as a Service) well, you get the idea... the good thing is that we run out of options at 26 acronyms...
If we (yes, everyone in IT is responsible for this GAF situation) are unable to come up with good names for new concepts, patterns, technologies or products, we should not blame those poor IT decision makers for not understanding our value proposition. In 9 out of 10 times we are not dealing with an ignorant decision maker, but just with someone suffering from GAF.
OK, I am off for now, I am going for a BLT.
Subscribe to:
Posts (Atom)