Have not all of us been in a spot where we feel an urgent need to fix some quality such as performance or availability, which takes a change in the architecture for effect? And yet we are pushed to work on new features instead?
There is a chasm between the tech side and business side that has to be bridged before a sound dialogue about system architecture can take place.
If you walk up to the PO and say, “here’s the deal, we add a load balancer and another server so we can handle the increase in load”, you may get a blank stare. If you take hostages or fly under the radar, whatever you think is for a greater good, you will lose trust. The PO and the team have to have a healthy dialogue built on trust and respect and therefore this communication gap must be bridged. The changes to the architecture must be put in terms that make sense in business terms.
How can we do that? The first thing is to understand is that the system’s architecture represents no business value per se. That’s why you have problem talking to each other in the first place. It is the qualities that are affected by the architecture that gives you the business value. As an example, consider the quality performance in the meaning response time performance. There are models for the relation between conversion rate on a web site and response time. No doubt that a slow site will scare potential customers away.
So the discussion with your PO should be along the line that given a number of users, the response time for a class of functions should become lower than today and possibly raise the conversion rate. That’s when a PO can prioritise architecture against new features, when the connection with business value is clear.
To take another example and this time a true story. A client of mine provided web shops for their customers. Each customer had their own branding and content. Also, they had different functions. Every new customer meant setting up a new web site. As it was, the cost of a new web site was 350 SP.
– 350 SP for a web site is too much, said the PO.
– How much would you like it to be, I asked.
– I want it to be 35 SP!
– Ok, good, here is what we’ll do given that constraint. We will change the architecture to provide for an easier way of adding web sites. The overhead will be on top of the next customer’s web site which we estimate will cost 450 SP. The one after that will be down to 35 SP, given our assumptions.
– We have a perfect customer for you, quite mainstream so let’s do it the next sprint!
The quality this time was modifiability, the cost of implementing and deploying a new web site. If we had tried to build that quality in from the first web site, we had been guilty of BDUF and most likely missed the target. After a couple of web sites based on a new web framework (Wicket) and looking at those made with another (home grown) framework, we had the data to get a good idea of what to do.
What qualities are there then? I know of no standard but I have seven in my mind. That’s a healthy number of attributes and they are different enough to not overlap too much and to some extent compete with each other. Yeah, that’s the problem with designing architecture; you get better in one department but worse in another. Makes the case for connecting with business value even harder.
The ones on my list are from the book “Software Architecture in Practice” by Bass, Clements and Kazman. They have six but I added a seventh, scalability.
- Availability
– Percent time a function is available to the user
- Modifiability
– Time to implement and deploy a change.
- Performance
– Throughput as data/time or response time
- Security
– Vulnerability to expected attacks
- Testability
– Time to test a change to the system
- Usability
– Structures that affect usability
- Scalability
– Ability to keep up with load changes
Cost is not a quality; it is often a unit of measurement, to answer a common question.
That’s it for today. Hope it was worth the reading time!
I attended a communications class a few years ago and we were taught that a very good and underestimated way of communicating is providing images and metaphores.
A good metaphor for optimizing architecture, I think, is that it is rarely seen in residential areas that there is an exclusive road to every house, instead the houses share roads until the very last yards, where there may be a little path leading exclusively to the house. This is considered quite natural and not many would oppose to this structure.