Agile development methodology has transformed processes, but developers do not operate in a silo. These new processes are forcing other groups, including enterprise architecture, to evolve their own procedures. As a result, the role of solution architects is changing as they learn to adapt their methods to complement today's nimble, fast-paced development environment.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"Agile is all about working in a collaborative, lightweight manner with short feedback cycles -- all healthy things for enterprise architecture teams, but it does require them to roll up their sleeves, get actively involved and work in a collaborative manner. This can be different for some enterprise architects," said Scott Ambler, senior consulting partner of Toronto-based Scott Ambler + Associates.
The change in workflow for enterprise architects is a "natural evolution," according to Matt Brasier, head of consulting at Worcestershire, England-based consultancy C2B2 Consulting Limited. "In the same way Agile developers start to follow the Agile process, architecture is starting to follow, and it changes the way architects engage in projects," he said. "You move away from developing architecture and design in the early phase of the project to a constant set of evolving decisions as you go forward, and you need to re-evaluate decisions as requirements change, so there's a lot more work."
Work side by side
Architects are most successful with Agile development methodology when they get their hands dirty alongside developers. By assisting Agile teams, there is an increased likelihood that the efforts enterprise architects are trying to promote will be leveraged, according to Ambler.
Chuck Faris, senior enterprise architect specialist at IBM Rational Software, agreed. "There is a certain clash of cultures around EA [enterprise architecture] and Agile, and some of this is natural. One way to overcome this is to have multi-disciplinary teams, involve developers and architects on the same teams, and encourage intermingling and cross-pollination."
However, having a relationship among teams doesn't come without challenges. "It requires the enterprise architect to do development and have something to offer," Ambler said. "You end up with an environment that is more of a meritocracy where you're actually able to help rather than just dictate what needs to be done. That's a much harder environment to exist in."
There is a certain clash of cultures around EA and Agile.
Chuck Faris, senior enterprise architect specialist, IBM Rational
In previous times, architects could work on projects in a hands-off fashion, but Brasier said that doesn't work with Agile development methodology anymore. "It's much more involved and much more of a hands-on role than the sort of hands-off architect who would sit in an ivory tower and say what the architecture would be," he said.
Some architects may participate in the process by reviewing code and essentially becoming a "sign-off authority," Brasier said. Others may mingle with the team or participate in pair programming. "It depends on the personality of the architect. Different people work well in different ways."
Regardless of exactly how an architect decides to work with Agile development methodology, it's a crucial step that can help their voice be heard, Abler said. "It's still possible for people to be just modelers, pure architects. But you'll need hands-on people as well, and some kind of mechanism to get your message out there that is coherent and attractive to the development teams."
Be business-savvy and use communication skills
The need for strong communication cannot be underestimated. "One of the causes of project failure is not having a communications plan. Developers need to know what and where the EA is, how they're supposed to use it, and how they're supposed to provide feedback," Faris said.
More on Agile development methodology
Best practices for Agile development
Users: Agile dev worth the effort
How to get started with Agile
For Maja Tibbling, principal enterprise architect at Portland, Ore.-based Con-Way Inc., communication is rooted in the business needs. "The main [skill architects need to learn] would be the ability to articulate the business case for the 'right thing.' … When doing the 'right thing' proves to take too long or is too expensive, making tradeoffs that are still in alignment with the long-term vision is a developed skill. It may mean suggesting twists to the shortcuts that are being put forward without extending the timeline or budget," she said.
To be successful with Agile development methodology, it's important to have an understanding of the business aspect, according to Brasier. "It requires a stronger understanding of what the business requires, because they need to understand when requirements change and what the impact is going to be. Is it a new change or implicitly handled already and they don't need to make a change?"
Tibbling noted the evolving role of architects with Agile development methodology. "Architects are even more becoming sales people, as they need to convince developers, [project managers] and the business sponsors that it is worth investing in 'the right thing' and extending timelines and increasing a project budget beyond the needs of the individual project. Articulating the business cases becomes an everyday thing."
Obtaining a firm grasp of the business side of things may be even more difficult than comprehending the technology, according to Brasier. "It's hard to understand what the business really needs and where business solutions might be better than technology solutions, or cheap solutions might be better than expensive solutions," he said. "It might be better to have a cheap solution that you turn on and off once a day or put a business process in place to deal with that. Quite often, people look for technology solutions to business problems and that gets quite expensive."
Why BizDevOps is going to change the world someday
Why design thinking in Agile has nothing to do with design