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.