Tag Archives: design

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

“Designing Delivery: Rethinking IT in the Digital Service Economy” by Jeff Sussna

When I recommended Designing Delivery: Rethinking IT in the Digital Service Economy on Twitter, Jeff asked me to explain why I thought it was valuable. Jeff’s book deals with a complex subject matter and he considers a broad range of different aspects. While this makes this book valuable, it makes writing a meaningful review difficult. For what it’s worth, here we go:

Confirmation bias — well, an ego boost

From a very superficial perspective, Designing Delivery makes me feel good as it confirms a few things I’ve been having hunches about for a while. This includes a broader and more proactive role for testing & quality assurance in lean & agile initiatives and organizations, a focus on product management rather than project management, an extension of devops ideas to business operations, an emphasis on designing & managing services (or service-dominant logic) and, more recently, seeking to combine agile development and design thinking.

Unfortunately, my thinking hasn’t been as thorough, consistent and coherent as Jeff’s. I haven’t foreseen all of this years ago — on the contrary, compared to this book, my thinking barely scratched the surface…if you look really hard, you can even see some marks.

Cybernetics

Cybernetics form the backbone of Jeff’s work in this book. I finally got the memo on cybernetics earlier this year and worked through Donella Meadows’ Thinking in Systems: A Primer. Yes, I know I’m late to the party…

Jeff introduces fundamental cybernetic concepts and applies them to software and, more generally, digital services in a very practical and approachable way. These cybernetic concepts helped me to talk and reason about behaviours I’ve seen at work and elsewhere in life. This, in turn, provides a basis for effecting change in these systems.

No software is an island

While software undoubtedly is essential to most businesses today, discussing software in isolation is insufficient: software needs to be considered in the context of the services it helps to deliver. Jeff provides a good introduction to service-dominant logic and how it applies to the digital service economy. In addition to customer-related concerns, Jeff discusses other people in the enterprise (especially employees and service providers) as well as organisational concerns. It is unsurprising that Dave Gray’s The Connected Company has a guest apperance.

It all comes together

Jeff brings together several schools of thoughts or practices that are hugely important today. In particular, Jeff shows that cybernetics (or systems thinking) and design thinking cannot only coexist peacefully but can actually be combined to yield even greater value. Furthermore, he shows how design thinking has an essential role to play in the fuzzy front-end of lean & agile software development processes. Jeff brings devops into the mix and shows how it can be relevant beyond software (i.e. service operations, business operations). He calls for operations to become an input to the design process and thereby completes the loop of designing, developing, delivering and operating software-supported services.

A crucial point in this book is Jeff’s call for a broader and more pro-active role of quality assurance in this context. He calls for a quality advocacy role that needs to go far beyond software development: indeed, quality advocacy needs to help the entire organization to deliver the right services to the right people — both inside and outside the company.

Many IT organizations are facing formidable challenges today. In Designing Delivery Jeff Sussna envisages a future for them in the digital service economy and shares his thoughts on how they can develop toward this new role.

That’s it for now

This blog post is only a start and is necessarily biased. It certainly doesn’t do Jeff’s book justice. As my thinking becomes clearer, I might update it in the future.

 

 

Perspectives in (service|enterprise) design

All sorts of perspectives on service design and/or enterprise design keep spinning in my head and, I think, in many posts on the topic. Why not add one more?

This post is work-in-progress and an attempt to clean up my thinking.

Fundamental perspectives

As Tim Brown states in Change by Design and IDEO explain on their website, successful design has to satisfy the three constraints of:

  • desirability (human perspective: Do people want it? Does it make sense? Is it meaningful?)
  • feasibility (technology perspective: Can we do it?)
  • viability (commercial/ecological perspective: Can we sustain it?)

The faculty of Industrial Design Engineering at Delft University of Technology recognizes these perspectives as peopletechnology and business.

Consequently, desirability, feasibility and viability are three perspectives that we will want to consider in most of our design activities. (We’ll have to ensure that we do not consider these to be constraints too early in the process so that we do not prematurely limit our thinking.)

Levels of abstraction

Drawing upon work by Tom Graves we can identify several levels of abstraction when taking a service-oriented view of the enterprise:

  • purpose (Why are we here?)
  • context (Who is “we”? What else is around?)
  • concept (Who does what for whom? When? And, especially, why? The conceptual (or functional) level.)
  • implementation (How is this going to work? The implementation-specific level.)
  • deployment (When will this happen? Who is and which resources are involved? The operations-specific level.)

I’ve been rambling about this before. This time I’ve omitted the action-record level, i.e. the level providing an historic record of activity within the enterprise. This brings us to:

Time

I think time is best considered to be a distinct dimension rather than an aspect of other dimension. It can be useful to consider the past, present and future when discussing desirability, feasibility and viability. Similarly, different time perspectives can play meaningful roles when discussing the different levels of abstraction introduced above. In particular, the action-record level is just a past slice of the deployment level. An action plan constitutes a future slice of the same level.

In the context of service design, we’ll often want to consider five different time periods: before, at the begin of, during, at the end of, and after the service encounter. This could be easily extended by considering distinct phases of becoming and ceasing to be a specific service provider’s customer (for services involving continuous or repeat services).

Over time, the enterprise changes its shape: participants leave and others join, resources disappear and others become available.

Jeff Sussna pointed out that these comments reflect a purely linear view of time that is typical of many service design efforts. I think that this is also true for many other types of design efforts including user experience and business process design. However, in many cases, the people involved have at least a latent understanding of the fact that life is not as linear as e.g. a customer journey map might suggest.

As designers we need to be more explicit about the fact that linear time-based maps are a gross simplification. We need to point out aspects such as concurrent or parallel processes (which may have varying degrees of interdependence) and other non-linear aspects of time.

More of Jeff’s tweets on the topic here, here and here.

What next?

The above is only a start, but the mess in my head feels a little more manageable already. Other dimensions can (and should) be added, the different concepts could (and should) be discussed in more detail. For example, entire books can be (and have been) written on desirability alone.

Update

2016-02-20: Added reference to Delft University of Technology to Fundamental perspectives.
2016-02-15: Updated section on Time based on comments by Jeff Sussna.

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.

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.

Different to a human, but not to a computer

We were discussing different ways of modelling information about two different concepts. One of my colleagues observed:

Concepts X and Y look very different to a human, but they don’t look all that different to a computer.

He suggested (looking further into) representing these two concepts using the same entity in the system.

A number of things struck me as noteworthy: I think it might be beneficial to more frequently distinguish conceptual models and implementation models (or conceptual and implementation concerns) in design discussions. I’m glad this happened here. Relevant concerns in a conceptual model don’t necessarily have the same relevance in an implementation model and vice versa.

We frequently still seem to draw on sub-classing as the mechanism of choice for distinguishing different types / categories / kinds of things in our models. Other mechanisms such as type attributes or type objects may yield much better results in many situations.

My colleague’s description of this thinking (looking different to a human but not that much to a computer) seems so much better than my ramblings about conceptual and implementation models.

Martin Fowler’s Analysis Patterns book contains a wealth of ideas on this and related topics — it’s highly valuable and relevant 15+ years after its first publishing. Get a first look here and here. Look for discussions of the knowledge level vs. the operational level in models.

Separate concerns…but not too much!

Separation of concerns is a fundamental design principle whose application can provide significant benefits (also in fields far beyond software). But these benefits become smaller the more we apply this principle and at some point we may actually cause damage.

An example: Categorising things can help us to achieve a better and/or quicker understanding of the situation at hand. Initially, introducing additional categories improves understanding. As we add more categories, the improvements of our standing become smaller while the difficulties of deciding which category the thing at hand belongs to increase.

With separation of concerns (as with many other things) too much of a good thing can actually be pretty bad.