With the evolvement of computing sciences and their practical implementation, software and software
design methodologies have transitioned into a new paradigm - a paradigm where service and object orientation, re-usability and communication between various applications is the main driver.

<a href=

Andrei Migatchev" />Traditionally, integration provided applications with means of ‘shared data’ exchange, allowing them to maintain their independence in fulfi lling business functions. When a requirement change was presented, existing functionality of an application was considered and then altered to accommodate the business needs. All too often functionality and data was duplicated between the applications in the organisation and integration was only considered when data subsets were required across multiple
applications.

Attempts to remedy several business requirements with the functions and features of only a single application need to be avoided, while all the software packages within the organisations need to be considered in satisfying the required business function with the middleware layer providing a seamless
communication mechanism for sharing of data and functionality.

ORCHESTRATION, NOT DEVELOPMENT

The majority of the time, considering an average organisation and all its software packages, a SOA architect is able to orchestrate a solution to a business requirement by simply re-using existing
functionality of multiple applications. New services are only created when certain functionality does not exist in any form or shape. These  services only provide the missing functionality and are not tied to any of the existing applications, but rather are added to a service respository for future re-use.

The two pre-requisites of this orchestration include the serviceenablement of applications and the existence of a solid integration platform, which will enable communication between services. These are
not achieved by simply acquiring a middleware package, but by adopting SOA principles in the software development methodology used. Only once the requirements are understood can a
decision be made to purchase the appropriate middleware.

Software integration should be considered as just another service and thus be designed as such.  Technology enables us to answer the exact requirements of an organisation at strategic and operational levels without sacrificing business functionality. Technology should not be a constraint.

A ROAD TO SUCCESS

Adoption of SOA principles and their successful deployment in every software project within an organisation does not happen overnight - it is a journey rather than a destination. Often when I talk about integration strategy and service-enablement of applications, I compare it to building a perfect house
– we fi rst start with a vision of what we want this house to be, then we architect it, including all the little details that are only relevant to us.

The same is true for creating an integration strategy; we first define what we want to achieve by adopting SOA principles, i.e. service-enablement of existing applications and their re-use, creation of a library of independent services for one or all the tiers of service architecture, or simply an ability to share functionality between various applications, without having to copy all the data across. Once we know where we’re going, we need to create a plan of how to get there – create a formal architecture roadmap, including all the details that are relevant to our particular organisation.

And now we’re ready to build our perfect house, starting with a solid foundation, then the outer walls, rooms and passages, and so on …