Ann Wrightson wrote:
>
> Joe,
>
> You wrote:
>
> For example, a methodology could start out (roughly) as:
>
> (1) Define all entities in your architecture
> (2) Identify all data exchange points
> (3) Identify the type of data (in general) that needs to be exchanged
> (4) If the type of data is transactional (i.e. purchase order/invoice), then
> the pattern is "Transactional"
>
> I'm wondering:
>
> How would you sort out whether *the type of data is transactional*?
Ah - I could have put this a better way: (4) If the exchange is
transactional in nature
> - this
> question is in the context of an assignment I'm engaged on (concerning
> interoperability of services between disparate IT and different
> organizations) where I'm supporting a team doing 1&3, against a background
> of knowing more or less the kind of 2s that are wanted, and explicitly
> deferring steps like 4 since the data representations of entities are seen
> as contingently rather than necessarily participating in transactions.
>
> This feels right to me from a philosophical/theoretical point of view, and
> also practically in that for example the assembly of information that is an
> invoice plays a part in a transaction, but may also be stored in a system of
> record, or play a role in a legal matter.
Absolutely. I think the shift from the data to the exchange (as in my
response above) might help resolve this ambiguity.
Thanks Ann!
Joe
> ... or do I have the wrong end of the stick?
>
> Regards,
>
> Ann W.
--
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton
