Arc-E-Tect: Where's the Agile Architect hiding?

Nowadays everybody and their mother is turning, transforming into agile beings. But where is the Agile Architect? In October of 2017 I did a presentation at ASAS2017 about the Agile Architect. Ever since I have been contacted about the presentation and specifically about what the architect's role is in agile organisations. Because of this, I think it is time to shed some light on this. Thus... Find out in this post.

Summarising

The Agile Architect is this Product Architect that is taking care of the organisation's software product landscape and maintaining its integrity. The Product Architect ensures that based on the input of the Business Architect and the Product Owner the product landscape is sound, adaptable and delivers overall architectural agility.

The difference between doing agile and being agile

The Agile Architect is a rare beast in today's agile organisations. But before I go down this rabbit hole I need to emphasise the fact that I am talking here about organisations that are agile and not those that are doing agile.
The main difference is that when you do agile, you're living by the book, like a religious zealot. You follow the rules, have your rituals and so on. It typically means that you're organised according to the school of SCRUM. Small teams of max 9 individuals, one Scrum Master, a Product Owner. working in Sprints that take typically two weeks, have your daily stand-ups, your retro's and demo's and a backlog of user stories and epics. In contrast, when you are agile, you're taking the lead from the agile manifesto, do the hard things as often as possible, prioritise your activities according to value, have a build-measure-learn loop in place and determine your next actions based on feedback from your users. This is the short version... Obviously.

Independence and autonomy are prerequisite for Agile Architecture

So having established this, I can continue on the topic of the agile architect. Well, just before I venture into that direction, let me explain that in an agile organisation, you also find a strong longing for independence and autonomy. Mind that it is not anarchy that is sought after. The challenge here is that different teams want to move with different speeds. Often this is called bi-modal or multi-modal (you can read about this for example in my post "Let me spell out why Bimodal IT doesn't work"). It doesn't matter how you want to call it, what it boils down to is that different teams work on different products and the organisation's market dictates that each product needs to adopt to changed circumstances in a timely manner, where 'timely' has different meanings for different products. It's extremely logical and also extremely unsexy. These different requirements regarding development speeds requires independence between products and therefore teams. Obviously, whenever there is a dependence, the speeds are linked and in fact agility is lost. Something I'll cover in another post some time soon.
So independence is required here. Autonomy is also important, because if a team cannot decide by itself how to solve problems, how to implement features, how to enable proper operational management, and instead have this dictated by a third party. There is a dependency with a bottleneck and hence agility is at risk. Look for the upcoming post "The Incompetence of the CC..." that will feel enlightening in case you don't understand this right now. But again, it is in fact quite logical how this all works.

So teams should be able to act independently of each other and should have a high level of autonomy, in fact the organisation should strive for the highest level of independence and autonomy that is possible within the context of that organisation. Note the subtlety of the last part of that sentence; that is possible within the context of that organisation. I am explicitly not saying that all control should be dropped and no governance should be implemented.

With the teams being autonomous and independent, the question about the role of the architect arises. Typically the first question I get is whether the architect should be part of the Product Team or not. And my answer is at all times that the architect is not part of the Product Team, where the Product Team is the team that develops and supports a (business) product. Just like the Product Owner is not part of the team, the Product Architect (that's what I call the architect) is not part of the team. This doesn't mean that the architecture of the software is to be neglected, what I am saying is that the team itself is responsible for the application architecture, referring to the internal structure of the software. There are typically a lot of important impromptu decisions to be made during the development of the software where the right decision is determined by the specific context in which the decision is key. The team knows best. That is not to say that anything goes. I'll get to what I mean by this in a second.

The Product Architect is not so much responsible for the software architecture, but for the positioning of the product in the organisation's landscape.The Product Architect is accountable for the integrity of this landscape. The meaning of this is best described through a use-case.
[Read this post on the importance of accountability and responsibility.]

Agile Architecting explained

Consider an organisation's product landscape to consist of several business domains, each consisting of several business products. A business product is a product that is delivered to a user, often a customer of some sorts. The customer typically accesses the business product through an interface. This could be a specialised App, a webpage or maybe a customer-success-agent. This is sometimes referred to as the business front-end, or the customer interface. What is important here is that the customer is not interacting with a piece of software perse, but instead could be interfacing with another human being. Demonstrating that a business product can consist of man and machine. In addition to this, business products can be related to each other. The final step of using one can lead to using another product. There can be a sequence, just like when you go to the movies. You buy a ticket, you get some drinks and snacks at the concession stand and then see the movie. These are three different business products and clearly the buying a ticket and watching a movie are closely related. But independent since the person buying the ticket doesn't have to be the person watching the movie. Think about gift-tickets.
So you see there are several (related) business products. How they relate to each other is part of the responsibilities of the Business Architect(s), sometimes called Business Domain Architect or just Domain Architect. It is the Business Architects that will typically decide to which domain a business product belongs. Buying things could be the Sales domain and watching a movie in the Media domain, or buying the ticket and watching the movie can belong the the Movie domain and the drinks and snacks in the Concession Sales domain. It's arbitrary but needs to be decided upon, this is what the Business Architect does.
Once it is decided to which domain a (new) business product belongs, it is the (new) Product Owner that determines how the business product is taking shape. Think about the MVP. Often the MVP is a first incarnation of a product, but it can be in fact be a completely different product that is used to verify that there is in fact a need, a requirement, for the new product. An MVP could be a simple teaser webpage announcing the new product or poster with a box attached that potential customers can put a card in saying how excited they are to get hold of the new product.
When the Product Owner ties the knot that software is to be developed, something typically decided after consulting the Business Architect and the Product Architect(s) for the products in a business domain, it is the Product Architect that comes into play. This is where the Product Architect is taking the task to maintain the landscape's integrity. First of all, the Product Architect will have to determine whether or not a new product is to be developed or an existing product is to be enhanced or adapted. In case of a new product development, it has to be determined what the best technology is to do this. Here it is important for the Product Architect to understand the product. The Product Owner is a significant source of knowledge and information here. Who'll be the user of the product and how will the user access the product? What are the security requirements and what about compliance aspects? Transactional integrity is important as well. Also the intended life span of the product is important. And obviously the product's relations and integrations with other products is key and for this the Business Architect needs to be consulted. Obviously all architectural principles are taken into account and the Product Architect will define what principles are such that specific practices are to be maintained. Consider a product that does financial transactions, that could mean that specific frameworks and products need to be used for the implementation. Or the fact that the product is going to be used by students after marketing campaigns, resulting in a deployment in Amazon AWS instead of the organisation's own data centres.
The Product Architect, in response to the Product Owner's requirements for the product, will also be responsible for example to define an API that is published as part of the product offering.

Product Architect vs Product Team

By deciding all this, the Product Architect is to some extent dictating the products architecture, and still it is the Product Team that is responsible for the software architecture and not the Product Architect. So how does this work? Remember I promised earlier in this post that I would elaborate on this.
It is actually very simple and all based on the role of Architecture Principles. The organisation will have its organisation wide Architecture Principles, principles that are to be followed at all times. Possibly depending on context, though. I always like to mention that KISS (Keep It Simple, Stupid) is the prime-directive of everybody. By stating so, everybody introducing complexity is violating this principle. As a consequence, the principle enforces the policy to deliver always the minimum that is required, hence helps implementing a LEAN mindset.
Apart from principles that are organisation wide and principles that are applied in a specific context, emphasising that the context needs to be specific, a Product Architect can also define so called 'local architecture principles' that are local to the teams within the circle of influence of the Product Architect. Think about these as local extensions on the existing principles. Maybe because the domain is subject to some specific regulatory context or maybe because the domain is specific for a specific market.
The Product Teams are always to abide by these principles. So although they have autonomy on how to do things, they need to stay within the framework of these principles. They can't just decide to make an overly complex solution, because that would violate KISS.
In addition, the Product Architect can also limit the acceptable answers to implementation questions. For example the Product Architect can state as a principle that all API's are based on Open Web Standards, but in addition decide that all API's that are exposed on the internet are to be based on REST/JSON and API's that are with business partners to be based on WS-*.

Consequential impact

All the above decisions also lead to other decisions. A decision for a specific deployment platform may mean that only certain teams are capable of doing the development. Or deciding that the product needs an API as well as a web-UI may result in the situation that two teams will work on the product, one on the product with the API and the other working on the web-UI based on the API.
Also, envision the situation where timelines are not really up to the needs of the Product Owner, it is then for the Product Owner and the Product Architect to determine the architectural shortcuts to be taken. Using different technologies to leverage the availability of another team for example.

Concluding

As you can see, the Product Architect's role is very challenging, just like the role of Product Owner. But although it is very challenging, it is also very much scoped towards the external aspects of the products. The scope is about the product in its surroundings. Think about the layout of a street with houses instead of the layout of the individual houses. Of course, the type of house, or rather building is a Product Architect's call. Villa's, brown stones or apartments is up to the Product Architect, not the amount of bathrooms, the type of tiles or the kind of sofa's. That's up to the Product Team in response to what the Product Owner can turn into value.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

Arc-E-Tect

Translate

January 18, 2018

Where's the Agile Architect hiding?