Series: How to Kill the Architecture Department? Part 2

Herbert Schuurmans

Part 2: Where is the employee formerly known as Architect?

The agile organization model

In the first blog post in this series Adriaan described a reference model for agile organizations. In other words: how an idea can be transformed into cash. An idea is prioritized together with all other ideas. It then gets planned, after which the idea is broken down into epics, user stories and tasks. At the end working software is deployed to production. In this process Product Owners play a key role. They coordinate the process to get ideas prioritized and user stories ready. Their main focus is business value. But, how about all those technical features and aspects? These technical features and aspects are the subject of this blog post.

Focus on business functionality

In the process described in the previous paragraph the focus is often on business functionality. The general reason is that Product Owners are members of a business department and therefore have less affinity with technical aspects. A second reason is that technical stakeholders like the Operations department are not always recognized as stakeholders. And a third reason could be that technical stakeholders are unable to explain the business value or needs for technical changes to the Product Owners. As a result necessary technical changes get less or no priority. The consequence is technical debt which can take a lot of effort to eliminate when it becomes necessary.

How can technical changes get more priority?

To give technical changes more priority a person is needed who is able to explain the value of these changes to (chief) Product Owners. At the same time the system architecture remains of vital importance. For that we still need someone with an overview off the IT landscape, the software architecture, etc. Someone who understands the impact new functionality can have on the technology stack. And who is able to support the dialog between the stakeholders together with the Product Owner. What we need is someone who is accountable for all technical aspects of the requirements and software, just like the Product Owner does for the functional aspects: a Technical Product Owner (TPO).

A what...?

A Technical Product Owner takes ownership for all technical aspects regarding the creation of software, from concept to cash. In this sentence the emphasis is on ownership. What does this mean? Where a traditional architect is standing on the sideline, a TPO should be in the middle of the creative process and feel responsible for all technical aspects of software development: the way both functional and non functional requirements are implemented, whether it is a database upgrade or a whole new architecture to be ready for further business requirements.

Many traditional architects prescribe developers what to do and how to do it. This doesn't work in an agile process since not all requirements are specified in advance and teams are encouraged to make their own decisions. The Employee Formally Known As Architect should therefore act as a Product Owner, a Technical Product Owner. He should discuss the business requirements with the Product Owner, analyze these and explain the options. On the other hand he has to be able to explain the need for certain technical changes.

How are Technical Product Owners organized?

Developing software is a team effort and a team responsibility. Architecture is part of that. But this can't always be covered by one person. To get for example ideas prioritized, you need more political and less technical skills then to divide epics into user stories, especially in a large organization. To get ideas implemented it is the other way around.

To get user stories READY a Technical Product Owner assists a Product Owner. I deliberately write assist because it is the Product Owner who remains responsible for the product. The reason for this is that in the end it is business value that needs to be implemented. Necessary technical changes, from a database upgrade to a large architectural change, therefore need to have business value.

Just like a team of Product Owners, a team of TPO's can be lead by a Chief Technical Product Owner (CTPO). This CTPO assists the Chief Product Owner to get ideas PRIORITIZED. Depending on the the amount of work this can be done by a specialized person or by one of the TPO’s.

There is no separate Product Owner in the DONE phase, but a TPO-like technical lead already exists: the Senior Software Engineer. He takes the lead in getting user stories DONE. The same applies to PRODUCTION. There is also no Product Owner in Operations. But for the technical aspects there is a Senior Operations Engineer.

These four technical leads work together and work closely with the (Chief) Product Owners. It might seem that these four leads are performed by different people. But that is not necessarily so. Depending on the type of organization, size of the project or program and skills required all these roles can be done by one person.

Stay tuned for the next episode of How to Kill the Architecture Department

In the next four posts these technical leads in all stages from concept to cash will be discussed. This will start with the Chief Technical Product Owner. What is his relation with the Chief Product Owner and the Technical Product Owner? And how can he represent the technical stakeholders? Stay tuned...

Comments (2)

  1. Dave Nicolette - Reply

    August 14, 2012 at 12:34 pm

    Renaming "architect" to "technical product owner" doesn't change anything substantively. The key change is the transition toward a collaborative approach to solution delivery, which includes architectural work along with other work. Your description of the technical product owner role covers this transition, but the title of the series is misleading because you aren't actually eliminating anything.

    I might be mis-reading this, but it seems as if the focus is 100% on application architects, sometimes called solution architects. Applications don't exist in a vacuum. There is no mention of enterprise architects, who are responsible for providing a reliable and consistent technical infrastructure that supports a variety of non-functional attributes around governance, capacity planning / scalability, security, branding, business activity monitoring, and so forth across all the applications in the enterprise, while also providing shared technical assets such as rules engines, ETL facilities, portals, and so forth. This can't be handled at the level of individual teams or, still less, individual projects.

Add a Comment