OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [soa-rm] service in a SOA ecosystem

Thank you, Ken. Please, get well!

I'll take on this draft with two following drivers:
1) "The section would extend the RM definition in much the same way as has been done in  
our email discussions."
2) "we'll see what makes sense for new models"

I am not sure I understand what ""No solution without SOA likely means no solution with SOA"" proofs. Many advanced SOA architects now say "SOA is no longer a competitive advantage; it's the cost of doing business".

- Michael

-----Original Message-----
From: Laskey, Ken <klaskey@mitre.org>
To: soa-rm@lists.oasis-open.org <soa-rm@lists.oasis-open.org>
Sent: Wed, Oct 27, 2010 3:10 pm
Subject: [soa-rm] service in a SOA ecosystem

First, I feel like crap and have an 11:20 doctor's appt, so I'm likely to miss 
at least the beginning of the call.

That said, I apologize for making the following suggestion and not being there 
to explain my point.  Anyway, here goes:

1. We should neither change the RM definition of service nor add another 
definition of service.  It will only create confusion.  Also, I was struck by 
Jeff's observation that we had better than an 80-20 solution in the RM, and 
suggested changes didn't necessarily increase the 80 but simply shifted some 
points in while having other points slip out.

2. The RM emphasis on needs and capabilities and service as the "access 
mechanism" was very much influenced by lots of folks traditionally having a 
problem with Blat and with no better understanding of the Blat problem or at 
least a notional Blat solution then advertised they were creating a Blat service 
to make it all go away.  The mantra of "No solution without SOA likely means no 
solution with SOA" consistently rings true when I teach.

3.  The concern of emphasizing "software architecture" led us to underplaying 
the business aspects.  As I noted, I submitted a draft white paper for this 
group's review while the RM was still in the final stages of being approved.  We 
have had this come up periodically again and again.

So my suggestion is we add a Service in the SOA Ecosystem section in the 
Ecosystem View after we cover the basics of what we mean by the ecosystem.  The 
section would extend the RM definition in much the same way as has been done in 
our email discussions.  (Let's consider adding the RM definition as an appendix 
for easy reference.)  I suggest doing this with no additional definitions (of 
any kind); we'll see what makes sense for new models.  This strikes me as the 
natural way to handle the problem because most of the missing things meld 
directly with the ecosystem.

I also suggest that Boris and/or Michael take on the first draft.  One, they are 
likely to have material to draw from in addition to the email threads.  Two, 
they have been part of the discussions over the years and I believe they can 
shape a consensus piece even if it does not draw in every angle they have argued 
for over time.  Conversely, I'm sure everyone's comments will be focused on 
overall improvement even if some of the suggestions have to part ways with 
cherished ideas we'd each like to see included.

Chew on this.


Dr. Kenneth Laskey
MITRE Corporation, M/S H305              phone: 703-983-7934
7515 Colshire Drive                             fax: 703-983-1379
McLean VA 22102-7508
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]