diff transactional data & master data

is there any difference?

Master Data (MD) is long lived, so is much Transactional Data (TD).
MD may only be valid for certain subscribing applications, same for TD.
It can make sense to publish MD even when it is not fully populated, same for TD.
MD has both global entities and local entities, that can be the case for TD.
MD often goes through workflow for updates/creation, so does TD.
MD entities are heavily references, TD not as much.
MD needs to be flexible to accommodate significant change, TD less so, since TD is normally consumed by fewer applications.

So if there is a difference that influences design it is probably MDs need to support a higher rate of change than TD and a higher number of external, incoming references.

Components of enterprise architecture

architectural principles.
reference architectures
as-is/to-be business process maps.
as-is/to-be organisation/roles.
as-is/to-be data and process flows through systems (from actors through to end nodes).
as-is/to-be functionality (inc. requirements for to-be world)
as-is/to-be system landscape.

as-is/to-be technology landscape.
as-is/to-be infrastructure architecture.

Next layer down:

Domain Model (static, dynamic)
Business Rules
Software Architecture
Infrastructure Architecture
Integration Architecture
Application Architecture (functions mapped against system)
Deployment Model
Workflow Specification

Layers below this are construction type activities. First punt, I'm sure there are more elements. I guess we are answering who, what, where, when, how. Of course Zachmann would suggest the above are broken down into 36 cells of normalised deliverables. I'm not sure I buy this type of model yet.

Entities more important than relationships - huh?

Why do the popular languages not have associations as first class entities?
Why do many modelers not see relationships as first class entities worthy of naming and attributes?

What is it about associations that encourages this wanton neglect?

I want to know.

Container elements

If an entity of type A has an association C to many entities of type B the XML could be written thus:

<A>
   <B>
   <B>
   <B>
   ....
</A>

but there could be multiple associations to entities of type B so maybe it needs to be:

<A>
   <C>
   <C>
   <C>
   ....
</A>

but now the element name representing entity type B is polluted with the association name. Perhaps it should be like this:

<A>
   <C>
      <B>
      <B>
      <B>
      ....
   </C>
</A>

advantages of this are that the association is a first class element, so it can have attributes and the name of the association doesn't effect the name of the contained elements. This also means that role names on associations (in UML) have a precise mapping to an element in the XSD.

I don't think this applies to unary associations though.

Practically it also seems to me that the traversal /A/C/B expresses the intent better that /A/C.

Dom Sub COTS

When building a programme around COTS do you go for a submissive or dominant partner? Who will do what you want and who will force you to control your desires? Which one of those options will work better? What signal will you agree? Do you want short deliveries that don't quite meet your expectations or do you want to be waiting and waiting and waiting.....?

The trouble with concensus

Consensus, stakeholder engagement, buy-in, continued business sponsorship, standards followed, fewer obstacles.
Design by committee, less effective decision making, 'all things to all men', group think, group polarisation, slow, distrust.

'grist to the mill', making it happen, get things done, more effective decision making, speed, trust, benevolent dicator.
No buy in, constant debate, dictat, favoured few, command & control, more obstacles, internal & external resistance.

Consensus requires engagement, engagement requires time, both from within and without. Consensus within large teams involves many people. Involving many people means many people are involved in many things.

Apartment thread the project and consensus is reduced. Small teams reach conclusions that are communicated but many people aren't involved in many things. The project is simpler to understand and more transparent. Trust is required, hard but once it's established is clearly beneficial. Each work packet has dedicated resource and energy is focused in one place. The project is invigorated and dynamic.

Everyone will attest to the fact that having someone working on multiple activities at the same time creates problems when tracking work or ensuring work gets done. However, it wasn't until this week that I realised how much consensus works to break down singularity of purpose. Consensus doesn't just make reaching decisions harder, it de-focuses the team. Worse, it's a slow acting poison. Initially reaching consensus makes life easier and more efficient. As the team grows the drip drip drip of consensus sets expectations. Before you know it, all the key players are on all the work streams, so they can all reach consensus.

I think it was really only this week that I realised just how significantly consensus de-focuses individuals.

Caveat

Consensus on small projects is easy, there is only a small group of people. My comments only apply to large projects where people end up being involved in N strands of work, just to ensure that consensus can be achieved.