One of the challenges that many organizations face with adopting agile practices is the problem of “where does architecture fit?” After all, we are developing software (emphasis on “soft), and that means it can be changed easily. So we do we need architecture anyway?

If all you are developing is software, you can stop reading now. You are not the people who need to hear this.

Step back and look at a company (or enterprise… often the same thing). Think of it as a group of cooperating processes, people with aligned motivations, and a series of financial rewards that keep everyone motivated to perpetuate it and expand it. Can you go there? people, process, reward.

Software systems play an important part.

  • Software systems constrain and automate processes.
  • Software systems illuminate and measure aligned motivations.
  • Software systems remove bias from the systems of reward.

Once you see software as the servant of the enterprise, you can see why software design is not the problem we need to solve. Understanding the context of software in the scope and span of an enterprise is far more relevant.

The difference between Enterprise Architecture and Solution Architecture comes into stark relief when viewed through this lens. While Solution Architecture is deeply concerned with the innovative use of computing resources to address non-functional attributes like reliability, throughput, usability, maintainability, and adaptability, Enterprise Architecture is addressing totally different problems. Many of the Non Functional Requirements addressed by Solution Architecture can, in actual fact, be addressed incrementally through an agile process.

Enterprise Architecture is looking at different problems and cannot be so easily folded away by agile approaches. EA is looking at the structure and informational flow of knowledge. EA is looking at the people involved in making decisions and ensuring that a decision can be made in response to available information, in an efficient manner, by an empowered stakeholder.

From there, EA decides where software should sit and what it should do.

It is up to the solution architects and agile team to figure out how to do it.

So look at your agile processes. SAFe attempts to address both and SAFe has some connection to EA. Typical “Scrum within SDLC” processes get lost in the confusion and noise. So do many architects.

I’ve often spoken about the role of architecture in agile systems of performance. I will keep beating the drum on this because I’ve seen the benefit of an empowered EA figuring out where software should sit and what it should do. And I’ve seen the lost opportunities when there isn’t a person fulfilling that role.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

2 thoughts on “Agility and Architecture”
  1. Do you have a view on how EA ‘governs’ (an unpopular term these days) once had-off to ‘SAs and the Agile team figure out’? How integrated. should the EA be to the Agile projects?

    1. Hi Nigel,
      You asked if I have a view on how EA governs after the hand off. Well in part, EA shouldn’t govern after the hand off in a truly agile model. The role of EA prior to funding is pretty clear: understand the approximate scope and the approximate benefits for doing a unit of work. Make sure that the team understands the enterprise value for that unit of work (including the product manager). But after the hand off, the EA should be working with the product manager to make sure that the right stories are prioritized and that they deliver the right conditions of satisfaction, not working with the team to use a particular API.
      The trick is to be part of the funding process itself. Work with the key stakeholders for the system being changed. Make sure that they see the value proposition for sharing, or not sharing, the information you are choosing to share or not share. Make sure that they see the enterprise value of things that they may not see, like taking a dependency or a particular technology or moving toward a particular platform.
      If your stakeholder understands, you can get your product owner to understand. If your product owner understands, you can impact the conditions of satisfaction for the stories. Do that, and you have the governance you need. In the agile process itself.

Leave a Reply

Your email address will not be published. Required fields are marked *

11 − 1 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.