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

[Francis McCabe <fmccabe@gmail.com>]

Ken
 I understand the issue, SOA!=success. But, is it really necessary to keep hammering that theme? There are many many instances of the same equation. There is no silver bullet, only rearranging of deck chairs. Just some arrangements work better than others. (This is especially true of architecture where that is all we are doing.)
Frank
On Oct 27, 2010, at 11:45 AM, Laskey, Ken wrote:

> Michael,
> 
> I think we're coming around to different aspects of the same points.  For a problem where SOA benefits are really needed, other approaches may be obviously inferior.  However, saying SOA does not substitute for knowing your business, knowing your processes, and having a clear idea of the real world effects you want to accomplish.  SOA helps you accomplish things but you first have to understand those things.
> 
> Ken
> ________________________________________
> From: mpoulin@usa.com [mpoulin@usa.com]
> Sent: Wednesday, October 27, 2010 1:56 PM
> To: Laskey, Ken; soa-rm@lists.oasis-open.org
> 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.
> 
> Ken
> 
> ---------------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>