Agile development processes are forcing organizations to change the way they approach enterprise architecture. The old way of building elaborate models and dictating technology choices no longer works in today's nimble and fast-paced development environment. While there may be growing pains as architects learn a new set of best practices for working with developers, the changes are ultimately for the best.
"There seems to be a correlation of success for enterprise architecture teams working in a collaborative, lightweight manner. Teams that are not working like that have a much higher failure rate," said Scott Ambler, senior consulting partner of Toronto-based Scott Ambler + Associates.
What does it mean to work in a lightweight manner? "They're not producing a lot of documents or models because detailed artifacts tend to be ignored by development teams, if they are read at all. They are helping teams to understand what the architectural vision is and [are] actively helping to build it out," Ambler said.
Enterprise architecture best practices, benefits
Scott McBride, senior managing consultant at IBM Rational agreed, noting the importance of having a strategic game plan in mind. "A surefire way to fail in EA [enterprise architecture] is to present a huge program where architects disappear for months and come out with models that no one understands and uses."
There are other general techniques and enterprise architecture best practices that should be deployed. Matt Brasier, head of consulting at Worcestershire, England-based consultancy C2B2 Consulting Limited, said teamwork is one of those basic fundamentals.
We're now in EA 2.0, and we've learned from our mistakes.
senior managing consultant, IBM Rational
"The key best practice is for the architect to focus on architectural principles and [to make] sure that everybody in all of the teams -- business people, developers, implementation teams -- understand that there's a set of principles that need to be kept in mind, and why they're there so that people buy into them," Brasier said.
Once people see value in incorporating enterprise architecture best practices, McBride said they are more willing to follow them. "We're now in EA 2.0 and we've learned from our mistakes. The principles remain the same, but we have learned from software development -- i.e. build fast and build, test, build, test, repeat, he said. "In EA, build pieces of EA fast, then communicate them, test them, and get feedback on them."
Maja Tibbling, principal enterprise architect at Portland, Ore.-based Con-Way Inc., agreed there are significant benefits in abiding by certain rules. "Part of the inputs to each Agile initiative need to be architectural principles, guidelines and standards, as well as discovery tools to find out what already exists that could be reused," she said. This, of course, requires a strong communications plan consisting of ways to use social media platforms and get feedback.
It's not enough to simply communicate enterprise architecture best practices and expect developers' strict adherence. Since Agile methodologies support changing requirements, architectural requirements must evolve as well. "Empower development teams to make some decisions themselves, and flag up when things aren't compliant with architectural decisions," Brasier said.
Agile development recommendations
It also helps to have architects work closely with development teams to facilitate the incorporation of architectural principles and help steer changes. Fred Albert, senior director of enterprise architecture at Mitchell International, a San Diego-based provider of property and casualty claims management technologies, said his team of 10 architects are directly involved with each Scrum team and provide technical consultation and design and review capabilities. "It's not the ivory tower type of architecture, which is often the case in more waterfall approaches," he said. "Architects are embedded in the teams and focused on supporting them in just-in-time design."
This goes back to Ambler's recommendation of working alongside the development teams. "By rolling up their sleeves and helping the teams do the work, there's a much greater chance of the team leveraging what the enterprise architects are trying to promote," he said.
While most enterprise architecture best practices put the responsibility on the architects to modify their work style in order to accommodate Agile development teams, the onus isn't completely on them. Developers can help by addressing requirements head on.
Brasier recommended, for example, dedicating every fourth iteration to architectural debt during which nothing is delivered to end users. "Spend an iteration just working on reducing technical debt and meeting functional requirements," he said.
This gives development teams an opportunity to address components that might not be working in the best way or aren't complying with architectural principles. "This works quite well because it gives a strong focus on architectural requirements and non-functional requirements -- and those tend to be the things that are missing otherwise," Brasier said.
Tibbling said her organization uses a similar approach. "At Con-way … we use an Iteration 0 to address any major new or changed architectural requirements. During that iteration, technical spikes that may require more time are identified and accommodated for in the iteration planning," she said. "A technical spike may include the introduction of a new technology, data migration, etc."