ER — PRINCIPLE OF ALPHA STATE INDEPENDENCE

PRINCIPLE OF ALPHA STATE INDEPENDENCE
The Essence Kernel framework is featured as independent of all methods and practices.

Dependent relationships among Essence Kernel alphas are established and determined by the choice of methods and practices their users import, that is, methods and practices supply the integrating glue that binds alphas.

Consequently, the checklist conditions for achieving an alpha state must be intrinsically associated with the alpha of which they are apart and should not explicitly import or repeat checklist conditions from other alphas.

A careful and critical review of the OMG Essence standard reveals that while these principles and rules of construction are fait fully adhered to in the Stakeholder, Software System, Team, Work, and Way of Working alphas, they are violated in the Opportunity and Requirements alphas where checklist conditions from each are explicitly restated as well as the Software System alpha.

It appears that the authors may be tilting towards the Agile Development Method and permitting the Agile way of thinking on the Opportunity and the Requirements to bleed through despite the method and practice promise and intention of Essence.

Specifically:

1.Stakeholders- OK

2. Opportunity
Issue 1: The Identified state imports checklist conditions from the Stakeholder alpha, that is, Recognized and Represented.
Issue 2: The Solution Needed state imports checklist conditions from the Stakeholder alpha, that is, Recognized and Represented.
Issue 3: The Solution Needed state imports checklist conditions from the Requirements alpha, that is, Acceptable and Addressed.
Issue 4: The Addressed state imports a checklist condition from the Software System alpha, that is, Usable.

3. Requirements
Issue 1: The Conceived state imports checklist conditions from the Stakeholder alpha, that is, Recognized, Represented, and Involved.
Issue 2: The Conceived state imports a checklist condition from the Opportunity alpha, that is, Identified.
Issue 3: The Bounded state imports checklist conditions from the Stakeholder alpha, that is, Recognized, Represented, Involved, and In Agreement.
Issue 4: The Coherent state imports checklist conditions from the Stakeholder alpha, that is, Recognized, Represented, Involved, and In Agreement.
Issue 5: The Accepted state imports a checklist condition from the Stakeholder alpha, that is, In Agreement.
Issue 6: The Addressed state imports checklist conditions from the Stakeholder alpha, that is, In Agreement and Satisfied for Deployment.
Issue 7: The Fulfilled state imports a checklist condition, that is, Satisfied In Use.

4. Software System- OK

5. Team- OK

6. Work- OK

7. Way of Working- OK

Close, no change.

The references from certain alpha checklist items to other alphas is intentional and not unreasonable, since there are associations between alphas, as reflected in kernel specification. However, this does not imply explicit dependencies between the alpha states – checklist items in one alpha do not actually refer explicitly to specific states in other alphas, but just general conditions that need to be checked. It should also be noted that kernel activity spaces are likely to advance alphas in the same area of concern together, indicating that alphas may move forward in "waves". Further formalization of this wave might allow the alpha checklists to be made more independent, but this is a topic that will require future research, and it would not be appropriate to change the specification in this regard at this time.