Many, many moons ago, I was a reseller of Operator 10 software (now found at http://www.allmaxsoftware.com/), which was for tracking maintenance of assets (e.g., that boiler at the Slough facility might not have exploded if we remembered to maintain it now and then!)

Wouldn't it be great if Fixed Assets packages talked to maintenance systems? Or if any Fixed Asset system could interchange data at any desired level of detail with other systems, such as:
- Purchasing and payable systems automatically updating Fixed Assets
- Fixed Assets usage tied in with planning (capacity requirements planning), costing (job costing), etc.
- Maintenance also tying in with FA, PO and Payables
- and of course, general ledger

It is something I am definitely keeping in mind. My intension of the hub and spoke diagram is really to indicate how OAccounts could be a 'lingua franca' between all these different systems. OAccounts in that sense is just a protocol via which you communicate with another node, whereby that other node could be a hub, or a spoke, or a node in some decentralised system; it is not the protocol's job to specify a particular implementation architecture. To use Eric's wording, yes, it is a "metadata standard".

That said, I am hoping to also produce an open source reference implementation, which will of course make many more architectural decisions (while leaving the possibility for other developers to write their own if they have different requirements). Curiously, it happens that I have started doing this in Scala! (Scala is the best language I could find for XML processing. Not using Lift yet, but I'll have a look to see whether it would add value here.)

One aspect which is quite important to me is to keep a version history of all changes to the accounts; very useful for audit trails, reconstructing past events in case of investigation etc. The reference implementation will probably use the distributed version control system Git for this purpose. It offers a lot of advantages, although of course for some purposes it might me more suitable to use standard database storage.

The hope, of course, is that metadata standards free you up to choose an architecture – or multiple architectural approaches – that makes the most sense and the agility to easily change between architectures. Send the data, leave the data in place and link to it, use a data warehouse or not.

So I read _virtual_ hub and spokes (overcoming the n-squared problem through a common mapping, requiring 2n maps instead of n*(n-1)/2 for one way proprietary mappings), not architectural; glad for Martin to clarify!

Can I direct you to SCALA/Lift as a possible open source messaging platform? David Pollak is the lead developer – it is open source and it is massively scalable. The reason I know is because it was used in our ESME project which is now part of the Apache incubator. We had to demonstrate scale as we were piloting on SAP/NetWeaver. David is a super cool guy and really knows about scale.