Tag Archives: people

Liveable application landscapes

Sarah Mei published a Twitter moment titled Livable Code.

The moment’s description reads:

“The modern practice of software isn’t much like architecture or construction. The buildings are largely built. These days, we make a pre-built space work for whoever lives there.”

Sarah talks about the differences between a staged house and a liveable house, and uses this as an analogy to discuss codebases in textbooks vs. in real-life systems. Go read these tweets, although I’ll mostly just riff on the description. I’ll wait.

Let this sink in:

“The buildings are largely built. These days, we make a pre-built space work for whoever lives there.”

I still see a surprising amount of custom software development in companies, but I’m convinced we’ll see better decisions on what to build and, more importantly, what not to build in the future. Building software to “make a pre-built space [i.e. COTS software] work for [the company and its people]” can be very worthwhile, writing yet another variation of CRUD code for customer addresses or basic product information usually less so.

As a side note, “[making] a pre-built space work for whoever lives there” seems to be what a sizeable chunk of today’s practice of architecture and construction is about. In this context, I enjoyed How Buildings Learn: What Happens After They’re Built by Stewart Brand very much.

In the early 2000s when Enterprise Application Integration was all the rage, Gartner predicted that companies would begin differentiating themselves less by the features of their applications rather than by the way they integrate these applications. This statement resonated deeply with me and I’ve been waiting for it to become true ever since. (OK, so this might actually be true, but I’ve been waiting for it to become a conscious decision.)

This integration, together with modelling concepts and activities in terms of COTS applications’ data structures and functions, is what makes applications (i.e. pre-built spaces) liveable (i.e. “work for whoever lives there”).

While Sarah wrote about code, I’m convinced her insights apply equally well on higher levels of aggregation such as applications, a company’s landscape of applications and beyond the organization’s boundary into the shared enterprise (i.e. customers, suppliers, partners, and beyond).

To me, “[making] a pre-built space work for whoever lives there” is a powerful metaphor and honourable work.

Sarah, thank you for that.


Originally published on Medium.

Advertisements

Architecture of people-intensive systems

Bob Marshall “didn’t sign up for all this people shit“. Neither did I. But like Bob — and Tom and Stuart and Ruth and Chris and Dave and so many others before me — I’ve come to realise that talking about the architecture of software-intensive systems might be distracting me from the core of the problem of building and running effective systems (although they haven’t phrased it in exactly these terms). Focusing on people and their needs might be a more effective approach. This is tough, at least for me, and I can fail at this in the most spectacular ways.

If a classification seems necessary, thinking of the architecture of people-intensive systems might be more useful to me than thinking of the architecture of software-intensive systems.

It’s the process, not the product

Stuart Boardman retweeted a link to a blog post by Rob Vens: “Software is not a product“.

In this post, Rob argues that we ought to consider our (hopefully ever improving) process of creating software as the primary product of our work rather than the software itself. In this sense, he argues that software is only a by-product of our work.

Interesting. I exchanged a few more tweets with Stuart in which he observed that “product” does not mean (physical) “good”. Indeed, services are products, too, both in a general sense and in the context of Rob’s blog post.

In my experience, clients still want to buy the results of the software process (e.g. an evolving web shop) rather than the collaborative design process yielding this result. This is despite the fact that software development processes and methods can be the subject of great debate at all phases of the sales and delivery process.

But herein might lie great opportunity: What if we could shift the conversation away from that by-product of our work to that collaborative design process that creates that seemingly auto-evolving web shop?

And maybe there is a chance of actually making this happen, if Laura Colvine (via Jeff Sussna and James Rock) is to believed: “It’s H2H: Human to Human“. (Alright, so I’m quoting this out of context.)

I’m well aware that the above is a tiny step for humankind, but it has been a greater and very enjoyable one for this human. Thank you to all of you who contributed to it.

I know realise that “The process is the product” would have been a better name for this post.

De-emphasising organisational boundaries unfortunately not a silver bullet

Many smart people have written many smart things about new ways of organising work that have become feasible in the last few years. Some of these smart people are Tom Graves and Dave Gray. A key aspect of many of these new ways of organising is de-emphasising traditional organisational boundaries, i.e. in effect doing work across organisational boundaries that would have been done within organisational boundaries just a few years ago.

The opportunities this brings have been discussed thoroughly before as actually have been the risks. So the following really is old news…but I feel strangely compelled to get it out of my system:

When you depend on others for critical parts of your performance, then critical parts of your performance actually depend on others.

When operating in a network of nimble and effective organisations this might be not much of a problem—assuming you can reorganise your value stream or value network in a swift and flexible way. Traditional corporate outsourcing can produce scenarios in which several large organisations are tied together by rigid contractual frameworks and complicated operating models over a fairly long time.

In these situations, the partners may feel they cannot obtain and, respectively, provide optimal value, but tragically feel they are unable to do much about it. Sooner or later, organising essential work strictly within the boundaries of the organisation looks preferable.

That sounds like rewinding a couple of decades and starting over. I think we can do better than this.

Going with the flow

A few weeks ago I joined an up-and-running software development (and service operations) project together with a few other people. The team had already launched the first version of the product successfully. We had heard that huge effort had been put in to achieve this success and we had a hunch that the team would likely benefit from a renewed emphasis on certain lean & agile practices. We also had a hunch that the team wouldn’t benefit from us showing up and starting to lecture from the latest Scrum book or so.

I consider us extremely lucky to work in an environment in which we are free to choose our working practices (obviously within reason). I also consider us extremely lucky to work in a great team willing to own their work — and to put themselves on the line every day trying to improve our performance while at same time having to deliver against high expectations.

Listening to the team and the people around us, and establishing a shared understanding of our goals (including trade-off priorities; hat-tip to Alistair Cockburn) and the forces acting on us seems to be the essential foundation for our learning. After that, getting out of the way seems to be the best thing us management types can do. Every so often, we can provide some support and advice, or offer some re-assurance and confirmation. But mostly, it seems to be about getting out of the way and keeping the way clear of other obstacles as best as we can (we have way to go on that one).

Our work practices seem to become more lean & agile by the day, and I think our performance is improving. This post makes reality probably sound easier than it is, but I feel things are going so much better than whenever I’ve seen project teams being instructed to “be agile”.

Consequences of yet-another-architecture-definition

I described my evolving thinking of what architecture is here and how someone called an architect could add value to a team here.

What consequences does this mindset bring about?

  1. Architecture is not a tangible artefact, but a social construct. (See note below.)
  2. Architecture cannot be created directly, but is the result of other activities (i.e. planning, designing, building and sustaining a system).
  3. The team creates the architecture through interaction. Someone called an architect doesn’t create the architecture by drawing diagrams for the team.
  4. Someone called an architect could promote the shared understanding of a system through conversations with fellow team members and potentially creating supporting artefacts.
  5. Someone called an architect may well contribute to making significant design decisions (sometimes called architecture in the sense of a system’s significant design decisions).

Note: I didn’t come up with the notion of “architecture as a social construct” myself. But then again, I don’t seem to be able to find a single source, so I probably mashed up some ideas from the sources on architecture I mentioned before and the notion of “software as a social construct”.

Updates

2013-11-24: Added note on “architecture as a social construct”.

What does an architect do?

I’m still uncomfortable with job titles such as architect used in software-related contexts. Nonetheless, it is difficult to ignore the fact that this title is used and adopted with apparently increasing enthusiasm.

So what do I think an architect does? Or, perhaps better, how do I think someone having the architect job title could provide value to the people she works with?

Against this mental model of architecture, Bob Marshall’s antimatter principle led me to this:

An architect attends to the architecture.

A little longer:

A system’s architect attends to folks’ needs by fostering the shared understanding of this system’s purpose, context, function, form, structure and characteristics.

How do you do that? Well, it depends…mostly on folks’ needs.

For those who’d rather be something than do something: An architect is an attendant to the architecture.

I like this definition of attendant: “a person employed to provide a service to the public in a particular place”. And I like to understand to attend as to look after (source).

Updates:

2013-11-30: Added form, made function singular.
2013-11-08: Added characteristics to definition.

Requesting contribution from others

“I don’t know what you think about this point, but I think <lots of opinion here>…” to me isn’t an effective way to request contribution from others. To me, it can be considered a violent act, especially if others are one’s subordinates.

“What do you think about this point?” at least opens up space for a contribution.

“Would you be willing to share your views on this point?” might be even more effective.

Making good decisions oneself doesn’t scale…

…and usually doesn’t lead to the best decisions the team could make. Enabling others to make good decisions instead (and accepting others’ help in making good decisions oneself) is likely to scale better and to lead to better decisions.

If this works on a nuclear submarine, chances are it works pretty much everywhere else.

I saw the leader-follower mindset in action again. It wasn’t pretty. I intend to do better.