The role of the software architect has morphed into a project manager, forward thinker and business analyst all rolled into one, according to Benjamin Day, owner and founder of Benjamin Day Consulting. While vendors and architects disagree on the responsibilities to be taken on by the new software architects, they all agree that agile is the force driving this change.

“With the rise of Scrum, [development teams] aren’t doing big design up-front anymore,” said Day. “In my career, it’s more and more of a collaborative process within the development team to figure out what the right architecture is. Frequently, the architect is also the middle man between the dev side and business side, helping each to understand the other’s ideas and mission.”

This idea of a software architect as a business analyst is a result of Day’s experience as a consultant for a variety of development teams working in small and large enterprises. Business analysts aren’t going away, but within collaborative teams, architects are taking on portions of their role to communicate the needs of the development team and ultimately achieve an understanding of the business side of the process.

Businesspeople are not as tech savvy as coders are, and someone is often needed to bridge the gap between both teams to help them understand their different roles and objectives within the Scrum development cycle, a role Day has found himself in frequently.

“The biggest change in the software architect role is to help the business team get comfortable with Scrum because now there are metrics showing how well each team is working throughout the process,” Day said. The inefficiencies shown by the Scrum metrics, such as those that measure the efficiency of deployment schedules, are often hard for the business team to cope with, in his experience, as business team leaders often believe that slow release cycles are caused solely by the development team.

Larry O’Brien, consultant and columnist for SD Times, believed that the software industry has started to shift focus from a high-level view of the development process to a lower-level look, mostly prompted by the agile movement. Agile doesn’t really buy into the value of high-level architectural modeling tools sold by vendors, he said. Instead, architecture should become important now.

“Teams are facing multiple platforms, devices and environments; architecture is very important, but most teams aren’t remarking on the development of the architecture,” O’Brien said.

“I don’t think the agile focus on value is wrong, but if all you focus on is near-term value, you run the risk of putting yourself in the box.”