Messaging with Payments

iang posts on the right permutation of message and payments

i. we want more transactions,

ii. payments business derives from trade …

iii. trade is really messages, with a payment tacked on,

iv. we have a payment system, built on great messaging principles,

v. we just need to switch the emphasis of our system architecture a little, to:

messaging-with-payments, not payments-over-messaging.

I've seen this many times, its a result of paying too much attention to functional requirements (what dos it have to do to complete business goal) and not enough to non-functional architectural requirements (how does the system as a whole work). You will arrive at different solutions if you work in this order.

Comments

[iang]

Something that has puzzled me is this whole /functional/ versus /non-functional/ thing. Why do people make a big deal about the separation?

I can see it is quite plausible to make the separation. But I don't see the utility. Every time I've been involved in requirements, I want everyone to know them all, think about them all, interact with them all of them, test all of them ... where's the added value?