Service-oriented architectures – delivering more for less

The concept has been around for several decades, yet is only now gaining momentum as it is seen increasingly to provide the solution for many of today’s business problems. In short, the service-oriented architecture (SOA) has become a buzzword with bite.

Today, businesses are faced with a 'double whammy' in terms of IT investment. On the one hand, budgets are at best rising with inflation and at worst shrinking. At the same time, the business overall is putting greater demands on service delivery. The result is that IT departments continually have to achieve more with less.

By making it easier to deploy applications across the architecture therefore – the heart of SOA – it becomes possible to provide a more beneficial service to the end user, both internal and external, more cost-effectively.

Yet, like many promises for newly-emerging management tools of course, this is easy to say but harder to achieve. Does the combination of improved internal efficiency and external customer service remain a holy grail – tantalisingly out of reach – or does SOA make it readily achievable?

Reducing complexity

There are a number of more or less complex technical definitions of SOA which have emerged over time, but a practical, working definition might be summarised as follows: in looking across the organisation, SOA seeks to eradicate duplication - particularly in the area of processing – and consolidate these similar areas of execution in one place.

For example in the case of quoting calculations: an insurance company may have, five in-house built illustration calculations covering products as diverse as life assurance and school fees planning. As a customer therefore, depending on the policy required you would be connected to the appropriate team, each with their own internally-built illustrative applications. As a result, there may be as many as 20 teams, with 20 different sets of infrastructure, fulfilling 20 different –but parallel – functions across the organisation.

At the next level down, each of these is likely to have its own separate form of address look-up and printing document capability, policy calculation process and so on. The goal of SOA is to build each of these up into a defined process that more than one department, team or project can utilise, so saving the organisation time and money.

Again, in a typical distributed enterprise with, ten offices worldwide, the chances are that there will be ten similar – but again different – order processing systems, utilising different applications and data, each putting significant demands on the infrastructure. If, therefore, you are able to integrate your various front-office applications with the central quoting process, the resulting single global pricing calculator will effectively deliver an SOA for that particular organisation-wide process.

The primary goal in each case is to reduce the complexity of the infrastructure, in order not only to reduce the internal time and cost of administration but also to improve the user experience. Customer addressing is a crude but illustrative example. You may use your bank for many types of service, checking and savings accounts, ISAs, share-dealing, mortgage and so on. If each team within the bank holds separate address details the likelihood of mistakes is greater.

Web services

Application-level communications protocols such as Simple Object Access Protocol (SOAP)-based web services are becoming the most common implementation of SOA, though some non-web implementations also provide equivalent benefits.

The creation of customer maps provides a straightforward example of web services in action. In order to determine how to get to a customer location, you would typically cut and paste the postcode out of your CRM application, launch a web browser, browse through to Streetmap.com or MapQuest.com, for example, paste the postcode into that web environment and undertake a web-search to produce – and then print - the required map.

With web services, each time you visit a specific client account, go to a web server: this will automatically push the postcode to that web server and feed the results back into the window, giving you all the information you need instantly. By removing the need for manual processing, this both saves time and reduces the risk of error.
Similarly, if there is a requirement to install a new account application, organisations have typically got rid of the old application and started again from scratch. Yet with newer generation tools such as FrontRange’s business process engine within a .NET-based foundation, this is no longer necessary. By utilising the concept of a library, it is possible to incorporate an established web service or business process within the new application.

So, for example, if you have an existing process for automatically emailing customers, this piece of code can be extracted from the library and incorporated in the new process. Using these ‘building blocks’ both saves time in building up the new process and reduces the risk of failure.

What now makes this possible, bringing SOA to the fore as a practical solution, is that there are now a set of established standards for web services, including SOAP, XML and WSDL. Thus, if you build an XML process within, or an XML gateway into, an application, the likelihood is that it will be possible to write data to communicate with that application.

Business needs

Though the drive for general business efficiency has been ever-present, much of the original impetus for SOA solutions was – and still is - from large enterprises suffering from infrastructure overload. In the case of a merger between two large financial organisations, for example, the fall-out in infrastructure terms is huge, with the imperative to simplify a complex mix of technologies and business processes.

More recently, what solutions such as the FrontRange Foundation have been able to do is to bring the necessary level of data integration to achieve this within reach of smaller, distributed enterprises.

Today, however, there is another issue driving the need for deliverable SOA solutions, namely the increasing demand for compliance. In the past, in order to achieve regulatory demands, each individual application would have to be changed separately – a costly and time-consuming exercise and one prone to error and omission.

By contrast, if you only need to change one element of the web service to comply, then any application using that service will automatically be compliant. This streamlines the infrastructure, speeds up compliance and makes the business more effective, and thus competitive.

From a technology standpoint, the building blocks are, for the most part, already in place, as most applications are capable of utilising XML, SOAP or WSDL standards. With this level of organisation around the delivery of SOA, it is now much easier for independent software vendors to develop solutions inline with these established standards.

As a result, the focus is now one of looking at the nature of the business problems of the end-user and recognising that, where relevant, SOA is a viable and realistic option. Thus, if the problem is the inability to produce quotes quickly enough, or that the majority of the IT budget is spent on keeping the business running rather than proactively advancing the business, then the solution is likely to require an SOA-based infrastructure.

Benefits to the business

From a back-office perspective, the benefits centre on getting more for less – physically requiring less from the infrastructure in terms of servers, server capacity and capability for example, at the same time delivering a better service.

For the individual user, a SOA provides a seamless, real-time, role-specific view of the business as the basis for better-quality decision-making, by bringing together diverse databases and applications from across the organisation.

Looking ahead therefore, SOA solutions offer a simplicity of approach with real potential for growth. Businesses simply cannot continue to add more servers, application servers and databases to their existing systems for, by common consent, greater complexity has not brought with it increased service quality.

So where are we today? With IT budgets typically tight, it is rare that approval would be given to completely rebuild a company’s order processing capability for example. Similarly, it is unlikely that a business would ‘start from scratch’ in implementing an SOA-based solution: much more likely is a step-by-step approach.

In any purchasing strategy therefore, the first stage is to ensure that chosen applications have open standards, are XML-compliant and are capable of making data visible to other parts of the organisation. Over time, the business can then look to link business processes as an evolutionary way of achieving SOA.

An integrated approach from FrontRange

At FrontRange, the current roll-out of our next-generation suite of products is based on a single, .NET-based coding platform, with SOA delivery very much front-of-mind. Thus, in looking at the data structure, every address within any application built on this foundation is held in the same place on the data store.

As a result, the information is stored once only, with no need to re-key the information repeatedly in individual data stores around the organisation. Fundamental to its development has been the concept of web services, with a centralised data store, a meta-data driven architecture and utilising the latest business processing standards (e.g. XML and DTML) and communications standards such as SIP. By focusing on open standards in this way, we can integrate with almost all data within the organisation and so provide users with a roles-based view of the business – the centre of an SOA solution.

As highlighted earlier, businesses are looking for evolutionary solutions which protect existing investment: existing HEAT customers therefore can acquire individual modules of the new solution set, together with the foundation which effectively gives them the key to unlock FrontRange’s SOA.

FrontRange’s ITSM solution offers a typical example. Most organisations today have a sound understanding of incident management, addressing the issues raised by their user community in a way which seeks to fix the individual problem and rapidly get the user up and running again. Yet though they are good at ‘firefighting’ at the incident level, with the increasing complexity of IT infrastructures they have been less successful at the level of change management.

By managing change in a controlled environment, the number of incidents will be reduced, creating more up-time internally and providing users with a better service. For a FrontRange customer this change is both straightforward and seamless. By acquiring the change management module based on the common foundation, this integrates out-of-the-box with their existing HEAT product set.

The existing investment in HEAT is thus protected: at the same time, those managing the change process using the new FrontRange solution will have full visibility of all incident data, together with other data essential for the change process throughout the business.

Evolutionary rather than revolutionary perhaps, but delivering measurable benefits every step of the way.

By Alastair Trower, FrontRange Solutions

www.frontrange.co.uk