First thoughts on the Oracle Database Machine in Australia

Well its been a little over 4 months now since i started been involved with the Oracle Database Machine or DBM as i will call it here. The DBM is Oracle's first foray into the hardware appliance market.

In this tough economic climate its no surprise that every organisation wants to drive cost out of the business, in the front end and especially at the back end. The DBM couldn't have arrived at a better time to the market for our customers, here is an appliance datawarehouse designed for massive throughput from loading data, executing queries and presenting the important business intelligence back to the business. Speed in everything is essential but speed alone doesn't reduce costs, the real value in the DBM is the fact its an appliance. This is underrated IMHO especially now in this economic cliamate.

This week i needed to re image my laptop, Oracle gives you the option of Linux or Windows and being a secret techno i thought i would give Linux a try. Now i used to dabble in Unix but it was 20 years ago, and i was hoping not to venture near the text based utility vi. Anyway Linux did install pretty easy, actually i was surprised but then when i wanted to tailor it with dual head display, tool bars, gadgets, desktop search and adobe air for tweekdeck (the coolest twitter app) i suddenly realised all is not what it seemed. Suddenly i was thrust upon with desperate searches to see how to install RPM/BIN and remembering syntax for commands that mean nothing to me like chmod, bash and sudo. Wow i cant tell you how many hours i have sat at home getting this just right. Its hard since building Linux desktops isn't my profession so i wasted a lot of time taking in the knowledge of configuring a Linux.

This now takes me back to the appliance concept and specifically the DBM. Customers initially look at this box and dont appreciate the sum of the parts is far greater than any bill of materials can suggest. The DBM contains 8xHP DL360's, 14 Exadata Storage Cells with 12 disk in each, Infiniband,Oracle Unbreakable Linux, Enterprise Edition Database, RAC and Partitioning. So if you wanted an new warehouse and went to the effort of procuring the hardware, software and then looked and building the hardware units, loading drivers, os, database, RAC and ensuring its all up to date you are talking abut serious hours here. And in reality for most organisations its months not hours because your never going to dedicate resourcing 100%.

In these economic times we need to look at efficiency and productivity closer than ever. IT departments are there to make sure the user community and the business have the tools at their disposal to be productive, to automate repeatable processes and build a secure and compliant infrastructure. Its such a drain on resources to build a linux desktop as in my case or to procure a crate of hardware and a library of software to build something when you can just plug in an appliance.

The DBM offers great value when you consider Oracle with HP has done all this work for you, you can then focus on getting the most out of your new datawarehouse with new queries for the business, better ETL performance and headroom to cover the expected growth when the world recovers.

So today i have just touched on the appliance value of the Database Machine, over the next few weeks i will look at what really makes this box scream. The "Secret Sauce" will be my next post when i will discuss how the Storage Cells in the Database Machine are accelerating customers queries by factors over x100 times.
 

The Oracle Database Machine

Project Management Pitfalls within SOA

Hi everyone. When the request came through to address the topic of project management within the context of SOA (our sixth part in our 10 part series), we could not think of a better person who works at the coal face, as Anton Gouws. Anton is our SOA Domain Lead for Oracle Consulting in APAC...

Project Managers: Know thy SOA

I have come across very few people that have really understood that SOA is not about solving an integration problem, but really about solving some very fundamental business issues (e.g. business agility, reduced maintenance cost, visibility of information, etc). Once people understand how a Services Orientated Architecture (with the focus on Architecture) is able to do this, their whole approach to implementation is changed. This is not rocket science but so few project managers (and customers) really understand this and it often leads to a host of SOA Implementation failures. For those of you that are still in the dark, I would urge you to have a look at the following SOA Video on YouTube.

Not understanding the principles of SOA by Project Managers often results in the following 2 key SOA Project Management mistakes. Now there are plenty more, but these are really fundamental to most issues:

Mistake 1: SOA without the Architecture
I can recall many Oracle Application projects, where I have been called in to help the team with their SOA implementation. On arrival at the site it becomes very apparent that this “SOA thing” is being equated to solving their integration issues. The Project manager also typically thinks that they are delivered on their SOA project commitments through the service enablement of the integration touchpoints. In my mind this is a BIG mistake, a massive opportunity loss for the customer and an outright project failure. On these projects rather than creating an architecture where common functionality (e.g. Credit Checking, Creation of an unique Customer across the organisation), business rules and information is available for all to use across applications and the organisation, they are perpetuating another silo’ed implementation that offers very little in terms of business agility and flexibility.
Below is a small checklist that you can go through to determine if your SOA project may not be using SOA architectural principals:

1. Your integration team has never seen the business process that their integration code is suppose to support.


2. No one is insisting on common functionality to be made available to the rest of the organisations.


3. No one is fighting about ownership of data (e.g. customers, products, assets) or who is going to pay for the development of the service.


4. No one is asking about the service lifecycle management.


5. There are no canonical data models.
   

Mistake 2: Silo’d Teams
Having worked on many SOA projects, the most successful SOA projects that I have seen, typically follows a more Agile approach to project management (typically using Scrum). I believe the reason why this approach works so well on SOA projects is because it allows people across the project to rally around a particular activity (or business process) and provides the framework for rapid iterative development. This allows all the developers and business users to collaboratively work together to get the task at hand completed and breaks the traditional boundaries between the development communities (SOA Developers, Legacy Developers, Oracle Applications Developers, etc). Although this sounds easy enough, it is actually very difficult when you consider that many of your resources may be working off-shore and in different timezones and that communication issues across geographies are plenty. However these communication barriers have to be broken down for your SOA project to be successful and the communication to flow freely between team members.

Oracle Web2.0 Event PodCasts

Thank you to everybody who attended the recent Web2.0 events in Melbourne, Sydney and Canberra during February 2009.

To listen to the recordings from the event, please select the session below.



Paul

SOA where are the skills?

Hi Everyone. We are half way in our 10 part SOA series, and I thought it apt to address our ever present challenge, skills.

A number of writers on the Net are stating that the dearth of skill in the SOA arena is one of the main contributing factors for retarding SOA adoption. Burton even suggests that the CIO should be replaced. While I agree with some of their statements, and I will discuss them shortly, I believe that the lack of skill goes much deeper than just SOA skill. I believe that with the emergence of any new IT wave there is a time lag where skills development has to catch up with the technology. Speak to any IT vendor and you will get a common answer. The biggest challenge to the marketplace adopting their software is the lack of people to implement it. SOA just adds to the complexity of the problem, as it is an approach, not a product, and requires the application of a new set of skills from both business and IT.

So how can we resolve the skill predicament we are in right now with regards SOA? Seeing that SOA requires organisational transformation, lets begin at the top, with the CIO. To successfully embrace SOA, the CIO role can be one of the most important transformation agents. The CIO though will require some key qualities, including being a visionary, being strategic and being viewed as strategic by the organisation’s leadership team, and lastly being an excellent communicator and in doing so have the ability to sell technology requirements to the business. Without this executive agent in place, SOA initiatives face a high probability of failure.

If a CIO change agent is in place, the next big challenge is to understand very early on in the adoption of SOA 1) the extent to which a SOA approach will be adopted to successfully underpin business transformation, 2) the roles that would be required, and 3) the skills gap. I have heard so often that SOA is no problem, the developers and dba’s will just get retrained! Huh? There are a plethora of roles that need to be identified, with an enterprise architect with a mandate to enforce architecture being one of the critical roles. A number of organisations do not have architects, and some are not mandated to enforce standards. Apart from the enterprise architect; roles such as integration, data and process architects, process modellers, business analysts, product technology administrators, service developers and testers, security and governance specialists need to be considered. Pooling resources and forming a SOA Center of Excellence are good strategies to discover and build skill and should form part of an official change management program. As SOA has the potential to span all tiers of an organisation, business needs to be represented and roles such as software, hardware and network specialists need to be part of the CoE. If the SOA CoE discovers that there is an incorrect skill matrix, skill sets should be developed or replaced as early on in the transformation as possible.

My last thought, for now, on skills, is the internal resource development versus external consultant debate. I have seen organisations outsource their entire architecture, which in my opinion, is IT suicide. An organisation needs to own their IT strategy; a consultant won’t do it for them. So if you do not have the time to wait for internal skill development, where could a consultant make sense? Apart from the obvious analyst, developer and architectural skill that could be injected tactically into a project, I believe that hiring a third party mentor would have a profound impact. Adopting SOA can be fraught with failure by overlooking necessary strategies like forming a SOA Center of Excellence and Governance strategy. A consultant who has experienced that journey would be of great use.

While I have concentrated primarily on “hard” skills in this entry, maybe a topic that we can explore in the future is; do organisations and employees have sufficient social skills to support a SOA approach? SOA is, by its very nature, requires social behaviour. It is forcing siloed mentalities and traditional dogma to be replaced by collaborative workplaces where alignment between lines of business and with IT is critical. So in essence evaluating cultural readines and applying organisational change management will be as important as planning for and developing hard skills. Either way you look at it, both soft and hard skill development should be planned for from the inception stages of business transformation.

SOA – Pay Now or Pay Dearly

Hi, and welcome to our fourth topic on the 10-part SOA series. My section focuses on how a lack of investment in certain areas, can hamper and potentially derail business transformation strategies that are relying on a SOA approach.

When I hear the phrase “doing SOA on the cheap” it means one thing to me, viz the fundamental building blocks to facilitate SOA transformation have not been followed or understood. There are though a number of investment-poor symptoms that I think could warn you of impending SOA troubles. I would break them into people, processes and technology.

If you look at the people issue, I think the most important aspect here is investing in time. As time costs money I often see SOA relegated to the corridors of the IT department because it is then easier to control. I believe that as a SOA approach should underpin business transformation, sufficient time has to be spent with business to understand the overall strategy, to gain alignment, to facilitate role transformation, determine project priorities and decide upon a funding strategy. In terms of funding, I have heard that the “spare bodies” in the IT department get thrown at a SOA initiative because it is “high risk”; no-one understands the concept and no-one would fund it, so SOA will start off small with a couple of trained developers or DBAs and never grow beyond an experiment. SOA needs the most highly skilled technical and business resources, including key external consultants, that money can buy. You get what you pay for in this game, and what you don’t want are unskilled consultants and staff putting your business under unnecessary risk.

If you look at process, I would put governance into this category. I hear that governance can come later in SOA maturity because it is an expensive overhead. On the flip side I have seen SOA projects grow from a concept to production extremely quickly, and without the right policies and procedures in place potentially bad development practices could quickly become the norm, and the execution of services at runtime could be unmanaged. I believe in putting down rules quickly in a process to prevent costly rework later. Debates continue at what point governance should begin to develop. I would say you should think about governance before you build your first service.

The last category that you need to look at is technology, which would include development and the SOA enabling technologies. If you look at development, developing a bunch of services is pretty easy. The more difficult thing to do is develop services for reusability. It is estimated that creating a reusable service to a base service is anywhere between 30 and 200% more expensive. The flipside is that using a reusable service in further projects reduces development cost between 20 and 80% of the cost of developing a base service. While this makes logical sense, no IT project manager will factor in increased development costs to incorporate the notion of reusability, when it might not bring them benefit to their immediate project. I think another way of tackling this issue would be to apply governance that would ensure that services are built for reusability and services form part of a managed service lifecycle and development culture.

Choosing middleware technology can be tricky. When funding is lacking, often skunk works projects are built with anything that is freely available, with little or no consideration to the suitability of the technology to the business and no understanding of the manageability of the final architecture when the middleware infrastructure begins to mature across an enterprise. Ripping middleware out of architectures is a difficult process and making a hasty middleware decision early on in SOA adoption can prove costly in the long term.

So maybe a parting thought is if applying a SOA approach on a shoestring is not a wise decision, how can you get the funding to make it happen? For any transformation initiative, business executives need to understand what is required for them to achieve their business strategy. If SOA is the right approach and will deliver the required business value to help them achieve their business strategies, and they agree to the principles, then you will have the business case and the mandate to begin to invest properly in time, process and technology.

All The President's SOA

I don't want to labour this point but it does make a nice introduction for what I want to write about this time out. I saw Paul Coby, CIO of British Airways present at a conference last year and one of his favourite phrases resonated with me, "There are no IT projects. Only business projects". He has a point. If you're doing technology for the sake of technology and not to help your customers or to improve your business then you're not doing it right. Now that's very easy for a high-flying CIO to say, how does he back it up. How, I wondered, does the thorny issue of executive sponsorship work itself out at BA?

Here's another quote for you, "There is nothing more powerful than an idea whose time has come." Victor Hugo this time. And, as I've blogged about before there is a single, simple, brilliant idea at the heart of SOA to prove that SOA's time has come, namely, building something once and re-using it is a good thing to do.

This famous quote of Victor Hugo is paraphrased in the movie 'The Contender'. As President Jackson Evans (Jeff Bridges) campaigns for his Vice Presidential nominee to be approved by the Senate he says "...there is no weapon as powerful as that of an idea whose time has come". As the nominee - Senator Laine Billings Hanson (Joan Allen) - finds out the idea is one thing,  having some executive sponsorship to back it up is another. And lets face it, there is no better executive sponsorship than that of the President of the USA.

You probably won't have that level of sponsorship for your SOA efforts, so you'll have to settle for executive rather than presidential. What do you need from that executive for your SOA to succeed? What areas do they need to think about to help and support SOA in your organisation?

I've identified six areas;

1. Business Strategy and Process: Organisations need IT implementations that support the business and its changing needs. This is all about thinking about the business project, not the IT project. This is about providing an environment that links the management and measurement of IT with the management and measurement of the business strategy. This is where your sponsor is a key sounding board and information resource. What are the KPI's of your organisation and how does your planning in IT help to achieve them?

2. Architecture: Nearly all organisations that I have worked in fund and build IT by projects in lines of business. This leaves enterprise-wide processes and integration to be considered as afterthoughts and creates a barrier to change. The A in SOA helps organisations build an IT environment based on standards, distribution, loose coupling, re-use and business process representation that is designed to respond to change and will operate and integrate at the enterprise level, the executive level.

3. Building Blocks: A lack of consistency and repeatability in IT implementation hinders most organisations in achieving their goals with respect to IT budgets and agility. The building blocks metaphor offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximising the ability to repeat successes by reusing implementations and the core infrastructure.

4. Projects and Applications: As in point 2 above, IT is traditionally developed by projects within lines of business – often creating excessive spending on duplicate functionality and compromising the integrity of enterprise processes. Executive sponsorship here helps you to catalogue, categorise, and modernise functions offered by systems and applications – standardising the manner in which those functions are offered, while reducing redundancy and promoting consistency. Duplication goes down, re-use goes up.

5. Organisation and Governance: The organic growth of our organisations has yielded an IT infrastructure that is difficult to manage and costly to change. Concentrate on creating an organisational structure and mandate - executive sponsorship needed here if you're going to mandate anything by the way - to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimise IT utility.

6. Costs & Benefits:The $64,000 question. What is this going to cost to build? How much is it going to cost to run? More importantly, what are the predicted benefits from using it? And remember, an IT benefit without a Business benefit is not a benefit at all. Key development metrics, productivity measures, reuse measures, general best practices and internal/external benchmarking. And how does all of that link back to the Business Strategy outlined in Point 1?

My Brazilian colleague Marcelo Simoes has also penned a take on this recently with his "Five-Step Action Plan for Executives". He makes several good points in his piece and I particularly like his Fifth step - The victory dance.

More Jeff Bridges to close with. You're probably not going to get The Dude to sponsor your SOA efforts. But get yourself a sponsor. One that can think big, start small and move fast.

Are you doing SOP’s instead of SOA?

Hi and hope you all had a great Christmas and all the best for the upcoming year!

This is the second blog in our SOA Governance series around a report that came out detailing the ten common mistakes in doing SOA that cause it to fail. I am going to address the second reason which is underestimating the impact of organisational change.  I am very much in agreement with this sentiment and we at Oracle, while we sell SOA technology, believe that SOA is really more a state of mind than anything else.  I also do not think this key issue that gets as much airtime as it should. In fact the mis-application of SOA at the isolated project level rather than the enterprise level largely determines whether you are doing what might be called Service Oriented Projects (SOP’s) or whether you are changing the culture and organisational behaviour with a truly transforming Service Oriented Architecture.

Well let’s get started. In any business initiative that involves technology there are three things that need to work together – people, tools and methodology. This is true with SOA but with an extra emphasis on the people component.  Actually organisational change is really at the heart of SOA.  If we go back to the beginning, SOA is all about making the business more adaptable to change. Why is this an issue? Because the processes and systems we have to support us are so rigid, so slow, so difficult to modify that they have become obstacles to future success.  These process and system difficencies have been  caused by many years of “oiling the squeeking wheel”. What I mean by that is mostly no-one has been really willing to tackle the problems at the core of the enterprise – they just focus on their particular project and seek to deliver it cheaply and quickly.  That is not bad in itself its just that each project done this way adds just a little bit more inter-system dependency, a little more tight coupling, a few more duplicated modules… You get the idea I think.

Why do we take this approach? Well its simple – the metrics by which we are measured encourage us to do so. Fast, cheap, self contained projects are viewed as successful. If we get kudos for this we do it again. Its also simpler than trying to fit in with what other parts of the organisation are doing.

SOA is about changing all this isn’t it? We want to streamline the organisation processes. We want a common set of data definitions. We want a re-usable library of services. We want common tools and consistent methodologies.  The problem should be now self evident - we are talking about cultural change as much as Web Services and XML and UDDI. Guess what is easier to do – change the culture or learn the SOA technologies?  

The bottom line is this – if you don’t try and change the culture of the organisation you are not really doing SOA.  How can I say that?  Well if you use SOA technologies and basically build a point-to-point architecture (so you don’t have to worry about any other project in the organisation) then you are not doing SOA you are doing SOP's.  You are just using SOA tools to build the same things you did before.  Is there any real value in doing that? Apart from learning how to build and use Web Services, ESB’s, BPEL etc - not really.

Is this what is happening? Have people invested in SOA tools but not taken a true SOA approach? Have they then expected to see cross organisation value that didn’t appear and then said “SOA doesn’t deliver what the vendor promised me?”

Recently on Kate Carruthers blog she spoke about why reuse fails. Guess what – its because of the psychology – its about the people – its about resistance to change - its about wanting to keep my project isolated and independent of the other.  Reuse is just one aspect of SOA (albeit an often overhyped one). To really make SOA work we need to think in a process oriented way because that’s how our suppliers, customers and partners interact with us. We need to structure our organisation around  these processes and measure the effectiveness of the lines of business in supporting them. If we do this the all IT projects are subordinate to the process and must work to make it efficient, flexible, fast and available.  Then and only then will any technology – including SOA – really deliver measurable business value.