Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

SOA positives and pitfalls

Jared Heng | April 17, 2008
Deploying service-oriented architecture (SOA) requires a business process management (BPM) perspective, along with organisation-wide collaboration in service development. But it can be hard to define.

SINGAPORE, 17 APRIL 2008 -- Rolling out Service Oriented Architecture (SOA) involves more than just leveraging on technology, according to Bjorn Brauel (picture), Software AGs vice president deputy CTO.

SOA is an architectural style used to drive Business Process Management (BPM), says Brauel. While having methodologies and standards to build applications is not a new concept, I believe SOA is unprecedented because it is a convergence of mindset, methodology and technology.

To achieve operational flexibility and agility, BPM models, automates and changes processes based on how the organisation, not the IT function, thinks the business should evolve, Brauel notes. From an IT perspective, that means providing flexible infrastructure to manage processes in response to change.

Paul Henaghan (picture), senior vice president webMethods, Software AG Asia Pacific and Japan, cautions about defining SOA, Deploying an ERP solution with service capabilities that subscribe to SOA principles does not necessarily translate into organisation-wide SOA deployment.

Brauel agrees, SOA is not a product you buy, but something you do as part of continuous process improvement in line with organisational objectives. He adds that SOA may also play a part in developing Web 2.0 services to give users a richer online experience.

Business case pitfall

A pitfall that CIOs should look out for when rolling out SOA is to try making a business case for SOA, Brauel says. Clearly, theres no business case for SOA by itself, and CIOs should describe SOA from a BPM perspective to other organisational stakeholders.

He stresses the need for CIOs to structure SOA around BPM, with an intuitive SOA roadmap that starts by defining a three-month business plan as a step towards achieving longer term goals. This ensures that organisational stakeholders can more quickly see business value such as cost savings arising from the SOA process, instead of having to wait for example three years before seeing ROI.

While long-term key performance indicators (KPIs) may not be immediately visible, it is very possible for short-term KPIs to be measured after three months given that the enterprise is re-using existing assets for automated processes, Brauel notes. From there, the roadmap can then project longer-term KPIs.

Balancing liberation and governance

A balance between liberation and governance is essential for service development, according to Brauel.

Too much liberation means that staff are allowed to develop services for themselves anytime without considering the needs of other organisational stakeholders. This leads to an inward-focused mindset, where service components that may provide business value are not shared with the rest of the organisation, he says.

On the other hand, too much governance can significantly stifle the creativity of staff, who may find ways to circumvent rules and regulations, he adds. Providing the right level of governance involves having clearly-defined goals and instructions for organisation-wide collaboration, while allowing flexibility on how services are developed.


1  2  Next Page 

Sign up for Computerworld eNewsletters.