Sign In
MSDN Blogs
Microsoft Blog Images
More ...
Thinking about SOA (again)
Common Tasks
Blog Home
Email Blog Author
RSS for comments
RSS for posts
Search
Advanced search options...
Search In:
Everything
Blogs
Forums
People
Groups
Places
Pages
Date range:
All Time
Last Year
Last 6 Months
Last 3 Months
Last Month
Last Week
Last Two Days
Tags
BPEL4WS
BPM
Compliance
e-Gov
IASA
Internet Scale Computing (ISC)
OffTopic
Process and Workflow
Service Orientation
Silverlight
WebServices-IntegrationandInterop
XML
Archives
Archives
August 2010
(1)
May 2010
(1)
September 2009
(1)
December 2008
(1)
November 2008
(1)
July 2008
(1)
May 2008
(2)
April 2008
(4)
March 2008
(1)
February 2008
(6)
January 2008
(3)
December 2007
(1)
November 2007
(8)
October 2007
(1)
September 2007
(1)
August 2007
(8)
July 2007
(2)
June 2007
(3)
May 2007
(2)
April 2007
(6)
March 2007
(4)
February 2007
(7)
January 2007
(10)
December 2006
(4)
November 2006
(10)
October 2006
(4)
September 2006
(2)
August 2006
(7)
July 2006
(1)
June 2006
(10)
May 2006
(3)
March 2006
(3)
February 2006
(8)
January 2006
(3)
December 2005
(2)
November 2005
(11)
October 2005
(2)
September 2005
(6)
August 2005
(3)
June 2005
(5)
May 2005
(5)
April 2005
(5)
March 2005
(5)
February 2005
(1)
January 2005
(3)
December 2004
(7)
November 2004
(10)
October 2004
(1)
September 2004
(4)
August 2004
(8)
July 2004
(2)
June 2004
(12)
MSDN Blogs
>
Loosely Coupled Thinking
>
Thinking about SOA (again)
Thinking about SOA (again)
John_Evdemon
17 Dec 2004 6:29 PM
Comments
3
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.
3 Comments
WebServices-IntegrationandInterop
,
Compliance
,
Service Orientation
,
BPEL4WS
,
XML
,
e-Gov
Comments
Harry Pierson's DevHawk Weblog
15 Feb 2005 12:32 AM
Harry Pierson's DevHawk Weblog
20 Mar 2005 10:07 PM
Loosely Coupled Thinking
15 Aug 2006 1:21 PM
Patrick Leonard nails it rather succinctly.  ESB is an EAI pattern (not a product) that may not...
Page 1 of 1 (3 items)