Governing Agile with Architecture
“Architecture needs to radically change to act as an agile partner in governance” sais Jan van Santbrink. At the Agile Governance conference in Amsterdam he presented how architecture when used with an agile mindset can play a key role in governance.
InfoQ interviewed Jan about why agile and architecture need to collaborate, how architecture can support agile decision taking and the benefits for development of doing architecture.
InfoQ: What do you consider to be architecture? Where does it differ from design?
Jan: Architecture is on the component level, design define how a component will be or has been created. Architecture is spanning multiple applications, design can be made for one application.
InfoQ: Why is it important that architecture and agile cooperate? What happens if they don't?
Jan: It is important to cooperate as both architecture and agile will be there over time. In order to avoid doing unnecessary work for either of them, I think cooperation is required. If they do not cooperate, team solution will not fit in enterprise level initiatives leading to higher costs of development and maintenance.
InfoQ: In your presentation you showed how architecture is embedded in SAFe. Can you elaborate on that?
Jan: SAFe takes architecture epics as a starting point and defines architecture features. These features are added to the backlog and will be prioritized with the business owner. If any architecture feature needs to be created in order to support many business features, they are added to the architecture runway developed in a separate sprint but still just in time.
InfoQ: You talked about the role of architecture in decision taking. What kind of decisions do top managers want to take, and how does architecture support that?
Jan: Top management has the task to solve business problems. Architects can support that by proposing solutions to the problem, defining pro’s and con’s and risks and agree on the right solution. This is a high level solution that needs to be detailed before it can be designed and built.
InfoQ: When a company adopts agile are these decisions still needed? Is it still top managers taking them or can they be brought down to team levels?
Jan: Agile will not automatically solve business problems, so it will always be needed to take these decisions. Decision taking occurs on all levels of an organization, Strategic decisions can never be taken at an operational level. If this happens in practice, there is an organizational problem.
InfoQ: Enterprises can perceive architecture and agile as different things which they find difficult to combine. Can you give some examples how they can be combined and support each other?
Jan: My statement is that Enterprise Architecture will always have a top down nature, and agile design and build will have a bottom up nature. Combining them is very well possible by incorporating solution and project architects in the teams. EA can provide you the right work packages based on known dependencies. Agile teams can provide feedback on the guidelines do work in practice.
InfoQ: Do you have examples how you can use TOGAF for enterprise architecture in an agile context?
Jan: My statement is that TOGAF only relates to Enterprise Architecture and is looking for stable elements in the organization. So if you introduce agile EA, it will be an entirely different agility from agile development teams.
InfoQ: What can be the benefit for development to do architecture? Which investment is needed?
Jan: Development can benefit by:
a. Values chains help discover stakeholders
b. Building blocks and dependencies help create the right work packages and teams
c. Top management commitment on the headlines, eliminate unnecessary changes
d. Standards and guidelines
Investment figures are extremely different over organizations, so it is not possible to estimate.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015