Software architecture is a platform for conversation

If you're writing software as a part of your day-to-day job, then it's likely that your software isn't going to live in isolation. We tend to feel safe in our little project teams, particularly when everybody knows each other and team spirits are high. We've even built up development processes around helping us communicate better, prioritise better and ultimately deliver better software. However, most software projects are still developed in isolation by teams that are locked away from their users and their operational environments.

The success of agile methods has shown us that we need to have regular communication with the business users or business user representatives so we can be sure we're building software that will meet their needs. But what about all of those other stakeholders? Project teams might have a clear vision about *what* the software should do, build the foundations to support that vision, add features and then release the software to an expectant audience. But then, often you'll hear phrases like this.

• Nobody told us you needed a production database created on this server.
• We can't upgrade to Java 6|.NET 3.5 on that server until system X is compatible.
• We don't have spare production licenses.
• Sorry, that contradicts our security policy.
• Sorry, we'll need to undertake some operational acceptance testing before we promote your application to production.
• How exactly are we supposed to support this application?
• I don't care if you have a completely automated release process ... I'm not giving you the production database credentials for your configuration files.
• We need to run this past the risk team.

In essence, the business users are just one type of stakeholder in your software project and there are usually many others.

• Current Development Team: the current team need to understand the architecture and be aware of the drivers so that they produce a solution that is architecturally consistent.
• Future Development Team: any future development/maintenance teams need to have the same information to hand so that they understand how the solution works and are able to modify it in a consistent way.
• Database Administrators: some organisations have separate database teams that need to be involved in and understand how your solution uses their database services (e.g. from design and optimisation through to capacity planning and archiving).
• Operations/Support Staff: Operational staff need to understand how to run and support your system (e.g. configuration and deployment through to monitoring and problem diagnostics).
• Compliance and Audit: Some organisations have strict regulations that they need to follow and people in your organisation may need to certify that you're following suit.
• Security Team: Likewise with security; some organisations have dedicated security teams that need to review systems before they are permitted into production environments.

These are just some of the stakeholders that may have an interest in your architecture, but there are probably others depending on your organisation and the way it works. If you think you can put together a software architecture in an ivory tower on your own, you've probably missed something. Software architectures don't live in isolation and the architecture definition process is a platform for conversation. Define your own set of software architecture guidelines and use them as a starting point to talk to people. A five minute conversation now could help capture those often implied architectural drivers and improve your chance of success.