Home > Architecture, DAD roles, People > The DAD Role of Architecture Owner

The DAD Role of Architecture Owner


As you can see from this diagram, the DAD primary roles are similar to those of Scrum.  In Scrum, the product owner decides what will be built and in what order.  In DAD we recognize that architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk.  As a result the DAD process framework explicitly includes Agile Modeling’s role of architecture owner. The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.  The person in the role of team lead will often also be in the role of architecture owner.  This isn’t always the case, particularly at scale, but it is very common for smaller agile teams.

The responsibilities of the architecture owner include:

  • Guiding the creation and evolution of the architecture of the solution that the team is working on.  Note that the architecture owner is not solely responsible for the architecture, but that they lead the technical discussions.
  • Mentoring and coaching other team members in architecture practices and issues.
  • Understanding the architectural direction and standards of your organization and helping to ensure that the team adheres to them appropriately.
  • Understanding existing enterprise assets such as frameworks, patterns, subsystems and ensuring that the team uses them where appropriate.
  • Ensuring that the solution will be easy to support by encouraging good design and refactoring to minimize technical debt.
  • Ensuring that the solution is integrated and tested on a regular basis, ideally via the practice of continuous integration(CI).
  • Having the final say regarding technical decisions, but they try to avoid dictating the architectural direction in favor of a collaborative, team-based approach. The architecture owner should work very closely with the team lead to identify and determine strategies to mitigate key project technical risks.
  • Leads the initial architecture envisioning effort at the beginning of the project and supports the initial requirements envisioning effort (particularly when it comes to understanding and evolving the non-functional requirements for the solution).

One of the key reasons for having this role in DAD is that the architecture owner, like the product owner, has a say in work items that are added and prioritized in the work item list (backlog in Scrum parlance).  While business value is certainly a prime determinant of priorities, completing work related to mitigating technical risks is also important.  Additionally, a DAD goal is to deliver consumable solutions, not just working software.  As such, sometimes it is necessary to add work items that are technical in nature, for example related to error logging/monitoring.  Or perhaps work items need to be added to improve the continuous integration and deployment processes.

We have found that the concept of having both product and architecture owners ensures that the solution addresses both functional and non-functional requirements such as usability and supportability adequately.  In fact, on my current project, I worked with the product and architecture owners to negotiate their priorities such that the iteration underway includes not only a selection of high priority stories, but also a set of technical work items related to hardening the solution in preparation for entering the Transition phase of delivering the solution to the stakeholders.  Without a specific role of architecture owner, it can be difficult to escalate important technical work into the work item list.  As as result it is often done subversively without the knowledge of the product owner which is not a healthy practice, or worse it never gets done resulting in a poor quality solution.

Scott has written a good article that describes the architecture owner role in more depth.  You can view it here.
About these ads
Categories: Architecture, DAD roles, People
  1. Anonymous
    May 30, 2012 at 1:09 am

    This is an excellent explanation of how the Architects must be made to fit in to the project by creating a formal role and responsibilities. In our organization the architects are frequently left floating around the periphery of a project once it is under way, without a continuing role or an ability to direct solutions or manage risks. This will be very helpful, thanks.

  2. March 6, 2013 at 11:12 pm

    Hi there, I discovered your site by the use of Google even as looking for a comparable topic, your site came up, it seems to be good.
    I’ve bookmarked it in my google bookmarks.
    Hi there, just was alert to your weblog through Google, and found that it is really informative. I am gonna watch out for brussels. I’ll appreciate if you
    happen to continue this in future. A lot of other folks can be
    benefited out of your writing. Cheers!

  1. December 18, 2012 at 1:18 pm
  2. May 30, 2013 at 9:49 pm
  3. November 10, 2013 at 1:00 pm
  4. June 9, 2014 at 8:33 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 624 other followers