[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
Hi Mike, I just finished my SAFe 4.0 Leader training and am taking the certification exam at this time (online, open-book). I have been involved for some time with a major US Government application that has adopted SAFe – somewhat abruptly, in my judgment – and helping the PMO tailor SAFe toward the
“High Assurance Systems” variation … Scaled Agile has only just started to detail what that means in terms of SAFe implementations. On the whole – and speaking only form a personal perspective – SAFe has value for organizations moving from more traditional software and system development methodologies to Agile
(Scrum) and DevOps in that it brings in the Enterprise, Portfolio, Value Stream, and Program views to flesh out the Team view that (it seems to me) is most commonly the focus of Agile transitions. On the other side of that coin, SAFe can seem to be about learning
a whole bunch of new words for the same things we did in earlier times and with those more traditional methodologies (that were never, in my experience, the stark Waterfall red herring that proponents like to contrast the Agile Manifesto ways with). Avanti, BobN From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org]
On Behalf Of Mike Poulin 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
--------------------------------------------------------------------- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]