Re: [soa-rm] Why do we need SOA? (proposal for Introduction text)

[Rex Brooks <rexb@starbourne.com>]

Hi Martin,

This is a specific topic that was among those I 
tackled in a recent four-part series published in 
DMReview, for which I would be happy to supply 
the urls, but which I decided not to post to the 
list simply because I frown on people promoting 
their own work in lists like this. However I can 
post my opinion about these issues, which I will 
do inline.

At 12:24 AM -0400 5/8/05, Smith, Martin wrote:
>List - -
>
>I sent essentially this same message in the 
>thread  "[soa-rm] When Is An SOA Really An SOA?" 
>a while back, but got no response.  Thought I'd 
>try again to see if no-one noticed it or no-one 
>liked it . . .
>
>I'm proposing we include something like the 
>following in the Introduction.  As several 
>people have observed, we all tended to jump 
>right in to the details of "what is an SOA" 
>without nailing down the answer to the "why 
>should I [the reader] care?" question.  As we 
>learned in the f2f discussion, many of us on the 
>TC care because it's our job to explain to 
>others why we all seem to think we need this 
>'SOA' thing (other than that it keeps being in 
>the news!)  I'm guessing that if we can 
>understand why SOA has become a buzzword, we'll 
>clarify the "essential definition" question.
>
>So, here's what I think is driving SOA:
>
>"The SOA concept has emerged in response to the 
>need for an approach to application architecture 
>that is well adapted to the Internet 
>environment. The Internet has revolutionized 
>personal communications with e-mail, and 
>"B-to-C" transactions with the World-Wide Web. 
>Following the exploitation path of other 
>technologies, the Internet may be expected to 
>have a similar revolutionary effect on "B-to-B" 
>transactions - - automating system-to-system 
>exchanges - - and this domain may eventually be 
>several times larger in scale that the "B-to-C" 
>space.

I think the SOA concept actually harks back to 
the roots of Enterprise Architecture post Zachman 
in the work that grew out of his initial work, 
paralleling the "Business Reengineering" concepts 
of the late 80s and early 90s, and also parallels 
the movement toward model driven architectures in 
OMG with the advent of UML as a practical tool. 
The web makes it more imperative to develop 
specific architectural patterns adapted to web 
services--however, I do think that the primary 
basis for SOA should be spelled out apart from 
the Internet/Web context because at a more basic 
level, a Service-Oriented Architecture develops 
from the simple concept of reliable, repeatable 
services, whether that be a lemonade stand which 
needs the back end of the orchard and water 
supply, as well sugar supply chain, or the 
retail, factory-franchised automobile showroom.

For the most part we are seeing those structural 
components for the web emerging in WSRP, WSS and 
various other more or less "structural" 
specifications. Of course we do have the 
menagerie effect which the major vendors tend 
throw up in ad hoc fashion to see which 
particular concept has "legs" as in WS-* and 
others, but it looks like OASIS is the major SDO 
for this environment for this activity, based on 
XML. So, IMO, we are in the right place at the 
right time to provide the missing piece of this 
puzzle--a formaliization of the concept that sets 
those patterns.

>The characteristics of the Internet environment 
>to which the SOA concept responds are:
>
>         1.  Multiple management 
>domains.--Business or other entities "on the 
>'Net" each have their own set of policies and 
>procedures, and they are legal peers so there is 
>little or no "top down governance" in the 
>environment;

Nor should there be. This is the uncentralized, 
as opposed de-centralized structures we may need 
to encourage among previously centralized 
structures, such as GSA, which Congress, in its 
illimitable wisdom is now seeking to 
re-centralize in the name of economic efficiency 
(I think?--I use the question mark because I have 
yet to see published reasons for this reversal of 
nearly a decade of agency-centered IT 
decision-making). The chief reason uncentralized 
governance works better for the future is simply 
that it will have less of a tendency to maintain 
outworn policies and cause problems when no 
greater action is required than discontinuing 
such a policy. If Congress merely backs the 
mandate issued by OMB Circular A-119 which 
encourages adoption of "Voluntary Consensus 
Standards" as opposed to government-centric 
proprietary standards developed by the vendors 
contracted to produce this or that component, we 
would see more coherent IT procurement and 
integration strategies.

>
>         2.  Heterogeneous technologies, semantics and processes;

Exactly, and developing vendor, OS, development 
environment, and Language Independent standards 
is the best way to encourage the vendors to build 
products which "play better together in the 
sandbox."

>
>         3.  A very large and dynamic 
>"marketplace" of potential service providers and 
>consumers.--Unlike the environment within a 
>single organization, there may be many 
>alternative providers of a computing service, 
>and available services may change on a 
>minute-by-minute basis;

Amen. Glad to see that at least someone DHS is 
aware of this, though I know you are not alone in 
understanding this pervasive predicament.

>         4.  Lack of standard context.--Within a 
>single organization, there is normally a body of 
>"well-known" information about what resources 
>are available, how they may be obtained, what 
>standards or conventions they follow, specific 
>interface details, reliability of the resource, 
>payment requirements, if any, etc. In the 
>environment of a single computer, the unknowns 
>are even fewer.  Because of the size and 
>diversity of the Internet, obtaining this 
>information is a much larger problem.

So providing an basic understanding of the 
underlying architectural principles ought to lend 
weight to the argument that vendors and service 
providers ought to develop to open standards 
where ever possible.

>         5.  Lack of infrastructure 
>services.--The Internet provides some basic 
>services, but on a "best-efforts" basis. Thus 
>issues like quality-of service and security 
>require must be addressed more explicitly than 
>in single-computer or local-network environments.

Again, Amen.

>Application architectures that call themselves 
>"SOA" provide a solution to these issues of the 
>Internet environment. There is nothing to 
>prevent implementing an SOA within a local 
>network, on a single computing platform, or even 
>in a non-technical environment like a human 
>household, but the need for SOA is driven by the 
>opportunity for exploiting the worldwide 
>connectivity provided by the Internet."

One specific thought I have pondered long on in 
connection with this Reference Model Activity is 
that I see SOÅ as applying to software "patterns" 
such that when one buys a set of service modules, 
one should  be free to adapt them to other 
subsystems such as HR or CRM even if the specific 
purchase was for a SCM component, and that such 
components should be available throughout the 
purchasing enterprise. This is not actually a 
fundamentall different SOA pattern than having 
sets of Provider/Consumers and discrete, named 
services that apply to specific business or 
enterprise processes.

>Martin


Thanks for giving me a chance to express these 
notions, Martin. My original intention was to 
bring them up earlier, but I did not want to slow 
the process that would lead to point where it 
would again be appropriate to bring these 
concepts up. If I had had the time to be a part 
of the run-up to starting the TC, I would have 
brought up such foundational concepts then, but 
under the circumstances, and having some 
experience with TCs, it seemed wiser to wait, or 
to hold off altogether, if no one else provided 
an opening into which I could insert these 
concepts. I do think there is a "there" here, and 
that if, if needs be, we may want to make a 
distinction between a service that is provided 
"as-is" with the stipulation that the core code 
not be changed or adapted, (as if such a thing 
was ultimately enforceable) and services that are 
provided as "service software patterns."

Ciao,
Rex

>
>
>
>
>
>
>
>
>-----Original Message-----
>From: John Harby [mailto:jharby@gmail.com]
>Sent: Thursday, May 05, 2005 12:05 PM
>To: soa-rm@lists.oasis-open.org
>Subject: Re: [soa-rm] When Is An SOA Really An SOA?
>
>This seem to be an issue for defining "Reference Model". Does this
>reference model provide a litmus test for architectures to determine
>whether or not they follow SOA?
>
>On 5/5/05, Chiusano Joseph <chiusano_joseph@bah.com> wrote:
>>  This question has been on my mind for quite some time, and I would like now
>>  to put it in the context of our in-process RM.
>  >
>>  In the past, I have pondered the following more specific question (please
>>  note that this is all scoped to Web Services-based SOA for ease of
>>  explanation):
>>
>>  If I have 2 Web Services that communicate, do I have an SOA?
>>
>>  We can say "certainly not!". One can do point-to-point integration with Web
>>  Services just as easily (to a certain degree) as without, with redundant Web
>>  Services rather than shared Web Services (a violation of one of the
>>  foundational tenets of SOA, which is shared services).
>>
>>  Now let's say that we have 2 Web Services that each conform to the SOA
>>  Architectural Model in Figure 1 of our most recent draft. There is a data
>>  model, a policy, a contract, etc.
>>
>>  Add to that our definition of SOA on line 470, in which we (correctly) state
>>  that SOA is a form of Enterprise Architecture, which (at least in my mind)
>>  implies enterprise-level benefits.
>>
>>  Q: Given the last scenario above (2 Web Services that each conform to the
>>  SOA Architectural Model ) and our definition of SOA: Is this scenario
>>  large-scale enough that it *really* meets our definition? IOW, how
>>  large-scale does an "instance" that conforms to our RM have to be to yield
>>  benefits on an enterprise scale? Do we need to stipulate something regarding
>>  this for our RM?
>>
>>  Joe
>>
>>
>>
>>  Joseph Chiusano
>>
>>  Booz Allen Hamilton
>>
>>  Visit us online@ http://www.boozallen.com
>>
>>


--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309