I got interviewed for an article in SDTimes a while back and it just dropped. The article talks about the changing duties of the software architect with an emphasis on Scrum and Agile. (Thanks to Victoria Reitano for giving me a call.)
August 8, 2011 — (Page 1 of 4)
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.