In the previous article we lay the foundation to understanding the principles of service-oriented architecture (SOA) and how they can be implemented in an integration strategy of an organisation.

In this article I will talk about how service-enablement can address business needs more effectively.

<a href=

Andrei Migatchev" />Traditionally software integration was considered a pure technical discipline and as such it was not given the necessary attention in the early stages of the project, such as requirements gathering, business analysis and software requirements specification. The first mention of integration requirements all too often only happened in the technical specification document and were related to the technical aspects of moving data from one application to another.

With this approach business analysis concentrates on the functionality of a software package in question without any regard to other applications that may have the functionality required. This can and
often does cause unnecessary duplication of functionality and data. Service-enablement calls for integration to be an integral part of the project from the very start, including all its early stages, whereby during business analysis and functional design we take into account all the applications and the services they can expose in order to fulfi l the required business functionality.

WRITE BUSINESS, NOT CODE

When faced with a business requirement, I believe one of the fi rst steps of the analysis should be decomposing the requirement into singular business process tasks or activities, then validating those against other activities and tasks for similarities.

Then, software packages that support business activities similar to those required should be  investigated to see if they can fulfi l on the business requirement and perform the activity.

An example of this could be a business requirement to enable customers to view their order status online. Traditionally this requirement would be analysed in terms of a single application, say, an ERP solution and the missing functionality would be identified as an ability to expose the information
via a Web portal. But a Web portal needs to have an authentication mechanism in place to validate a customer and ensure that no illegitimate queries are processed.

All too often we would build this functionality as an add-on to the application that has the required information, in our case – an ERP solution.

Following the service-enablement approach this can be decomposed into several activities – a customer logging on to a Web portal of sorts, then requesting a report for a specific order and then
viewing a report. Comparing these activities we realise we already have an online portal that allows customers to submit their complaints and it does perform user authentication. There is also a report in
the ERP system that allows a call centre operator to query status of the order for a customer. Thus what needs to be done is to link the two systems together rather than create the missing functionality in
either one of them.

The next step would be to analyse the technical requirements for this functional specification and identify the technologies to be used. But as can be seen, the technical analysis is now concerned with integrating the two systems and configuring web portal to include a new menu option rather than creating a complete software module that will either contain a duplicated order information from an
ERP system and then expose it to the customers online or an add-on to the ERP solution that will expose ERP reports via a Web portal.

Real life scenarios are often far more complex than the above example, but they should be approached in the very same manner. To help deal with the complexity an organisation could build a software
functionality matrix, which will assist any IT department in reducing duplication, building more robust and flexible solutions and delivering within shorter time span.

SOFTWARE EMPOWERS BUSINESS

Software is not developed for the sake of software; there is a business requirement behind every single line of code we produce. At the same time, application functionality and data should not be duplicated,
once a software package is created for acquired it should be re-used by every business process that requires its functionality, thus exposing itself as a service or set of services.