Tag Archives: architecture

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.

Enterprise Design Framework: Anatomy

Yesterday I said how valuable I thought Intersection: How Enterprise Design Bridges the Gap Between Business, Technology and People by Milan Guenther is and talked about a few things I view and do differently with respect to the enterprise design framework’s Big Picture layer.

Today I was going to write about things I view and do differently with respect to the anatomy layer…but it turns out I already did:

Content strategy, service design and physical objects

In this context you also have to ready Mapping the Enterprise by Tom Graves.

 

 

Design Visualization: Smoke & Mirrors (by Ruth Malan)

My friend Marc pointed me to the slides of a presentation given by Ruth Malan last year. (I also found a version with her notes here, but haven’t read through them yet.)

As usual, Ruth’s material is incredibly dense, i.e. lots of information, thoughts and insights in a small space. Don’t be fooled by her friendly and casual tone: More often than not I find myself happily trotting along with the conversation — just to go back because I realised I probably missed half of what she said. YMMV, though.

I found the thoughts on system design intent vs. system design reflection intriguing.

Whole-of-system architecture

Tom Graves writes about whole-of-enterprise architecture, where the enterprise is far greater than any single organisation or even individual markets. Similarly, whole-of-enterprise architecture concerns go far beyond the technology domain.

When working at the scope of individual systems, I have realised that we can benefit from taking a similarly whole perspective: I suggest thinking in terms of whole-of-system architecture can be useful and, in my work, necessary. Software systems certainly play an important role in my work, but people play vastly more important roles. As do relationships between people, groups of people and various forms of organisations. Furthermore, we need to talk about processes and data. The list goes on an on.

Even when thinking only about the technology aspects of such whole-of-system architectures, we usually have to consider runtime (or deployment) architecture concerns, development-time concerns (form, function and structure of code) as well as the tools and processes for helping us to build, deploy and manage the technology components of the system.

Thinking about this further, we might consider a system in this broad sense to be a fractal element of a larger enterprise, and therefore, perhaps, a small enterprise in itself. Consequently, whole-of-enterprise architecture insights may well apply. If so, whole-of-system architecture can then be understood as a specific type of whole-of-enterprise architecture (i.e. one tied to the system scope).

Having gotten the above out of my system, I can now start to sort it out. Would you care to help?

Networks of independent agents…and coffee

A few days ago, Laura Colvine said this on Twitter:

David takes on Goliath – Cups: A Coffee Startup Taking on Starbucks

The link pointed to an interesting and well-written article by Alison Griswold titled “Cups: A Coffee Startup Taking on Starbucks“.

In brief (and much less well-written than the original), the story is approximately this: Cups, an Israeli startup, offers bulk subscriptions (5, 10 or 20 cups) and monthly all-you-can-drink monthly subscriptions to customers of participating independent coffee shops. It uses mobile app technology to facilitate coffee shop discovery and location, subscription management and payment. Cups pays the coffee shops per cup, albeit at a highly discounted price, but assumes the risk associated to high consumption by monthly subscribers.

I like this idea very much: I like how technology is used to facilitate an idea that mostly plays out in the “real” world. I like how this idea seeks to level the playing field for small independent agents in a highly contested place. I like how the independent agents’  individual strengths and characteristics are preserved in this scheme. I like how this sustains and maybe even enhances diversity in this difficult environment.

(I have no problem with Starbucks or large corporations. This is not a rant against them. But I also value diversity very much.)

I wonder whether, no, I’d bet that similar approaches could work in other contexts. What type of business will be next?

Note: I understand that Cups can be understood as a shared platform and the independent coffee shops as pods in the sense that Dave Gray wrote about in The Connected Company. Cups and the independent coffee shops are participating in a shared enterprise as described by Tom Graves in Mapping the Enterprise (and his other books and his blog).

What the system is, does and knows?

In Lean Architecture for Agile Software Development, Getrud and Cope describe a system’s architecture in terms of what the system does (function) and what the system is (form).

(As a side note, their work includes the only substantial discussion of form (as distinguished from structure) of software systems I have come across so far.)

But what about the information managed by the system? Wouldn’t we also want to discuss what the system knows (in a casual sense of the word)?

Architecture descriptions (at least most of the ones I’ve seen) tend to discuss relevant data or information models in the context of a system’s structure (i.e. its major building blocks), but that never felt quite right to me. Or is discussing what the systems knows unnecessary because we could include data capture, storage and retrieval in the context of a system’s function?

I’d love to hear your views on this topic.

Update:

2014-04-06: Function & information: a useful duality? might be relevant in this context.

2014-03-16: Clarified that I used “what the system knows” in a casual sense. This may not have been a good idea — see the comments below.

2014-03-15: Correction: Form describes what the system is in this book, not structure. Also added “major building blocks” to somewhat clarify what I meant with “a system’s structure” in the last paragraph.

Use cases in lean architecture

James Coplien and Gertrud Bjørnvig have written a wonderful book explaining how lean architecture can play a meaningful role in agile software development. Here they describe the benefits of use cases “as a way to capture what the system does when it is important to understand a sequence of work towards a goal in a context” (Lean architecture for agile software development, ch. 8.2).

The notion of a sequence of work towards a goal in a context resonates strongly with me: it’s a brief and–to  me–powerful way of tying what needs to be done to context and purpose.

I have been working on e-commerce sites for the last few years. Much of the work has been driven by conversations about user journeys or user interaction flows (or whatever you’d like to call this).

I suspect that interaction flow descriptions/visualizations and use cases might well complement each other, but I haven’t yet seen them being effectively used together. I’d be grateful for your thoughts, experiences and suggestions.

Notes:

When I say “use cases” I refer to the Alistair Cockburn tradition.

James & Gertrud more often used the phrase “a sequence of tasks…” than “a sequence of work…”. The latter seems preferable to me as it seems applicable in a much wider context.

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.

Yet another architecture definition

A system’s architecture is the shared understanding of this system’s purpose, context, function, form, structure and characteristics.

A system’s architecture results from planning, designing, building and sustaining this system.

In hindsight, mental model probably would have been a better term than definition.

The above was inspired by the thinking behind http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf and http://en.wikipedia.org/wiki/Architecture.

 

Updates:

2014-04-26: Gene Hughson wrote about Architecture vs. Design at Iasa Global and Like it or not, you have an architecture (in fact, you may have several) at Form Follows Function.
2013-11-30: Added form, made function singular.
2013-11-09: Added characteristics to the definition. Stated mental model may be a better term than definition.