Joe McKendrick wrote: "...  And, let's face it, SOA would be 
downright boring (make that Boring with a capital B) if it was just 
another means of app or systems integration, and nothing more."

IMO, the only reason SOA is "exciting" is because of the debates 
about what it means. :-)

SOA is just another means for defining integrated solutions. Defining 
an architecture involves several activities. (I'm sure we'll debate 
these too!)

* Identify the components, striking the right balance between too 
many components (components doing too little) and too few (components 
doing too much).

* An SO approach says that many components (most?) will be service 
providers and will have defined, published, discoverable interfaces--
for the express purpose of being used by other components to 
integrate with the service. Some components will not be service 
providers. Some components will be service consumers. Some will be 
both. Some will be neither.

* The architecture defines how the components are related, how they 
interact--how they are integrated into a cohesive whole.

* The architecture may constrain how components are to interact. For 
example, it may specify that data exchanges between components are to 
be document-oriented as opposed to procedural.

* The architecture may specify how the interfaces are to be exposed, 
which in turn may constrain how the components are defined. For 
example, the REST style.

Integration, in the general sense, is the bringing together of 
components to form a cohesive solution that addresses some need. A 
car with an engine that isn't integrated with the transmission won't 
go very far.

Architecting is an exercise in integrating components prescribing 
agreement on syntax, semantics, and other aspects. Consumers are 
integrated with providers. Consumers and providers may also be 
integrated with other components to fulfill their responsibilities. 
The integration is defined in the context of the architecture and its 
goals.

Let go of your preconceptions about integration that are rooted in 
old-school systems integration, poorly-executed EAI, solutions built 
on a tools-first basis and recognize that virtually everything we do 
strives to build integrated, cohesive, robust solutions for our 
businesses.

As always, I may be wrong. :-)

-Rob

Reply via email to