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.

Repeatable results over repeatable processes

DAD teams focus on producing repeatable results, such as delivering high-quality software which meets stakeholder needs in a timely and cost effective manner.  DAD teams do not strive to follow repeatable processes.  The observation is that because each DAD team finds themselves in a unique situation, to be most efficient they need to follow a unique process tailored to reflect that situation.  That “unique process” may be comprised of a relatively standard lifecycle and common practices such as architecture envisioning, database regression testing, non-solo development, and many others (granted, those practices may be tailored to reflect the situation too).  The point is that each team in your organization may follow a different process, albeit processes which share similar components defined by a common process framework, while achieving the results required of them.

This may of course be heresy in some organizations.  The danger with “repeatable processes” is that they grow in size over the years to address all possible situations, and as a result address none of them very well.  Imagine a project team that is large and has regulatory compliance concerns.  This team will tailor its practices accordingly.  Now imagine a small team that doesn’t have to address regulatory concerns.  An organization focused on repeatable processes might have that team follow the same process that the previous team followed, even though some of the practices had been tailored to meet scaling factors that don’t apply.  In other words, the repeatable process included some aspects that were overkill for the second team, thereby impacting their ability to deliver in a timely manner or in a cost efficient manner.  In the vast majority of organizations, when given the choice, stakeholders prefer to spend the money wisely and have the solution delivered in a timely manner, not to have the team follow a consistently “repeatable process.”

Adopting a Full Lifecycle Requires Discipline

Despite some agilists reluctance to admit that projects go through phases the DAD process framework explicitly recognizes that they do.  Building serious solutions requires a lot more than just doing the cool construction stuff.  It takes discipline to ignore this rhetoric and frame your project within the scope of a full delivery lifecycle.  The basic and advanced/lean DAD lifecycles explicitly depict:

1. Pre-delivery activities.  There are portfolio management activities which occur long before your project begins, including the initial identification of potential projects, their prioritization, and finding initial funding for the Inception phase.
2. Three-phase delivery lifecycle.  Projects have phases that they go through.  All efforts are initiated at some point, all of them go through a construction effort (or a configuration effort in the case of purchased solutions), and hopefully some sort of deployment effort.  This is why the DAD lifecycles include explicit Inception, Construction, and Transition phases to respectively address these aspects.  I’ve confirmed via surveys that the average agile team invests about a month in project initiation/inception activities, often referred to as Sprint 0 or Iteration 0, as well as about a month performing release/transition activities.  From a product point they will go through at least the Construction and Transition phase many times throughout the life of the solution.
3. Post-delivery activities.  The fact that your solution is operated and supported in production, or in the marketplace for commercial products, is included.  We do this to reflect the DevOps reality many DAD teams are in the position that they are working on a new release of an existing solution, and therefore are very likely to be getting defect reports and enhancement requests coming in about previous versions.  As a result they require the discipline to treat these things as potential new requirements and act accordingly.

Without a doubt construction is an important aspect of the overall Disciplined Agile Delivery process, but it’s not the only aspect.  Yes, for many people this is the fun part of delivery, it certainly is for me.  But the reality is that as development professionals we need to explicitly consider more than just construction if we’re to be effective.  It takes discipline to adopt a broader lifecycle that goes beyond the fun stuff that we would prefer to focus on.

DAD Book Launch at Innovate 2012 in June

We are thrilled to confirm that our new book “Disciplined Agile Delivery:  A Practitioner’s Guide to Agile Software Delivery in the Enterprise” will be launched at the IBM Innovate conference in Orlando June 3-7.  It will be a busy week with the following events planned:

Scott will be co-delivering the Agile Transformation track keynote on Tuesday morning with Scott Rich, the development leader of the Jazz team. That afternoon he will be a participant at the Agile and Systems goldfish bowl. Wednesday morning Scott will be delivering his Disciplined Agile Delivery and DevOps talk and then in the afternoon giving an overview of Agile Modeling and Documentation strategies. Throughout the conference Scott will be meeting with customers, contact your IBM sales rep if you want to organize such a meeting, and doing several press interviews.

On Wednesday Mark will be speaking on “Disciplined Agile Delivery:  Adoption in the Trenches”.  On Monday he will be on the “Agile Coaching 101 Panel” with agile/lean thought leaders such as Mary Poppendieck.  Mark will also be at the Canadian reception Monday night at Blue Zoo.

Mark & Scott will also be doing a book signing on Wednesday at the bookstore.

If you miss the signing and want a book signed, try the Agile Transformation Zone in the Exhibit Hall.  There is a good chance that you will find us there, comparing notes with other agilists and discussing the challenges of disciplined agile adoption in the enterprise.

It promises to be a fun week, with the party at Sea World and the band Foreigner playing.  We hope to see you there!