RE: [soa-rm] RM at Open Group...

As per the glossary request I think that it might just be that element that has caused the perception.

Like you say there are many different Service based approaches, and levels, where I think the RM as a document now helps and acts as a base. The “Super Enterprise” or “Extended Enterprise” one being a particularly valuable area, some people might see these as business services (certainly our Open Group members would) which is why I 100% agree that the RM should be explicit in that area of definition as its still unstable (IMO). The RM is applicable in these spaces and given the PPT that covered these concepts it would be a useful piece of information to explain this breadth and let people complain that we haven’t focused on their particular area of interest (SOA-RM it doesn’t cover Services for penguins type of stuff).

The challenge appears to be not so much one of content (baring the one thing in the glossary) but one of communication of intent, as Rebekah says there are other people complaining from the opposite perspective which means that the RM has achieved its goal of defining a proper RM for all of SOA. Its probably worth stressing this point when the formal release is made so people are aware that it _is_ applicable everywhere, this is certainly the message I’ve been using with clients.

I agree, its more “and” than “but”, we just need to make sure that is clear outside of this group.

Steve

From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: 26 January 2006 15:25
To: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] RM at Open Group...

Agreeing and adding:

Regarding the following from the original e-mail below:

<Quote>

it looks like it actually can define SOA at a business level (Business Services) but the document has some references/qualifications in definitions that tie it to technology, application, etc.

</Quote>

I don't see the above as a "but" (negative connotation), but rather as an "and", which I believe captures the essence of SOA: IT capabilities (technologies, applications, standards, etc.) that support business and mission needs. So if I wrote the above, I would use "and", and follow it with "which is a great thing!".

Regarding the following:

<Quote>

This seems like a missed opportunity to define SOA as about business services.”

</Quote>

Perhaps missed (intentionally) in this document, as we are describing an abstract model. The opportunity for this should come in the reference architecture(s) that we define.

I still also believe that there can be multiple levels of SOA (I believe I may have mentioned this several months ago on a thread here) - from top down:

- Super-Enterprise

- Enterprise

- Business

- Technical

I'll explain these further:

- Super-Enterprise: Meaning outside-the-enterprise - think multiple organizations interacting

- Enterprise: Enterprise-level services - e.g. ERP, HR

- Business: Services that are more business-facing than technical services, but not at the enterprise level - e.g. automation of a process for claims processing within an insurance company.

* May also think of these in terms of the most *immediate* value being realized at a business level (e.g. automation of the claims process therefore faster claims processing, etc.) than at a technical level.

- Technical: Services whose most *immediate* value is realized at a technical level, which may further translate (through one or more additional degrees of separation) into value realized at a business level.

* Example: Consolidation of error processing for forms entry in an organization from multiple software modules into a single service that is invoked by all forms. The most immediate value is more technical than business in nature - e.g. consistent error messages, maintenance of error messages in one place, etc.

* The second case (maintenance of error messages in one place) does provide business value over time, but that value will not be realized as quickly or as impactfully (a word?) as with Business services.

Another way to look at this stack is in term of maturity - however, I do not believe that Technical services are "less mature" than Business services - they are just a different type of service.

Joe

Joseph Chiusano

Associate

Booz Allen Hamilton

700 13th St. NW, Suite 1100

Washington, DC 20005

O: 202-508-6514

C: 202-251-0731

Visit us online@ http://www.boozallen.com

From: Metz Rebekah [mailto:metz_rebekah@bah.com]
Sent: Thursday, January 26, 2006 8:36 AM
To: Jones, Steve G; soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] RM at Open Group...

It’s interesting to hear this comment this morning. Yesterday afternoon, one of my colleagues mentioned some discussions he had at a recent Gartner Group event. The feedback he provided was that the SOA-RM did a good job at describe business services, but didn’t acknowledge that things at a purely technical level (e.g. a storage service) can also be SOA without tying directly back to the business.

My reaction to that comment is to say that even a ‘purely technical’ service ties back to the capabilities. Perhaps they might tie in through the IT supply chain rather than a 1:1 correspondence to a business need. Nevertheless, I would argue why someone would offer a service if they don’t anticipate that they will provide that service to someone else. That mission objective may be a small part of the over mission objective for an enterprise – but it certainly should be traceable.

That said, if we’re receiving comments from both perspective – we’ve probably struck decent middle ground. Perhaps a primer on the RM might express these perspectives and how the RM supports both of them?

Rebekah

Rebekah Metz

Associate

Booz Allen Hamilton

Voice: (703) 377-1471

Fax: (703) 902-3457

From: Jones, Steve G [mailto:steve.g.jones@capgemini.com]
Sent: Thursday, January 26, 2006 4:30 AM
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] RM at Open Group...

Capgemini are also fairly heavily involved in Open Group (running the BP group for instance) and at the SOA event the RM has come up in discussion…. Some feedback from the folks there

“We are looking at the OASIS SOA reference model in the SOA forum in Open Group - and having had a quick look at the document (scan at best, not complete) it looks like it actually can define SOA at a business level (Business Services) but the document has some references/qualifications in definitions that tie it to technology, application, etc.

This seems like a missed opportunity to define SOA as about business services.”

I actually think the document applies equally well in both technical and business domains but it might be something to tighten in the wording to help ensure that message comes across.

Steve

___________________________________________________________

Steve Jones | Capgemini

CTO, Application Development Transformation

T +44 870 906 7026| 700 7026| www.capgemini.com

m: steve.g.jones@capgemini.com

txt: +44 (0) 7891157026

Join the Collaborative Experience

___________________________________________________________

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

soa-rm message