Interfaces

Drawing a diagram to show the containers that make up your software architecture is a great way to understand what the major building blocks are, with each container being an executable element such as a web server, application server, database, etc. The lines between the containers are collaborations between those containers and highlight where you probably have inter-process communication. These links are probably your architecturally significant interfaces.

Interfaces are one of the riskiest parts of any software system, so it’s worth spending some time to understand what the interfaces are and how they work. However, you need to look past the usual "what" and "how" questions to really understand the interface and how it influences your architecture.

• What is the interface technology and protocol?
• Who has ownership of the interfaces?
• Are they synchronous or asynchronous?
• How often does the interface change and how is versioning handled?
• If messaging is being used, which queues (point-to-point) and topics (pub-sub) are components using to communicate?
• What format are the messages (e.g. plain text or XML defined by a DTD/Schema)?
• Are asynchronous messaging links guaranteed?
• Are subscribers durable where necessary?
• Can messages be received out of order and is this a problem?
• Are interfaces idempotent?
• Is the interface always available or do you (e.g.) need to cache data locally?

Spending some time to answer these sorts of questions for each of the container collaborations will really help you understand what you're dealing with and how best to design for it. After all, interfaces often represent the areas of the highest complexity and can influence your architecture in dramatic ways.