When you document your architecture, you need to ask yourself why am I documenting it and for who? There are different perspectives on product architecture each of them highlighting different things useful to different people. We think there could be up to 5 views we could work on:

• a marketing architecture is a communication support to explain your product architecture to stakeholders, other teams …
• the business architecture is focused on the problem space: who are your users, what are their pains, in which value chain are you, do you contribute to a business process, what is the ubiquitous language
• then comes the product architecture to describe the solution you come up with to meet the problem. One finds here the system context and the bounded context if you use technics such as Domain Driven design, the functional & data views
• The technology architecture: how are you implementing your product? what are the technologies you used? where is it deployed ? …
• Last but not least, the system engineering view. It’s very unlikely that your product is operating alone. You need to document how it’s integrated in the overall system. Here one finds the system context map and the integration strategy between them (again liked to DDD).