Two major pitfalls in typical software development projects are the architecture process and the architect's level of experience. The architecture process often consists of one or more architects relatively disconnected from developers and business. They try to predict the future at the beginning of a project, often resulting a lot of friction with project management and developers that have to deal with and adjust to the day-to-day situation and requirements. The consequences are the ivory tower or police agent architects, uncomprehensible complexity, problems in production and a mismatch between stakeholder and customer concerns and the delivered solution. What usually happens is that the product ends up not being built according to architecture. In a best case scenario, the architect is forced to make costly adjustments to his design. The problems become even greater when architects think too far into the future or suffer from a "not invented here" syndrome.

Xebia believes that effective and efficient architecture is created "just in time" and "just enough". The main focus is to address architectural concerns of product that is to to be delivered first. Xebia architects embrace any new insights during the project and make changes accordingly. This way of thinking will fit in any process, but it fits perfectly in an Agile software development process. We believe that architecture must be based on a business case, on business needs, and on business concerns. This also implies the non-existence of "silver bullet" solutions. Each situation is different and needs to be treated as such, plus the focus should be on design, communication and facilitation of the architecture process. The creation of architecture is not an architect's privilege, architecture becomes so much more effective when the organization and all developers are involved.

The result of Xebia's approach is:

• Project management experiences the architect as a facilitating partner that brings real value
• Project management sees architecture as flexible and able to adjust to changing requirements and changing budget
• Developers become active supporters because they are directly involved
• Architects are not spending enormous budgets on creating extensive documents that prove to be of less and less value as the project progresses
• Architects are involved throughout the project and will be testing the architectural description and removing risks at an early stage