Service oriented architecture (SOA) should be defined with an emphasis on service if its benefits are to be fully realised. This extends to the culture surrounding SOA implementations, which are often too focused on architectural rather than service priorities.
This is the view of Andy Brauer, chief technology officer at Business Connexion, who says that service should be the point of departure when implementing an SOA in government, and not technology. “Service orientation is here – ATMs and internet banking are examples of the concept in action. The problem is that too often SOA implementations focus on the infrastructure rather than the service requirements.
“Government must clearly define what it wants from a service perspective, and not only from an architectural perspective, or it won’t see the benefits,” he says.
Brauer adds that SOAs should not be too tightly coupled or their potential for agility and flexibility will be limited – and these are key requirements for future systems. “The future belongs to those who can master services composition and ubiquitous connectivity,” he says.
A lack of acceptance is another danger facing SOA implementations in government. As such, a thorough change management process and a team that works to ensure proper buy-in from both the users and the IT team are essential.
But winning favour with users is only one of several challenges, as a number of technical hurdles also face government SOA implementations. These include designing one multipurpose service that satisfies all users; obtaining a local environment of a quality that is ready for a network connection; designing and implementing high quality, relevant and localised content and services; setting up a balanced support operation; and keeping up with developments in the commercial market.
It is also important to understand legacy systems when planning an SOA implementation. “In cases where the legacy system is not already service oriented it is important to be able to migrate the legacy system to service oriented delivery,” Brauer says.
Additionally, moving in too much of a proprietary direction can be limiting: “There are many different types of systems in the real world, and proprietary architectures will restrict government’s flexibility and its ability to work with the service delivery concept,” he adds, noting that earlier this year the South African government committed to implementing software based on open standards.
The benefits of SOA are that it optimises processes, breeds efficiency and improves service – infrastructural spin-offs with favourable financial implications. Additionally, reusable code gives government agility and flexibility from the back-end and allows it to adapt quickly to changing conditions.
Brauer says that the first step towards a successful SOA implementation is deciding whether or not it is a necessary step. This requires a thorough assessment of resources.
Following this, there are a few guiding principles: “It is important to start small, with a pilot project, before attempting larger implementations. The pilot implementation should also provide access to the whole organisation and be based on open standards. Finally, it is necessary to understand that SOA is not an overnight solution but rather something that evolves and grows and requires continuous attention,” he says.
Brauer asserts that SOA is not only appropriate for business and that focusing on service delivery rather than architectures is an invaluable decision for government as well. “With the right service delivery mechanisms in place government can assist the economy with SME business support. SOA allows government to introduce new services and react quickly,” he adds.