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.”

O’Brien explained that while the vendors’ focus on tools for modeling provides a decent framework for conversations about the architecture, not all projects and tools require the same types of conversations.

“Heavyweight tools are not good for lightweight methods. Tools don’t necessarily deliver the value they claim to deliver,” he said.

O’Brien added that teams have learned, throughout the past decade or so, that you can have a lot of success without spending a lot of money on tools. The whiteboard, in his opinion, is still the ultimate tool.

This tool, however, does not work for very large teams or distributed teams. Co-located teams can even have a hard time keeping track of all the updates, according to Tim Hahn, distinguished engineer and chief architect for enterprise tools at IBM Rational.

He explained that teams are now looking to collaborate on a more granular level and often need to use a tool to keep track of these communications.

“I’ve noticed with the passage of time that [architectural development] is much more of an iterative process,” said Hahn. “In the past, architects would go off into a room, create the architecture and hand it to coders or programmers. Now, teams design architecture, write a bit of code, and then tweak design and the architecture.”

This new way of working has, according to Hahn, paved the way for new tools that bridge the communication gap.

“Development and operations have always had a hard time communicating and combining their goals,” he said. “Development is always pushing for the ‘latest and greatest,’ while ops is driven by what’s available.”

IBM Rational has created development topologies within Rational Software Architect to help teams communicate using a universal tool and language.

Hahn said teams can draw models and add text in order to thoroughly explain the models. They can then attach these collaboration items to other requirements tools and development management tools.

The topology module within the Rational tool flags where requirements haven’t been met throughout the process to alert teams of holes in the architecture or code. This, Hahn said, can help with iterative testing, up-front design and communications.

Moderation is key
Benjamin Day said that the best advice for programmers or development team members interested in being a software architect is to be careful about over-committing.

“A software architect shouldn’t take on too many projects or too many roles within individual projects,” he said, adding that, should a team choose to use Scrum, the architect should not take on the role of Scrum Master or project manager or team lead, although it may seem like a natural transition.

“The keeper of the process (the Scrum Master) doesn’t have to be especially technical, but he does have to say ‘no’ to the software architect at times, so it is a conflicting role,” Day said, explaining that at times the Scrum Master will have to make decisions related to costs and other business objectives that may not mesh with the architect’s desire to utilize the newest technology.

Ultimately, Day said, the software architect is a development team member who knows the right answers to a variety of questions and can be looked to to provide the skeleton for a development project.

O’Brien also stressed the need to focus on architecture, as that, in his opinion, is the key to reducing technical debt (the costs incurred by companies when code needs to be reworked or debugged) and producing solid, secure code.

“If you’re not spending effort on the project at the architectural level, you face the serious risk of reworking huge chunks of code after deployment,” he said.

O’Brien believed the focus within the software development world will eventually shift back to a more neutral position: focusing on both the higher and lower levels of development. This shift, he said, is currently happening, but will be pushed further by a new generation of thought leaders, the likes of which he has yet to see.

“We need a new generation that understands the agile perspective, culture and evolution, but also understands how important and complex architecture is,” O’Brien said, echoing Day’s advice for new software architects to be individuals with good people skills, and who understand the needs of both the business team and the development team.

O’Brien said that agile has the momentum to spread beyond development teams and traditional companies, and as it spreads, he believes that these thought leaders will emerge as their predecessors did—from frustrations within the work place and a belief that there are better ways of creating software.