Service-orientation (usually referred to as service-oriented architecture or SOA) has existed now as an architectural approach to software design and development for many years. Like many ‘paradigm shifts’ in the IT industry, it has gone through its cycle of novelty, hype and maturity. The hype of course brings with it the pernicious effect of bloating expectations to the point of believing once again in the possibility of at last having found the illusive silver bullet to lay waste to all our IT ills. It also causes many organisations to (attempt to) adopt it when they have yet to fully understand its objectives, methods and most importantly its requirements.
Too often many organisations give up on their service-orientation initiatives, exasperated by the result of failing to manifest any of the benefits the approach promises. Central to much of this failure is the lack of a universally accepted definition of what exactly SOA is. If one speaks to several “experts” one is likely to receive as many definitions of what it is, with an equal number of “ways it should be done”. Certainly each of the responses will contain common threads – composable solutions based on loosely coupled, autonomous business services etc – but the responses will also usually differ in considerable extent. These differences can often be attributed to the scope with which the answer is given.
Technical points
For example many discussions on service-orientation dwell largely on the technical aspects. Such discussions will generally focus on the platforms, enterprise service buses (ESB), web services, application servers etc., which of course is appropriate but should nevertheless only represent part of a much wider scoped discussion. When such narrowly based discussions are held with organisations possibly considering a service-orientation initiative for the first time, they can be left with an extremely distorted impression of what it is and how it can be employed. All too often companies invest in an ESB, web service-enable an existing application or build and deploy a few web services to solve some immediate need, and declare themselves service-oriented. These organisations soon find themselves asking the question “so how is this better than anything we’ve done before”?
The benefits promised by service-orientation, organisational agility, increased interoperability, reduced IT burden etc., are lofty objectives and ones surely worth striving for. But these goals also represent the goals of many other earlier paradigms we have seen in the software creation field. The reality is that for organisations that to date have managed to produce poor or mediocre software, using whatever approach they do, they will most likely continue to do so using service-orientation. The problem is not with service-orientation but with the organisation’s understanding of it and its comprehension of what needs to be done to adopt it successfully.
Too often service-orientation initiatives are driven by technical personnel who have been made aware of SOA and all the benefits it promises to bestow on any organisation adopting it. Unfortunately, initiatives driven by purely technical motives seem destined to fail. Granted web services (a technology commonly used in service oriented solutions) offer service-orientation a technology, based on non-proprietary standards, through which to deliver solutions that have unprecedented global acceptance among platform vendors. This is an exciting area for the techies and is certainly a technology that will no doubt adorn the IT arsenal of many, if not all organisations before long. However, as mentioned earlier, solutions following a traditional silo based approach to building and deploying services to address narrowly focused (immediate) concerns deployed to an ESB, does not constitute a service-oriented solutions. To have the strategic advantages of service-orientation the initiative must find its place within the organisation. It must also be understood that for some organisations this place might not yet exist.
Laisser faire
Many organisations that have a software development function still maintain a laisser faire approach from a management perspective. In many cases the management of the software development remains in the hands of largely technically focused people. The end result is usually a patchwork of tactical solutions built largely with a developer-led approach. Whilst these solutions may meet the immediate concerns of certain stakeholders e.g. the users and developers, they largely do not concern themselves with other stakeholder concerns e.g. those of owners, partners, customers, maintenance teams, administrators etc. Many of the concerns of this broader set of stakeholders will be strategic in nature e.g. How will the new system “fit in” with what we already have? How easy will it be to adapt the new system to changes in the way we currently operate? How can we expose the new system to partners or customers to allow us to generate revenue or develop or enhance our market presence?
To address these broader strategic concerns organisations need to develop a more formal systems engineering approach to their software creation function. This approach will require the application of both management and technical processes to produce solutions that will best meet the diverse set of concerns of this wider set of stakeholders. For many organisations the irony is that they may very well possess the management skill sets but these have not been applied to the management of the software creation function. For these organisations a change is required to bring together these two disciplines to structure the required multidisciplinary systems engineering approach. As we all know change is hard and the effort required to effect it successfully should not be underestimated.
Technical domain
Whilst service orientation has the wider scope embracing both the managerial and technical aspects of systems engineering, SOA (i.e. the architecture part) rests squarely in the technical domain. At its heart SOA is an architectural approach to software solutions that aims to insulate an organisation from the ill effects of having to adapt those solutions to accommodate change. This is what is known as organisational agility in this context. The change to be accommodated can be foisted upon us from an external source, e.g. new statutory regulations requiring a change in our process or reporting requirements, or internally, e.g. process change to accommodate increased efficiency, requirements to expose existing products or services to a broader set of sales channels, etc. The point is not the reason for the change but that change itself must be accommodated. An SOA for any organisation must have as its central tenet the objective of immunising its solutions as much as possible from the effort required to support business driven change.
Service designed
The agility offered by service orientation will not come about through the use services alone. Solutions produced that employ web services will not be service oriented in and of themselves. To be service oriented, the services comprising any solution will have to be designed as such. At a very simplified level this means that they will have to be designed in accordance with an organisation’s service-oriented reference architecture and in accordance with the design standards and processes defined for the organisation. These fundamental artefacts and processes will be purposefully designed to ensure that what will be built will be a growing number of services that represent a service inventory from which the organisation can assemble its software solutions. Through purposeful design the service inventory will comprise a collection of intrinsically interoperable and composable services that accurately reflect the semantics and business of the organisation.
To embrace the strategic objectives outlined earlier an organisation’s SOA will need to embrace patterns, principles and industry standards at an unprecedented level. For many organisations new practices and project delivery methodologies will need to be embraced. From a technical perspective a fundamental and key requirement for any organisation wishing to successfully adopt service orientation, is the development of a common understanding of SOA among its technical staff. Despite much rhetoric to the contrary this is not as common as one would hope. At this stage of maturity there are excellent reference works, courses and tutorial available. Organisations would be well advised to review these with a view to selecting the appropriate course to develop its own knowledge of SOA.
Strategic goal
As outlined here, any organisation wishing to successfully adopt service orientation will face a range of multidisciplinary challenges. The benefits promised by service orientation certainly do position it as a worthy strategic goal for any organisation. The current economic downturn is one which we would all prefer to have missed but it is not without its opportunities. At this stage many organisations have adapted and continue to adapt on a tactical front. From a strategic perspective, it does offer us the prospect of developing our internal resources through training and education to allow us to better cope in the longer term. This may be the perfect time for the purse holders to pursue such strategies and, at least to some extent, part with their (to date understandably) parsimonious proclivities where education and training is concerned.
Ltd
