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] Groups - Draft Minutes-SOA-RM TC Nov-23-2016.doc uploaded


Thanks, Bob.  I had not seen this before.

Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

On Nov 25, 2016, at 8:37 PM, Natale, Bob <RNATALE@mitre.org> wrote:

Apologies to those who have already seen this, but this is a common representation of sources of waste that can be addressed via lean processes and practices … it takes some slight (but mostly obvious) mapping for IT services versus its manufacturing origin:
 
<image001.png>
 
 
Avanti,
BobN
 
From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org] On Behalf Of Ken Laskey
Sent: Friday, November 25, 2016 6:08 PM
To: Mike Poulin <mpoulin@usa.com>
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Groups - Draft Minutes-SOA-RM TC Nov-23-2016.doc uploaded
 
Michael,
 
I think a couple points of SAFe are relevant and consistent with your arguments.
 
- You come up with requirements and build to those requirements but unless you are doing something that has been done countless times before, the requirements are not completely known and unchanging.  Lean/agile assumes change will happen and you should accommodate.  The challenge is to recognize and respond as soon as possible rather than heading down the wrong path assuming certainty that doesn’t exist.
 
- XP argues for creating the minimum.  I’m not convinced that the minimum is always the most efficient.  If you know how to design in flexibility you are likely to need, that seems like a good investment to me.
 
- In the SAFe context, there is a lot of emphasis on getting stakeholders together to express and understand needs and be on the same page as to what we agree is high priority.  The waste avoided is people working at cross purposes.  It also looks at the processes and where there is significant delay in moving forward.  Delay is waste.  And, as noted above, recognizing the need for change early avoids the waste of blithely heading down the wrong path and building the wrong thing.
 
- SAFe also appreciates that architecture work is needed and there needs to be planning and resources made available for enablers.  It doesn’t specify how to do architecture, but it appreciates architecture doesn’t emerge by magic.
 
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508
 
On Nov 25, 2016, at 5:34 AM, Mike Poulin <mpoulin@usa.com> wrote:
 
Hi Ken,
 
I've opened SAFe 4.0 and it says that SAFe is for enterprise-class Lean-Agile software and system development. If you have grasped the essence of this thing, please, tell us how it relates to Architecture (including SOA).
 
Years ago, when that American coupule (do not remember thier name) brought Lean from Japan and stated/published the Lean Principles, I think I published a blog about incompatibility of one of the core principles with SOA (actually, with COS). This pronciple is "Eliminating Waste". When a team write code, there is a Specification, i.e. Requirements, and the team simply realises it (them). Everything that is not in the Requirements is a waste. That's simple. 
 
When you design a Service, you have to address a set of needs of a category of future consumers - this is not presise or quite concrete. Every implementation must be as flexible (changeable for minimum time and minimum cost) meaning that what is waste today may be a 'golden egg' tomorrow. That is, Lean is not adequate to Service development. It is right becuase this method has been acquired from the Japanise cate manufacturing industry, this has irthogonal concept of product to SOA. In conveyer, the outcome is known up-front and specified well, plus, any deviation from this specification is undesirable becuase can degrade the quality of the final product (the car). In Service design/development, the outcome is uncertain to the degree where only flexibility can help to adjust the final product to the market needs (Note, when we connect two independent systems with Web Service or REST interface, we do not create any Services)
 
The only way remains in building Services is to specigy such requirements, that have a lot of extra elements - hooks for extending, replaicing, outsourcing, eliminating parts of the final product. At any moment at the beginning there should be a lot of waste regarding particular task the Service is used by particular consumer. However, this waste can becomes the black earth (humus) literally tomorrow.
 
I think that multiple attempts to bring manufacturing development models in SW development and, especially Archtiecture are a fundamental 'dead end'.
 
- Michael
 
 
 
Sent: Wednesday, November 23, 2016 at 6:00 PM
From: "Rex Brooks" <rexb@starbourne.com>
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] Groups - Draft Minutes-SOA-RM TC Nov-23-2016.doc uploaded

Document Name: Draft Minutes-SOA-RM TC Nov-23-2016.doc 


No description provided.
Download Latest Revision
Public Download Link


Submitter: Rex Brooks
Group: OASIS SOA Reference Model TC
Folder: Meeting Notes
Date submitted: 2016-11-23 10:00:10




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