One thing I'd say is that my challenge was around the "time-sync"
piece which indicates that it must be complete with all referencable
sources.  That for me is the bit that is a bit too principle for me.

Steve


2008/11/25 Rob Eamon <[EMAIL PROTECTED]>:
> +1 on the principle vs. solution tradeoffs. I'm a big fan of
> establishing "this is the way it is done unless there is a reasonable
> reason not to." Of course the debate then turns to what's a
> reasonable exception and what isn't. :-)
>
> Is there debate/disagreement on the merits of this principle? And
> touching on Mark Baker's response, how much completeness is the right
> amount? If the sender doesn't want to send why the prisoner is being
> held, that's cool. But then for recipients that need that information
> before taking some action, then the event is not complete in that
> context. The classic trade-off between too much info to wade through
> (message schemas run amok) vs. too little to be helpful (messages
> requiring several other queries).
>
> When do we recognize that a principle might be too idealistic, that
> adhering to its spirit will almost never be achieved in application?
> I'm not saying this principle falls into this category necessarily.
> Just wondering aloud...
>
> -Rob
>
> --- In [email protected], "jack541108"
>
> <[EMAIL PROTECTED]> wrote:
>>
>> --- In [email protected], "Steve
> Jones"
>> <jones.steveg@> wrote:
>> >
>> > A little bit pie in the sky here, nice in theory but a killer in
>> practice
>> >
>>
>> It's all about the difference between architectural principles and
>> solution architectures. Principles are guidance in ambiguous
>> situations toward an ideal. A solution architecture holds the
>> trade-off. Deviating from the principle must be motivated, adhere to
>> the principle not. That's what enterprise architecture is about.
>>
>> -Jack
>>
>
> 

Reply via email to