This Blog is a kick off to for many writings about architecture in an Agile World. We will explore the topic from all the views possible, in order to gain a better understanding about it. By doing so, we hope to create a community of followers, who would also like to contribute or discuss about this topic.

Xebia is helping many organizations in the Netherlands, France, the United States and India with implementing an agile way of system development. In most of the cases the Scrum method is applied and very good results are achieved. Business and IT are working much closer together, resulting in more quality and much more customer satisfaction. However, lately we also see a trend in problems that seem to occur in (almost) every organization. Software is developed in a fast way with high quality, but it takes forever to get it in production. The more teams are being formed, the more interdependencies between the teams occur, disturbing the heartbeat of the teams. Teams have to wait for other teams to finish, or they have to work together to complete the work. Also it’s not always clear which team should do which job. Next to this product owners are being over asked. They have to supply the teams with user stories / epics, but also have to know upfront which team to ask it, have a clear understanding of the direction of the solution and at the same time define non-functional requirements like availability or system responsiveness.

The scrum masters in the teams are not able to solve all this. They have the interest of their team at hand and are mainly focused on the process to do a good job. They are less focused on the contents of the product backlog or how team deliverables are related to the broader context. However the real situation in many organizations is different. The environment of scrum teams is complex and often not very agile. Scrum teams need to work in the context of an existing organization, which has formed over years. To be able to do so, they need a context. Especially the context in the content in important. Here is where architecture comes in.

The picture below shows how Scrum synchronizes the business cycles with the IT project cycles. Without Scrum the time lines for supply and demand are out of sync. By delivering software faster, Scrum is able to follow the priority of the business and develop IT systems which are in line with current demand (not with a demand from last year). However, businesses also have a longer term strategy, which can make them give significant competitive advantages in the near future. To be able to direct the IT development towards this longer term goals, the business needs architecture. In this way the short terms Business cycles and IT development cycles are in sync, but they move forward towards reaching the ultimate business goals. The picture shows the three different stages from being out of sync, to being in sync and also be moving towards the strategic goals.

Therefore, architecture in the agile world has a very important role to play. However it has to adapt to the new way of working and the new way of looking at the world. In an earlier blog from Xebia, we talk about the 3 C’s of architecture. We defined three goals of the architecture function in IT organizations: The Three C’s of Architecture. These are: Connection, Cohesion and Changeability. Taking these as the prime principles of architecture provides focus on what to do and how to position architecture in the Agile organization. We deliberately do not speak of “the architect”, because architecture is created by many people: domain experts, (experienced) software developers, testers, operations people, software architects, enterprise architects, etc. Therefor we will talk about the architecture role.

The Connection with organizational goals is achieved by using enterprise architecture as a way to create a common understanding about the business and IT in the future. But also the architecture role plays an important part in helping the product owner(s) to specify their requirements and give directions to possible solutions (in line with the enterprise architecture). Cohesion between teams and cohesion between teams and their surroundings, are the main aspects the architecture role has to focus on, by helping the teams getting more productive. Finally the architecture role focuses on Changeability by continuously evolving the architecture and adjusting it to the real world. Architecture creates its own learning cycle. Next to this the modularity of the architecture has to be taken care of, so software is easily adapted without too much interference with other elements in the architecture.

In the coming months we will write a series of blogs, about several aspects of architecture in the agile world. First of all we will write about experiences in the field. How things are done. What can be done better and which lessons are learned. Next to this we would like to present out view about the architecture role in an Agile environment. Which tasks should be done, who contributes to creating architecture. Also we would like to write some blogs, about tools and methodologies used to be able to fulfill this new role in the best way possible. Finally we would like to talk about the architecture itself. How can we make architecture agile? How do we modularize the application architecture, or in what way does virtualization, provisioning and automated deployment help? With all these blogs we intend to redefine the world of architecture in the agile world. Comments and opinions are most welcome, so the architecture and agile communities merge together with a way of thinking on architecture.