SOA's deadly dozen

The common mistakes in adopting a service-oriented architecture (SOA) are now well understood and, with a little effort, can be avoided.

Ignoring (and therefore repeating) such mistakes can derail the entire effort you put into introducing SOA and lose you the benefits. Listed here are the 12 most common mistakes Gartner has observed in SOA implementations.

Mistake No. 1: Irrational SOA exuberance

Excessive numbers of services ­ those that cannot be readily matched to the business model of the application ­ are a sign of an SOA environment where applications need to be checked as they are completed.

Such environments may feature repositories full of services, volumes of documentation and an impressive collection of new tools and middleware, but what they will not have is agility, incremental software versioning or reuse.

Mistake No. 2: Forgetting the data

Crafting a service model is a task much like designing a data model. And forgetting the data in the process can easily result in services that perform poorly and which challenge the integrity of the application.

Strive to design services in a manner that is co-ordinated with the design model of the underlying database.

Mistake No. 3: Leaving SOA to the techies

When the SOA process is left mostly with the IT side of the organisation, services risk being designed to optimise software performance and reliability, but may not fully reflect the business requirements.

Clarity of business interfaces is essential for cross-application integration or multi-organisation use.

Mistake No. 4: Overlooking the cultural obstacles

One of the most anticipated benefits of SOA is the increased reuse of software, but achieving the expected results can be a challenge.

Cultural obstacles can derail an SOA reuse effort. For example, if an IT department suffers from “not invented here” syndrome, programmers, project leaders and architects will not trust reusable services developed by other teams, or will simply want to develop entire solutions by themselves.

“Not invented here” syndrome can result in redundant programming effort, overstaffing, and lost opportunities from a lack of available resources, and represents a major obstacle to SOA reuse.

Mistake No. 5: Making a sudden commitment

Many organisations, especially ones that believe they are late in using SOA, tend to make a giant leap from scepticism into a sudden, strategic commitment. But plunging into a large-scale SOA development effort without proper preparation and planning is usually a dire mistake.

Because service orientation is a long-term initiative, organisations should invest in developing the required understanding and organisational culture before committing themselves to mission-critical SOA projects. Gradual adoption is imperative for most firms.

Mistake No. 6: Starting in the wrong place

The most obvious starting place is to follow the business requests of the intended first users of a service. For example, if the service is requested by a user-facing application, then you might design a tool to match their data requirements.

However, such a design process may end up generating as many services as user interfaces, often leading to a redundant and ever-growing collection of services.

A more consistent, systematic and effective approach is to design a cohesive set of information services around the application’s business process or data model.

Mistake No. 7: Assuming everyone thinks like you

Having originated as a technical design pattern for advanced distributed systems, SOA is now a subject of interest beyond the programming community. Co nsider and allow for such differences when tailoring business communications at all levels.

To a programmer, SOA is a form of distributed computing in which the building blocks may be offered to other applications.

To a software architect, on the other hand, SOA translates as the disappearance of fences between applications.

For chief information officers, however, service orientation is an investment in the future. Code reuse is a means to reduce the cost and time of new application development.

But for chief executives, SOA is expected to help IT become more responsive to business needs and to facilitate competitive business change.

Mistake No. 8: Choosing dictatorship to combat anarchy

Individual IT projects, groups, divisions and domains often have a hunger for independence that might be seen as anarchy because they make it impossible to impose shared objectives on the larger organisation.

A drastic alternative to such anarchy is dictatorship, where departments and projects are forced to abide by central command.

Neither approach offers the balance required for a successful SOA environment.

A well-organised SOA environment always includes an SOA centre of excellence (COE), which involves all participants early and facilitates co-ordination between otherwise independent projects or divisions of the organisation.

The COE also minimises unnecessary intrusions on the internal processes of the participants. IT workers can then preserve their independence, while contributing to the shared and larger objectives of the organisation.

Mistake No. 9: Underestimating technical issues

SOA users must understand the complex world of middleware.

Despite service orientation’s growing popularity and the availability of SOA-enabling middleware, the risk of making wrong decisions looms large for newcomers.

Use point-to-point web service connections for small-scale, experimental SOA projects.

And if the number of services deployed grows to more than 20 or 30, then use a middleware-based intermediary ­ the SOA backplane.

Mistake No. 10: Allowing unshareable services to proliferate

Shareable services yield faster development of consumer applications, lower development costs and easier maintenance.

If the average number of services per consumer application significantly exceeds 20 ­ or fewer than 10 per cent of services are shared ­ it may be that the amount of services being shared is sub-optimal.

Mistake No. 11: Excessive centralisation

Rather than imposing a single, enterprise-wide SOA backplane, it might be more practical and politically smoother to adopt a federated approach. Here, the organisation’s SOA initiative is split into SOA domains ­ subsidiaries, business units or departments.

Each domain is managed by one business owner and one technical manager. Each also has its own specific SOA backplane and service registry, is supported by a domain SOA COE and is managed on the basis of governance policies.

Mistake No. 12: Selling SOA before you are ready

The organisation-wide adoption of SOA requires the support of the chief executive and possibly the board. However, seeking the management’s commitment to organisation-wide SOA too early can be dangerous.

By 2010, fewer than 25 per cent of large companies will have developed the technical and organisational skills needed to deliver organisation-wide SOA.

Massimo Pezzini is vice president and distinguished analyst at Gartner

Best practice tips for a successful SOA project

*Recognise that reuse is not SOA’s only benefit. Other advantages include clarity of software design, the development of software in increments, more efficient deployment and maintenance, and an increased affinity between business modelling and software design.

*In the early stages of integration, develop best practice for the design and management of SOA-style projects. For the long term, plan to invest in dedicated infrastructure and productivity tools to
ensure you get the best results from your SOA efforts.

*Invest in the systematic design of core tools before opening the application to the creation of rapid,
opportunistic services.

*Think long term, but act pragmatically – and gain maturity through smaller-scale projects, with frequent milestones and metrics along the way.

*Ensure that business-modelling analysts are involved in the design of services, and that services reflect business functionality rather than technical partitioning of software, where appropriate.

*Promote a culture of sharing and collaboration throughout the organisation.