When existing applications are adjusted to expose granular business functionality, we refer to that as exposing “services”. More specifically, exposing business oriented web services – business transactions or small components of business functionality are exposed for use by different applications.
Example – The company’s primary Customer Management System contains the customer data. A customer may call the customer service number and request a change of address – with the customer service representative accessing the Customer Management System to perform the task. However, if the company decides they wish to add the ability for customers to self-change their addresses in the Customer Website, exposing the change of address function of the Customer Management System for access by (integration into) the Customer Website is the way to go.
This is Service Oriented Integration - a subset and building block to SOA, Service Oriented Architecture.
When we begin to model new applications (or major functionality changes to existing applications) as granular business services with standardized interfaces, combined together to present a larger group of business operations, then the IT systems have entered the realm of true Service Oriented Architecture.
Service Oriented Integration:
- Targets “Integration Spaghetti”
- Moves integration logic out of the applications into the central integration space.
- Creates integration reuse.
- Allows for composite functionality – composite services.
Service Oriented Architecture aka Enterprise SOA:
- Changes the Application Design Pattern
- Targets Narrow Business Functions with matching IT System Functions
- Decomposes traditional systems into their business processes.
Service Oriented Integration often starts with developers grabbing the latest tools to ease integration. When it becomes an enterprise effort it moves to ‘just a better middleware’. With maturity and proper management it moves onward to an improved integration pattern.
Service Oriented Architecture aka Enterprise SOA presents a new application design pattern focused on creating service components which are effectively (either by manual coding or by tools such as BPM and Portal tools) assembled into applications. By extension it creates a new business to IT interaction pattern, as IT starts talking to the business about granular business process functionality rather than about departmental functionality.
Later, as the business reorganizes business functions, IT gains a similar capability to reorganize the IT ‘systems’ via the assembled service components.
This is the end state goal of Generation 1 SOA. Generation 2 SOA virtualizes the the component deployment environments (the Cloud) and fully utilitizes underlying supporting IT or even business functionality. A very logical repositioning of Generation 1 SOA goals against the evolving state of IT resources.