maandag 27 april 2009

The seven challenges for Oracle

Oracle is moving towards the biggest provider of all software in the market, by means of smart acquisitions and a simple aim what they want. The aim of Oracle is to be bigger than SAP and IBM. I identify seven major challenges for Oracle the coming years. All challenges need to be guided by a sound roadmap towards the future.

What are the challenges for Oracle (and therefore also for Oracle partners and clients) the coming years:
(1) Integration of all products
Of course this is a no-brainer, and is a tough job. The roadmap helps in identifying integration points between the products to be integrated and still enabling growth for these individual products in parallel.

(2) Offering a roadmap towards the future
Last year, at the first of Juli, Oracle presented the acquisition of BEA with an excellent webcast, showing the preferred product stack for the future. Also included was a roadmap for the 100 days following the webcast which contained integration of some major BEA components into the Oracle stack. The 11 version of the technology stack would be a new milestone in the Oracle technology stack, but still is not in production and not clear what the choices are.
What I'm missing now is a decent roadmap for the future. Being a solution/software architect I need to know what is happening the coming years with a product stack when I propose a solution to one of my clients. This roadmap should contain product information, timelines and migration strategies for keeping track with the technology stack. Important is that the roadmap should not start from today, but also contain all 'old school' products of Oracle.

(3) Keep the 'old' Oracle customers on board
The impact of this fast change is that all existing clients (for instance 65K Database clients in EMEA only) see Oracle speeding away over the horizon. With the help of the roadmap we can help them move in a controlled pace towards the future, and not only for technology sake, but adding business value to their landscape.
Oracle should invest in migration tools helping the customers move towards the new technology stack. And not, as I've heard a product manager say, well open the 'old' and 'new' environment on two separate PC's and start typing... ;)

(4) Challenging other database products
Oracle is the market leader in the database area. This area however is getting commoditized more and more. Electricity was once a specialized product, but now you just get it 'out of the wall'. Speed, stability, availability and storage costs are an issue in the Database market, not extra functionality anymore. Since software is slower then hardware maybe Oracle should create hardware based Databases, on the new acquired Sun systems, with extreme speed and cheap in price. Another option would be offering the Database available in a Cloud.

(5) Challenging Open Source
In the Open Source market, more and more products are standardized and growing in experience. Products like MySQL and JBoss have the potential to be used in all types of core applications. One of the biggest advantages Oracle has over Open Source is that they can provide support and the likelihood that they will keep on existing during the lifetime of an application, and longer. Again here the roadmap is essential in providing information to clients when (not to) choose for Open Source.

(6) Challenging IBM
There's one thing where IBM beats Oracle, and that's architecture. IBM however has also the same problem as Oracle with their technology stack. They've got an extensive product stack with, not always, the best alignment among product components.
Oracle has got the opportunity to shape out a new landscape that is based upon a strong architectural base and is in complete alignment. The roadmaps shows the speed of shaping out this new architecture.

(7) Challenging SAP
SAP beats Oracle with Industry solutions. But with the introduction and work with the Oracle Application Integration Architecture (AIA) Oracle catches up with SAP. Oracle asks partners and clients helping with creating new AIA industry patterns. Here the roadmap can show the speed of development of patterns across industries. Advantage of Oracle over SAP in this arena is the momentum of development of the new patterns. SAP is struggling now with implementation of their SOA strategy and wether the choice of Java in their environment was a good one.

Of course Oracle can't do this on their own, but with the help of partners and clients we can come a good way, by helping creating a sound roadmap which will lead us the coming years in the Oracle world.

Thanks to Joost van der Vlies and Ruben Spekle

woensdag 15 april 2009

The four ‘FIT’ factors, making a Business Case for Open Source and Vendor products

Open source is hot in the market. It is free and you don't have vendor lock-in. True, a landscape based upon 100% dependency on one vendor can cause situations where your business wishes are not in agreement with the architectural possibilities (or pricing strategy…) of the vendor products. So are we better off with Open Source, where unlimited developers seem to be working day and night? As always is the answer, it depends...
So how can we decide whether to choose for Open Source or Vendor based technology?. This can be based on four ‘FIT’ factors: Functionality, Technology, Pricing and Support.

First of all, the Functionality fit has to be determined. Fit for functionality is the acceptance factor of the end users. Ability of the technology to (rapidly) adapt to functional changes also has to be checked. And the expected life time of the needed application has to be determined. How well can the needed functionality be mapped on the features of the software.

Then looking at the Technology. What is the needed stability of the application (this is related to support). What is the track record of the technology in this area. How easy can new technology be added to the stack and combined with other components. How much knowledge is available in the market. How open is the technology. How proven is this technology.

Pricing is of course also an important component. The pricing component not only consists of license- and support fees, but also development costs, and needed personnel after go-live to support the application.

Support requirements differ according to the type of application and it’s usage. This may range from an FAQ list, 24*7 help line all the way to immediate on-site support. In case of open source you should get an idea of the group developers that does updates, otherwise you may get stuck with the functionality you have.

What is the Business Case for Open Source
+ Fast delivery of add-ons and new functionality by developers community
- No timelines for new functionality
+ Push from new technology (enables new functionality)
+/- Will it still exist at the expected end-of-lifetime of the needed functionality?
+/- Code set of Open Source can be changed by Development team, what is the risk for the future and ability to upgrade?
+ No license fees
- Costs involved for keeping team of developers available for support
+ A lot of independent developers are working on the source set
- In case of emergency, who to call
- Dependency on the developers after go-live (developers lock-in....)
- No official support

And the Business Case for Vendor based technology
+ Track record of core functionality
+ Timelines for new functionality
+ Industry solutions implemented
- Marketing and sales strategy may have a higher priority than functional and technical developments
- Speed of development on new areas
+ Transactional stability (proven)
+ Track record of core functionality
+/- The role in the ecosystem as a provider of stable out-of-the-box systems is sometimes forgotten ?
+/- How well does the vendor do with regards to upgrades to newer versions/technologies?
- License and support costs
+ A good fit between functionality and Vendor based technology / Industry solution can results in lower implementation costs
+ High level of support possible

So depending on the needs of the system, the four 'fit' factors Functionality, Technology, Pricing and Support make the case for Open Source or Vendor Based technology. Any suggestions are always welcome!

Written with Joost van der Vlies, thanks to Ruben Spekle