Grid and SOA - Friends or Foes?

There has been much coverage in the press recently over two architectural approaches to technology: grid computing, where hardware assets are virtualised so that applications can share resources, and service oriented architectures (SOAs), where discrete items of functionality are created that are brought together on the fly to meet the business' process needs.

At Quocirca, we've been tracking both approaches for some time, and our view is that grid computing and SOAs fit together, hand in glove.

The trouble is, our research shows that there are differing views from with IT professionals, and that much work is required to educate users on what both grid computing and SOAs bring as value to an organisation.

Firstly, let's look at grid computing. Quocirca has carried out the Grid Index survey for Oracle on a six-monthly basis for over two years, and we have seen continued growth in understanding of grid technologies, in the capability for grid to be layered on an organisation's existing IT infrastructure, and of actual grid adoption.

Where other surveys have shown that grid is not high many organisations' radar, we find that our respondents, once grid is explained to them, find that an advanced cluster approach to grid-enabling specific areas of functionality makes sense.

That their organisation will also gain an upswing in hardware utilisation (most companies make less than 15 per cent overall utilisation of their hardware assets in a standard infrastructure) and that the better flexibility of a grid enables the organisation to be more flexible makes this approach even more appealing.

Now, implementing applications in a grid architecture has certain problems.

To make the most out of a grid, you want to be able to rapidly provision applications on to the hardware assets you have at your disposal.

By this, we mean that you may have a server that is not doing a great deal, and you have an application that is struggling with the load placed upon it.

The idea is to run up another instance of that application on the "spare" server to meet the demands placed on the application.

Easy enough in theory, but in practice? Just "running up" a new instance of SAP is not so easy.

Think how much easier it is where the "application" no longer exists, that it has been decomposed into discrete pieces of functionality, each far smaller and more flexible than the overall application.

These discrete pieces of functionality can be provisioned onto new hardware far more easily, and this is the basis of a SOA.

So, grid and SOAs go together, and that's the end of the story? Not according to our findings, unfortunately.

Firstly, the maturity of user understanding when it comes to grid and SOAs are far apart: nearly 25 per cent of respondents had no knowledge of SOAs against less than 1 per cent for Grid, and 25 per cent had a good to excellent knowledge of SOA, against 40 per cent for Grid.

We also found that whereas there was a good correlation between levels of SOAs knowledge and levels of grid adoption, when it came to levels of SOA adoption against grid adoption, there was a slightly different story.

For those who are taking small steps into SOA territory, then grid adoption is high - but for those who are taking the full plunge, looking at a full SOA infrastructure, grid adoption is low. Why?

Quocirca believes that the decision to go for a full infrastructural change is seen as high cost and high risk, and that bringing too many variables in to the mix is not seen as being a good idea.

Therefore, for those looking at a big, enterprise wide change, the decision comes down to grid or SOA. For those where it is more based around a specific project, SOA and grid can be intermixed.

But, the question still remains, for what are grid and SOA technologies being used?

Grid's history is primarily a high performance computing (HPC) one, and major uses are bleeding into finance, automotive/aerospace design and other heavy number-crunching environments.

SOA is being used to support more flexible business processes in many areas.

Is there a place for grid and SOA in manufacturing and logistics?

Yes - think of the need for new product design, of the amount of data now being used from bar codes on sub-assemblies, on pallets: think of the extra data that is going to be created as we increasingly use RFID on pallets and containers, and how all of this needs managing and reporting on.

Think of how we need to look at data and product flows up and down the value chains of suppliers and customers.

Think of how we need to be fleeter of foot than our competitors. Now look at your existing environment - how rapidly can you change a business process that is automated by your existing infrastructure?

How would you cope with a 300 per cent increase in requirements for an item through your ordering system and through your ERP system - never mind your actual production system?

Now think how much easier this would be if your total infrastructure was virtualised - all servers being able to be called upon as a single compute environment, all storage available as a single mega-data warehouse.

Then look at how easy it would be to change direction on the fly if your business processes could call upon technical functionality at will, and how these discrete pieces of technical functionality could be re-used across multiple different processes, could be plugged in and plugged out as better functionality emerges, and even as to how members of your value chain could share the same functional components to ensure consistency and workflow efficiencies.

Is an SOA based on grid a good option for manufacturing and logistics? You bet. Should you jump in to both on an enterprise level straight away?

No. Take the approach of gridding specific areas of functionality as advanced clusters with SOA capabilities, and then merge these grids together as time goes on.

You can download the PDF version of this article here