Trevor Fyfe asks the pIT stop panel:

Software providers are incorporating service-oriented architecture (SOA) into their applications, but should companies that buy those applications but do very little or no development at all be introducing SOA themselves?

The pIT stop panel’s replies:

To begin an answer to a question such as this, we must fall back on those rules which govern the adoption of any new versions of software or change in hardware. IT exists to support the business and drive increases in efficiency. Therefore, any adoption of new architectures or new methodologies must only be done if the perceived benefits will truly be a value-add to the business; this in itself could be said to determine whether or not SOA is introduced, regardless of whether the development is done in-house or not.

Furthermore, given the modular approach to SOA, the answer can depend on the industry. There are some vertical sectors that perhaps are better served with off-the-shelf software than others and this too has to be factored into the equation as it may well be that in-house development is not needed on any large scale.

For those that wish to, or are compelled to, in-house development need not be the overhead it sounds. Given proper implementation of services, the standardised, non-proprietary approach enables relatively easier integration of new services into the infrastructure. Provided too that documentation is done properly, standards are agreed upon, and so on, as with any major change of approach it comes down to return on investment. Will you yield the return? As ever it depends on the software bought or developed, the hardware on which it is run - yes this can be important - and the people who develop and implement.

By Intel

The simple answer is yes. The longer answer is that SOA helps businesses integrate their applications and also makes the task of configuring them to fit particular business process much easier - and many more businesses will configure applications, compared to the number that customise them or develop them from scratch. As such I recommend that every IT department has a strategy for SOA.

Almost every business application that a company buys will need to be integrated with other applications used by the company and across a range of business processes. Imagine a business process such as order-to-cash without some form of integration across the supporting applications. SOA is now the key to making applications easier to integrate. Being able to change business process without major application changes is also the promise of SOA, and another reason why businesses need to consider it. So, for a pure technical sense SOA needs to be part of the framework of every IT organisation.

However, there's an aspect of the question that disturbs me.

"Introducing SOA" is strange idea, when taken in isolation. The real need is for IT and the business that it supports to have a strong relationship, with IT supporting the business and a strong alignment between the two. This means setting out strategy together, with a common set of goals and agreeing how those goals will be delivered and measured. SOA can, and should be, part of the vocabulary that is used to create that strategy and define how the business and IT interaction works, with IT delivering a number of services to the business. SOA can be the framework that helps IT and business, together, to decide if doing little or no development is right, whether it is right to install standalone package applications and a whole variety of other questions.

By David Mitchell, senior vice president of IT research, Ovum

Major application vendors, notably Oracle and SAP, are building standards-based SOA into their core platforms – for both internal integration between components and external integration with other applications and services. A customer could theoretically ignore SOA, and simple “license the application”, but that would be a missed opportunity, as well as leaving you at the mercy of both the vendor and expensive consultants; successful application deployments involve skills transfer between vendor and customer. Even SAP Business ByDesign, for example, a new end-to-end, integrated application suite designed for mid-sized companies with few customisation requirements, is SOA-based.

Building at least some level of SOA competence is the best way to ensure that the customer is in control of their own environment. It’s also important to note that very few organisations choose single vendor strategies when it comes to business applications – even companies that do pursue such a strategy usually find that merger and acquisition activity or adoption by “rogue” business units will require them to integrate with other applications.

While SOA holds out the promise of modification by configuration rather than code, there is no substitute for having skilled people on the team who can understand both the application infrastructure and associated business rules. SOA can foster a more productive conversation between IT and the business. Organisations should not necessarily invest in SOA just because they are choosing a new application package – but they’ll likely be able to offer better services to users if they do.

By James Governor, co-founder and principal analyst, RedMonk

SOA is one of those topics that has been discussed by IT decision-makers and bandied about by IT suppliers for so long that it’s meaning and purpose has almost got lost in the fog of good intentions (and sometimes bad implementations).

It has become a concept that people perceive to be complex and difficult when, put simply, SOA should be all about simplicity.

The aim of SOA is to reduce complexity in your IT infrastructure by offering tools and best practices to ease integration between software applications – whether developed in-house or purchased as a package. The concept is all about reducing IT development to its constituent parts and creating modular software systems with components that can be re-used, replaced or updated without affecting other functions. It is the antithesis of old, monolithic software applications that require enormous amounts of complex maintenance and are a pain and a business restriction every time they need to be changed.

So, on that basis, if you are a major user of software, you’re going to want to understand SOA and how it can benefit your IT strategy. Even if you almost exclusively rely on packaged software applications, SOA knowledge will help you to deliver the benefits of the work your software vendor has done to make their product compliant.

But an all-encompassing SOA strategy is not necessarily needed. Some organisations have introduced SOA by stealth – or even by happy coincidence – by adopting SOA principles each time a new system is introduced or undergoes major overhaul. A lot of IT departments that have issued a mantra of “SOA everything” have failed because the effort is simply too great.

As with any technology or trend, it has to be driven by what is appropriate for your business requirements. Having said that, what IT strategy would not aim to drive out complexity and make software maintenance easier? So SOA as a means of simplicity, integration and efficiency should certainly play some role in your plans.

By Bryan Glick, editor, Computing

Read more about the pIT stop here: www.computing.co.uk/pitstop