Tag Archives: relationships

Fat markers and guided, incremental change

There has been a strong backlash against architecture and, perhaps more to the point, architects in the software development field for many years. One source of that backlash are parts of the agile community. Some of the reasons for criticism are poor practices by some architects as well as a misunderstanding of the suggestion to avoid big design up-front. Software, solution, systems and enterprise architects seem to be the primary objects of this criticism.

To avoid doubt, some of that criticism is well-deserved. As always, the devil is in the details and context matters. This post is not about the details or about who is more wrong.

By and large, that conflict seems unnecessary to me. Many of the ideas popularized by the agile movement have been accepted by people far beyond the software development field. In particular, many architects (in the fields I mentioned above and beyond) don’t need convincing regarding the value of respect for people, cross-functional collaboration, outcome orientation, and responding to change.

Having begun reading their book “Building Evolutionary Architectures: Support Constant Change”, Neal Ford, Rebecca Parsons, and Patrick Ku explain very well how software architects can meaningfully contribute to modern software development efforts.

They describe their notion of evolutionary architecture as follows:

“An evolutionary architecture supports guided, incremental change across multiple dimensions.”

That is certainly compatible with my understanding of architecture and the architect’s role.

Against his information architecture background, Jorge Arango states:

“A design career is a progression from thin markers to fat markers.”

He also highlights the need for design work at different levels of precision:

“You can’t design exclusively using whiteboard markers any more than you can with only fine markers. You need a combination of both.”

Jorge continues:

“As a leader, you don’t necessarily stop being a practitioner; you just move on to a fatter marker.”

Architecture is design, so all of this is also applicable to the architecture fields I mentioned above. It is also compatible with the notion of guided, incremental change, as well as the fundamental principles popularized by the agile community.

Jorge provides a meaningful description of what an architect-as-practitioner looks like. To me, this in sharp contrast to naïve interpretations of the “architects must code” idea. It also is a clear rejection of the idea that fat-marker wielding architects could provide comprehensive, detail-level specifications to those wielding fine markers or IDEs.

While I’m not sure I’ve been actually aspiring to these ever fatter markers, they certainly have been coming my way throughout my career. And that’s alright for this practitioner.


The end of service encounters and customer relationships

I’m currently reading Service Design for Business: A Practical Guide to Optimizing the Customer Experience by Ben Reason, Lavrans Løvlie and Melvin Brand Flu of Livework. I’m enjoying the book so far and am convinced that it will make the field of service design much more accessible to a wider business audience.

The authors have extended the traditional three-stage model of service consumption (pre-purchase/pre-encounter, encounter, post-encounter stages) by another stage (begin) yielding these four stages: before, begin, during, after. Their reasoning for adding this stage is sound:

How customers begin their relationship with a service is critical to success…A good beginning helps to avoid dissatisfaction and makes customers more disposed to do more business with you later. –Reason, Løvlie, Brand Flu

In their takeaway messages for this chapter they conclude:

The beginning sets the tone for the relationship. –Reason, Løvlie, Brand Flu

Symmetry suggests we also take a closer look at how service encounters or entire customer relationships end. Thinking about our own experiences as service customers it becomes clear that the end stage of an individual service encounter or a relationship with a service provider can have significant impact on our evaluation of the overall service experience and the service provider.

For example, being rushed out of a restaurant after a nice meal with our partner (or having to wait too long for the bill) may well spoil an otherwise excellent experience on the finishing line. Similarly, if the service provider makes it difficult for me to leave a service after my needs have changed, my overall evaluation of a satisfactory service experience up to that point will be diminished.

In both cases, my readiness to re-purchase the service will be severely reduced as will be my readiness to recommend the service to others. On the contrary, I’ll probably complain about the service failure to anyone who cares to listen.

The authors seem to recognize this without highlighting the end of a service encounter or customer relationship as a distinct stage:

Past customers are also potential future customers–and are therefore always worth attention. –Reason, Løvlie, Brand Flu

In conclusion I suggest extending the discussion by considering referrals & recommendations by current and former customers, and by adding an explicit end stage to the model, thereby yielding these five service stages: before, begin, during, end, after.