Tag Archives: architect

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.

Advertisements

Cross-functional product management teams

Over the years, we have achieved some success with the cross-functional software delivery teams established (well, popularised) by lean and agile methods. More recently, the perspective has broadened somewhat to delivering usable solutions rather than working software.

I think it’s time to broaden the perspective a little more and to think of software-supported solutions in terms of products more consistently and to manage them accordingly. Kristofer Layon’s book Digital Product Management is a good start.

My experience mostly comes from fairly sizeable digital business initiatives in fairly sizeable organisations. While your mileage may vary with the size of the initiatives and the (network of) organisations you are involved, I believe that the basic argument put forward in this most still holds true in a smaller context.

Years ago I’ve seen projects succeed whose leadership included a competent functional architect and a competent technical architect. This duality was de-emphasised by the Unified Process with its strong focus on the (fairly technical) software architect role and by Scrum with its focus on the (fairly functional) product owner role. To make things worse, providing the “content leadership” (a better term, anyone?) on any sizeable initiative is a tall order for any single person, at least in my experience. Disciplined Agile Delivery begins to address this issue be re-emphasising this duality with its product owner and architecture roles.

To me, this looks like a good start but I think we ought to go a step further: I suggest that introducing cross-functional product management teams is likely to yield similar benefits in the area of “content leadership” as introducing cross-functional solution delivery teams did in the area of producing software-supported solutions.

For example, in addition to business and technology design expertise, we certainly want to include experience design expertise in the product management team in most contexts. Other expertise can be added as and when necessary.

In addition to the immediate benefits of the cross-functional approach, this will also help to reduce the load on the two people that used to be “the architect” or “the product owner”.

In the type of contexts that I tend to work in, this leaves a digital business initiative with three major groups: project management, product management (in a staff position to project management) and the delivery team(s).

The concerns addressed by these groups can be delineated quite nicely, which offers the benefits of clear focus for each of them. In combination with a shared purpose, these clearly defined responsibilities provide a strong basis for collaboration across these groups’ boundaries