comments on last week's telecon

[Ken Laskey <klaskey@mitre.org>]

Well, my wife broke a wine glass and cut herself, so I sit in the  
urgent care clinic waiting for her to get a few stitches.  And as I  
sit here, I listen to the mp3 of the last meeting I missed.  I skipped  
the epiphany piece and went to trust, and I have a few comments on  
that.  I'll listen (actually did listen and comment) to epiphany talk  
later.

As for the trust discussion, I agree with most of it but let me add a  
few ideas for figure 13 (which I don't have in front of me).  To  
answer Frank, the braces having Responsibilities, Goals, Constraints  
within each ownership boundary sets the context of action within that  
ownership boundary.  I always act to satisfy goals within my context.   
My goal can be to accurately represent your goal expressed as your  
intent that is transferred across the boundary.  If you believe that,  
there is probably a high level of trust.  If I send out phishing  
emails, I may understand your intent, but my goal is to separate you  
from your money.  Phishing relies on there being too much trust.  So,  
in summary, I always act to satisfy my goals and my goal to some  
extent may be to see your intent satisfied.  I may have additional  
goals that I hope to satisfy at the same time, like making money  
(legally and ethically) for my efforts.

Now for the venn diagram, it is not meant to express the overlap  
between needs and capabilities but to express how well I can  
understand your intent and to what extent I am capable of seeing it  
through.  The overlap between your intent  and what you can expect me  
to accomplish is probably less than 100%.

Finally, there was mention of adding some of the trust discussion to  
governance.  I don't think it belongs there.

Now I'm listening to the epiphany section.  First, we have repeatedly  
and explicitly said we never expected you to code from the RA; indeed,  
you need a concrete architecture and you design code from that.   
However, the RA should provide a consistent basis from which concrete  
architectures can be developed.  Second, my original complaint was  
that I saw section 3 as a sociology treatise that would completely  
lose our audience.  I have become convinced that there are things like  
security that really need things in section 3 as their underpinnings;  
my position evolved to say we need some things in section 3 but these  
need to be explicitly tied to later sections where the section 3  
concepts are used.  If the concepts are not explicitly used, parsimony  
says they should be dropped.  I think our value falls off  
precipitously if we limit ourselves to another overly abstract  
document that doesn't have hooks into the concrete world.

re the RM, service was the central concept but we certainly spent a  
lot of time talking about all the things that revolve around it -- see  
our initial concept diagram with service in the center but the two  
triangles around it.  Yes, we were minimalist but we did much more  
than just defining service.  But the RM is primarily definitions and  
base relationships, and thus the need for the RA.

Time to check on my wife.  Talk with you all tomorrow.

Ken


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