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

["Laskey, Ken" <klaskey@mitre.org>]

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