Thinking about SOA (again)

  • Eventually we’ll stop talking about SOA and go back to talking about Architecture.  When we stop talking about SOA it will finally become a reality (who talks about 3-tier architectures anymore?).   Thanks to Harry for this one!
  • SOAs are like snowflakes – no two will be the same.
  • SOAs will most likely be built using web services (but building web services will not necessarily result in a SOA).
  • The most valuable services will be used in ways in which their original architects never intended or expected.
  • A specification without an implementation is a hypothesis and should be treated as such.
  • SOA is not new.  CORBA, DCE, DCOM and EDI were all early examples.
  • EDI may have provided the first example of SOA principles (e.g. document-centric, loosely coupled, etc).
  • SOA is not web services
  • SOA is a design philosophy, not a technology or a methodology
  • SOA does not enable or ensure the alignment of IT and business.  The IT industry has been promising this for decades –there is no silver bullet for aligning IT and business.  Alignment of IT and business is an organizational issue that will not be resolved by an architectural design philosophy alone.
  • Service Orientation (SO) will happen in your organization in one of two possible ways: chaotically (typical approach) or in a disciplined manner.  The path your organization takes (and the cost of later fixing that path) is up to you.
  • Companies that fail to adopt SOA will be less competitive in the marketplace,
  • SOA is a means for realizing loosely coupled business processes.   Loosely coupled business processes (not services) are the key to an agile organization.
  • SOA is a means, not an end.  Opportunity emerges when a SOA is used.  
  • A service’s value is equivalent to the number of business processes in which it appears.
  • Services are not Distributed Objects
  • Business Processes are not Distributed Objects
  • Distributed Objects and Legacy Systems should be cleaved into services
  • If you set out to “do SOA” you will fail.  All IT projects have the objective of improving the performance of the enterprise – there is no point for the IT project to exist otherwise.
Comments (3)
  1. Patrick Leonard nails it rather succinctly.  ESB is an EAI pattern (not a product) that may not…

Comments are closed.

Skip to main content