Following the first topic ( emergent products ) on applying Agile values and practices in a Business Intelligence (BI) and data platform domain, this is the follow-up article. What is the impact of Agile on a BI Architecture? Do you need that trusted, integrated data model before you can create value? How do you transition from old-school Foundation thinking into new-school Agile thinking?     Critical Success Factors for Architecture  It is an interesting topic to understand if a group can identify specific critical success factors. The typical Agile remark, in this case, is to translate the architecture into specific business value. Understanding the projected business value for architecture is a way to provide the team guidance. Once the business value is better understood, the next step is simply to start with the development of the solution in “an agile manner.”   One of the critical success factors of Agile teams is to give them autonomy. In this specific case, it means decentralizing the decision-making when it comes to the architecture of the design. Agile teams that have the competence and a clear understanding of the objectives are far better equipped to make decisions on what the solution should look like. You can trust such teams to make the right design decisions faster because they have the information to make them, without the overhead ballast of seeking approval.   This means that agile teams need to be at the core of architectural design choices. The architecture needs to support designing and working in small work packages. That way, it is possible to deliver value to the business users on a regular cadence and to be able to adjust based on the received feedback.   However, there is more to consider for the solution than just business value. Questions on topics like the management of the solution, security, and durability also need to be answered. These factors are often not visible to the business but do contribute to a stable and durable solution.    The implications of these so-called “non-functionals” can be quite large and counterproductive from a business point of view. Traditionally, it meant that a complete framework was needed before any business value could be generated. This takes up considerable amounts of time, endangering a reasonable time-to-market.   The way Agile teams ensure that non-functional essentials are being met is the Definition of Done. The Definition of Done should cover all the criteria that will be needed to deliver a stable, secure, and maintainable solution. The Definition of Done also tends to grow with the maturity of the solution, adding non-functional requirements as needed. In short, no functionality should ever be released without it conforming to the baseline quality standards and architectural guidelines set for the solution. All teams that work on the same product adhere to the same Definition of Done, to ensure that quality is not only built-in, but consistent.    In addition, teams need to collaborate on how to decrease technical dependencies amongst each other, to ensure that integration and stability are safeguarded. Instead of fixed structures, working with agreed-upon design principles and standards makes it possible for teams to operate independently towards a common aligned goal. Ensuring a loosely coupled landscape with common quality standards captured in a Definition of Done seems to be the way forward. These guardrails put structure in place on how parts of the solution interact, while allowing for freedom within the boundaries of the loosely coupled, highly autonomous parts of the solution. This will make it possible to deliver small increments of functionality faster.       Time to market for Architecture  When the architecture is known and the value is set, how can an agile team achieve a good time to market? The most popular comment here was the truly agile remark “get the feedback early.” In this case, that means working with prototypes, small chunks, and regular reviews. We would like to argue that an Agile Architecture is the critical success factor for a good time to market because it supports working in small deliveries.   The challenge is to maintain a good balance between a durable, stable solution based on a supporting platform and at the same time delivering business value. The key here is “just enough, just in time.”   Critical here is validated learning: ensure that you are building the right thing as soon as possible. The key is to start small but think big. Learn what is minimally required for generating insight (for example by mocking a report) and figure out what sources need to be obtained, to reduce time spent on loading and transforming data. Validate that this meets the needs of the customer, then improve or move on to the next item. Build capabilities modularly and evolve them when needed, for example when adding an anonymization strategy for GDPR regulations to an existing data stream.     Takeaways  In this article, we have argued that creating an architecture for a BI and Data platform is like creating an architecture for any other development project. Understand the why of the project. What is the true value of the products that the team wants to create? And make the work manageable. It is like the answer to the question: “How do you eat an elephant?”. Because the answer is quite simple: You eat the elephant in many small bites, one bite at a time.   A concern is how to balance functionality and quality as captured in the non-functional requirements. The answer to this can be by ensuring good practices across the board, and agreements on standards that empower decentralized decision-making, without compromising on key quality aspects. This way, it is possible to deliver small chunks of value to our customers fast, without making any concessions to the qualitative aspects that a customer would expect of the solution. By applying these principles, both information products and the data platform (framework) can evolve incrementally into a complete solution.       Rob Kool  Ivo van der Heijden  Rogier den Dulk