I'm reading the book "The Software Architect's Profession" by Marc and Laura Sewell (Amazon link) and it got me wondering whether a software architect is a part of the old non-agile BDUF approach.
Is there a place for software architects in an agile approach? I'm especially interested in Scrum.
BTW I currently am the Unix Application Architect for a major company.
cheers,
Rob
I would think that this is more a skills issue than an approach issue. So yes he may have a role even if he has that title.
I would say that there certainly is. Even though the focus in agile is on developers being free to deign their own code there is still a need for an overall program design at a higher level than an individual developer would be working.
Totally.
The development/project process that you have mentioned are for building the things that the architect as designed.
So the often used analogy, the architect designs and plans the - city, the roads, the buildings.
The developers build the city, the roads, the buildings.
The developers can use what ever project managment system they need to get the building up, cars on the road and the city functioning.
Just as building architects are on hand to oversee the building with the engineers, so too should the software architect be on hand to oversee the development process.
Both roles Architect and Developer are related - but can follow different process to achive their own work programme.
Absolutely yes, especially on medium to large projects. An architect provides technical direction by having a bird's eye view of the project and is responsible for assessing and mitigating technical risk. Developers tend to have a narrower focus and are less exposed to high level concerns.
Sure.
Remember - agile isn't a 'bring me a rock' approach. There are still requirements, still a design and still a need for a solid architecture.
When you are building a product or product line and employing Scrum or some other agile approach to managing your project, one of the key ideas is developing a short iteration cycle, prioritizing the backlog of tasks to accomplish, determining what is going to be in iteration A, B, C, etc. There is where an architect can really be valuable. Having someone with a clear idea of how X, Y and Z all will fit together can make your Scrum iterations that much more productive.
Agile development does not means anarchist development, it still need to be coordonate in order to stay maintanable over time.
But... Maybe the biggest difference between waterfall methodologis and agile methodologies, is that where you'll find a software achitect PERSON in the waterfall, you'll probably software achitect SKILL in agile developpments. I mean, as people are working more tidely toeghether, there is a high chance that skills become over time more shared accros the hole team, which is good.
Of course the software architect "leader" will be the one that keep the big picture in place and ensure that all the building blocks are consistent, but he won't be the only one to refer over the time, as his knowledge will be teach to the others.
However... Agile is best for small projects, and specialized Architects normally are more useful in large projects.
The way I think with would work well, is if the Architect lays down the over all road-map and defines the necessary modules along with team leaders in a Scrum fashion. However then the Team leaders and their Scrum teams do the the actual development.
Kind of a two-staged Scrum.
My role as architect in Scrum includes the following.
Technical spikes -- proofs of concept -- how will we do that. ("It would be simpler if you'd simply using the SMTP library directly, it already wraps the existing SMTP libraries; writing your own wrapper around our wrapper doesn't help much. We can add the method you want.")
Coordination among the developers to fit the intended architecture. ("Ummm... why are you using your own properties file?"
Working with users to prioritize the backlog appropriately. ("These three are related, if we do one, we get the other two at almost zero extra cost.")
Working with managers to cost the backlog. (No, a project manager can't do this; they don't have the technical depth. No, the programmers can't do this, they don't have the overview.)
Articulating why the package names are that way, and why the data model has those features.
Finding the things we're missing and reprioritizing the backlog on technical grounds ("We're going to need this additional sprint to integrate [X], upgrade [Y] and replace [Z] or we'll never get those sprints done.")
Even in an Agile methodology, which may not have a strict hierarchy, programmers are not going to be equal. You will have seasoned campaigners, beginners, those who know the codebase and the problem domain backwards and combinations of the above.
I think that although there may be not "formal" architecture on a truly agile project, there are always architectural concerns that need to be addressed and it is generally the more experienced team members that will have the knowledge to address some of these things.
And also keep in mind that the internal project method may be separate from the pay-grade - so a title may largely be ignored "on the job" so to speak.
+1 on S. Lott's answer. The architect's role is important, but an agile approach begs for the architect to come down from the ivory tower and get his/her hands dirty with the team. This can be hard, as ivory towers often lead to disconnectedness with the craft of creating the software.
Absolutely. No reason the architecture has to be done all up front anyway.
We've been practising Scrum successfully for 1 year and what we've experienced is that there are two things that have to be balanced: -System Architecture is an important "counterweight" in a purely feature driven development environment. Strategic and mid-term planning on technical level has to be done explicitely as Product Owners focus on the next features they want to be implemented (which is of course ok for their part) -On the other hand being truly agile means that -System Architects should not sit in ivory towers (as mentioned in several previous posts) and design things that work in theory only -Knowledge should be distributed so that every team has sufficient architectural skills
Our solution was the following (we are working in a multi-team environment): We created a virtual team lead by the Lead Architect (who is not part of a Scrum team). Each team decides for each issue that has to be discussed which members want to take part in the discussion. The team makes a common decision. If additional work is necessary this is either done via a new user story or if it is small outside of Scrum. The team members who comitted themselves to the decision are responsible to communicate the decision and control its execution within their teams.