RE: [soa-blueprints] Anti-Blueprints - Number of services

["Miko Matsumura" <mmatsumura@infravio.com>]

Thanks for posting this, an excellent way of furthering the specificity
of the Coalogic case. I should resist the urge to wax philosophical and
rhetorical and try to apply myself to furthering the blueprinting work
(it's sometimes hard to resist)

Let me take a look at this further and see what comes up...

Best,
Miko

-----Original Message-----
From: marchadr@wellsfargo.com [mailto:marchadr@wellsfargo.com] 
Sent: Tuesday, November 01, 2005 7:03 AM
To: Miko Matsumura; Marc.Davies@uk.fujitsu.com; dnickull@adobe.com;
steve.g.jones@capgemini.com; Theo.Beack@softwareagusa.com;
klaskey@mitre.org
Cc: soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services


The carefulness comes to how many people are trying to speak with the
same letters and what the interpretation of those letters are within
their vocabulary. Spanish, French and English all use the same letters
but do the words mean the same thing?

My personal feeling is that the letters need to be formed into a sort of
terse word vocabulary that can be the basis of what the service is and
what it will provide. It is a very similar process to coming up with a
business strategy and probably takes a lot of the same mechanics to
define.

For example, buy, sell and trade are much more descriptive and
constraining than b,u,y,s,e,l,l,t,r,a,d,e (duplicate). I do see where
you are going with this, just cautioning the making the reduction stick
to the pan so to speak.

Here is an example of a terse way to break down an enterprise (such as
Coalogic).
http://blueprints.jot.com/WikiHome/Eriksson-Penker+based+break-down

I used the Eriksson-Penker style diagram to create it.

- Dan

-----Original Message-----
From: Miko Matsumura [mailto:mmatsumura@infravio.com]
Sent: Tuesday, November 01, 2005 6:27 AM
To: Davies Marc; Duane Nickull; Jones, Steve G; Beack, Theo; Ken Laskey
Cc: soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services


+1
 
One theme of a talk I am giving lately is about how we describe SOA.
When we talk about SOA "Reuse" we are talking about a potential for
reuse that is fundamentally unlike what most people think of when they
hear that word.
 
For example, I am currently "reusing" the alphabet to write this email.
This suggests dynamic and fluid expressions of remote and instantiated
services, not of classical class reuse such as OO. 
 
In order to achieve such "reuse", there are serious architectural
hurdles. 
 
At the ground floor, hurdles include things like service description and
discovery and interoperability standards. This allows your SOA to make
simple two word "sentences" where one service consumes another.
 
As you start to "talk" about subjects that deliver value for your
organization (business services), you begin to need things like security
and governance. I know these are not well specified, but bear with me.
 
In order to form more complex "sentences" involving business value, you
will need to have additional architectural support including a way to
manage provisioning, versioning, dependency mapping, service level
agreements and probably other things I'm not thinking of presently.
Another potentially useful tool at this stage are service contracts,
which allow for the externalization of relationship-specific delivery
preferences from the services themselves.
 
At the most expressive and dynamic, you most likely will need some kind
of business process language, some tooling support and within the
domain/organization/contextual frame a level of semantic integrity or a
mechanism to achieve semantic integration. Here be some serious dragons.

 
The saving grace is most likely that most organizations can dramatically
limit the scope of valid topics and "sentences" which can be built on
top of their SOA. Thus instead of being a "semantic web" problem of vast
complexity, it becomes more like a problem of plumbing--do the hot and
cold pipes fit together?
 
Probably more philosophical than I should get in a "blueprinting" group,
but there you are.
 
Best,
Miko

	-----Original Message----- 
	From: Davies Marc [mailto:Marc.Davies@uk.fujitsu.com] 
	Sent: Tue 11/1/2005 5:27 AM 
	To: Miko Matsumura; Duane Nickull; Jones, Steve G; Beack, Theo;
Ken Laskey 
	Cc: soa-blueprints@lists.oasis-open.org 
	Subject: RE: [soa-blueprints] Anti-Blueprints - Number of
services
	
	

	Now you've hit the important point for me Miko - SOA isn't
*just* services
	(despite our recent conversation thread), its architecture. My
view is that
	the services are the *realisation* of good architecture and a
collective
	approach toward building a loosely-coupled, multi-tiered and
flexible
	environment where its possible to gain cost synergies and re-use
	flexibility, avoiding the seemingly endlessly recurring scenario
of
	large-scale enterprise with its bulky, silo-maintained and
poorly integrated
	(while being tightly coupled!) typical non-SOA environment.
	
	I think Duane's example of the Internet perfectly underscores
this principle
	- inasmuch as the Internet is a collection of millions of
services - it is
	(IMHO) *not* an SOA - unless we're talking Service Oriented
Anarchy :-)
	
	... it doesn't conform to architectural disciplines, anyone can
code how
	they want, anyone can deploy what they want, there are no checks
to ensure
	services deliver on their promised capability (I could go on).
Sure, its an
	excellent example of how millions of services can be operating -
but, its
	also an illustration of how millions can end up delivering very
poor
	service, to analogise - if you google the 'wrong' search string
- you end up
	with 1 million 'hits' = meaningless
	
	Essentially, this is my rationale for finding Steve's document
so very
	useful as a benchmark pointing us forward, as (for a change) it
doesn't seem
	to be the tail wagging the dog - i.e. its top-down approach
assures the kind
	of alignment with business goals which I think SOA is trying to
achieve,
	abstraction (at all levels) is an important element of SOA and
in this
	context defines (to me) the importance of blueprints; properly
done they
	represent a model that ensures a solution is customer (i.e.
business
	processes, goals and fundamentals) focussed, rather than
technology driven.
	
	Regards,
	Marc.
	
	
	-----Original Message-----
	From: Miko Matsumura [mailto:mmatsumura@infravio.com]
	Sent: 01 November 2005 02:33
	To: Duane Nickull; Jones, Steve G; Beack, Theo; Davies Marc; Ken
Laskey
	Cc: soa-blueprints@lists.oasis-open.org
	Subject: RE: [soa-blueprints] Anti-Blueprints - Number of
services
	
	I deprecated the microservice antipattern because it was a "I
know it when I
	see it" antipattern, but hard to codify. I added a comment to
the "Too many
	cooks" antipattern to get a similar point across. I just see too
many people
	focused on the "S" part of SOA and maybe not enough on the "A".
Present
	company excluded, of course.
	
	        -----Original Message-----
	        From: Duane Nickull [mailto:dnickull@adobe.com]
	        Sent: Mon 10/31/2005 4:42 PM
	        To: Miko Matsumura; Jones, Steve G; Beack, Theo; Davies
Marc; Ken
	Laskey
	        Cc: soa-blueprints@lists.oasis-open.org
	        Subject: RE: [soa-blueprints] Anti-Blueprints - Number
of services
	       
	       
	
	        All:
	       
	        I still have problems with the "number of services is a
measurement
	of
	        whether something is a pattern/anti-pattern for SOA"
conversation.
	       
	        If you agree that the internet is a large SOA, it has
more than
	        10,000,000 services and I do not think that anyone would
state that
	is
	        not an SOA due to the large number of services.  I would
not be
	willing
	        to state that the internet is architected errantly since
it has too
	many
	        services. Number of services has no static bearing on
good vs. bad
	        design IMO.  The requirements vary specific to scenario
and YMMV.
	       
	        Some thoughts on what may not be SOA (*thoughts only)
	       
	        1. A service that is orphaned and has no associated
mechanism for
	being
	        discovered by any consumer is probably not SOA, even
though it is a
	        service itself.  One of the core tenets of SOA is that
concrete
	services
	        must have some mechanism to declare they exist and are
available and
	to
	        communicate such to potential consumers.
	       
	        A service availability and discovery concept is in the
core
	reference
	        model (*EDITORS DRAFT only).
	       
	        2. A service with a set of metadata too slim to provide
a potential
	        consumer with the information and/or pointers to
information it
	requires
	        to make a service invocation request is not SOA.  This
may include
	many
	        mechanisms including out of band human-to-human contact
to figure
	out
	        more intricate details.
	       
	        A service discovery concept is in the core reference
model.
	       
	        3. A set of multiple services that functionally
duplicate each other
	and
	        one of the services is not used by any active or planned
future
	consumer
	        MAY be a poor practice, but is still probably SOA.
	       
	        4. A service that does not have a mechanism to allow a
potential
	        consumer to discover its policies may not be SOA.  Even
if a service
	has
	        no specific policies, that is still a conceptual policy.
	       
	        5. A set of services that advertise or claim they act on
a specific
	        resource but in fact do not do anything, are likely not
SOA.
	       
	        6. A service that has no interaction possible is likely
not SOA.
	       
	        7. An always on synchronous socket from one physical
endpoint to
	another
	        may not be SOA.  Not sure how to qualify this or if it
is relevant
	to
	        the price of tea in China...
	       
	        So what!
	       
	        While this is an interesting conversation, I also think
it may
	detract
	        from the work of building the following items:
	       
	        1. A metamodel for expressing architectural blueprints;
and
	        2. A catalog of SOA blueprints and a system for locating
ones that
	are
	        applicable to a specific scenario.
	       
	        Duane