Traditionally in most development organizations we have treated the "application" as a distinct boundary, not just in terms of code, but in terms of project management, requirements gathering and so on. So, even when component technologies such as COM, CORBA or J2EE are used we still tend to act in the same "monolithic" way that we did with legacy systems development. Frequently when you talk to developers in an IT organization (or even some larger ISVs) and ask them what they do they tell you "work on xyz application", we build organizations/teams around these boundaries, we assign staff and budgets and manage schedules around development or maintenance of applications. Now, we all know there are some shared elements, usually components that wrap up technology issues and of course the dreaded shared database. So why would we say that introduction of SOA changes this in any way? Well, a number of factors in the development of services leads us to services that tend to be at a coarser grain than typical components in J2EE (and I know this is a subjective measure) and so tend to focus on decoupling dependencies with other services. In developing a set of enterprise-wide services in this manner we really develop a fabric of peer services, services that are developed independantly, developed for reuse across the business and developed defensively with contracts that define the behavior provided by the service and expected of the consumer. This fabric of services represents the basic functionality of our IT capability, but how do we bring them back together to provide end-user capabilities? Well processes provide the threads that connect together services in end-to-end flows supporting end-user requirements.
- Services; The set of business and technical functions published for reuse by processes. Services may be relatively short-lived, transactional data access elements, encapsulate business logic or business rules, or provide access to infrastructure software such as messaging, monitoring and so on.
- Processes; The flows supporting end-user requirements, choreographing services, note that a service may actually be implemented as a process, so there is a potentially recursive nature to the relationship between services and processes.
So, we see that really processes and services represent the two primary aspects of SOA; you cannot consider one without considering the other and it is the combination of service and process that really represents an application. So, we have moved from an application as a hard boundary for development to something which is far more dynamic, a particular pattern woven through the fabric of services.
This has some impact on the current organization of many IT departments - organization of development should be around the development of these services, developing them using tools, techniques and standards appropriate to their purpose (when much of the data that will be needed by services still exists in systems such as CICS). Similarly organization of knowledge should be around the processes, with interaction between the business stakeholders and IT architects focused on the precise understanding and modeling of the services that will be automated in support of the business.