Monthly Archives: January 2016

Enterprise Design Framework: Frames

The third layer of the enterprise design framework as described in Intersection: How Enterprise Design Bridges the Gap Between Business, Technology and People by Milan Guenther deals with frames or viewpoints of conceptual models.

Higher layers of the enterprise design framework deal with anatomy and the big picture.

The four frames covered by the framework are business, people, function and structure.

This choice of frames seems highly useful to me, as do the descriptions of intent of and the selection of methods for the business and people frames. I’m less sure about the function and structure frames.

According to the paper version of the book, the function frame “captures the purpose the enterprise fulfills and the behaviours it exhibits towards its stakeholders. The functional viewpoint helps the understanding, prioritisation, and selection of a set of requirements the outcomes of a design initiative [are] expected to meet” (pg. 185). Requirements engineering is introduced as an appropriate design method for achieving these goals.

To me, requirements management tends to gloss over the fact that requirements are design decisions rather than natural laws or unfailing wisdom passed down from the powers that be–at least when practised as I usually experience it.

Sally Bean, an enterprise architect consultant, is quoted (pg. 215):

Requirements are often just laundry lists: someone makes them up, they are arbitrary, out of context and just plain wrong. –Sally Bean

That neatly sums up my experience, too.

Engineering seems to imply a degree of certainty or inevitability that the term design and the notion of a design decision avoid. In turn, this enables discussion of trade-offs between different decisions and design choices.

In addition to classic approaches to expressing requirements, tools such as value stream maps (or value network maps) and capability maps can be extremely useful (as well as many other methods and tools). I also recommend User Story Mapping by Jeff Patton.

The paper version of the book states that the structure frame “captures the objects and entities relevant to the enterprise, how they interrelate and form a structure. It enables an exploration of the problem domain in conceptual models and the transformation of those models in the course of a design process”.

In this context, domain-driven design as proposed by Eric Evans is put forward as an appropriate design method. Without intending to criticise domain-driven design in itself, this seems too software-centric and perhaps also too (software) implementation-focused in this context. The ideas put forward by Martin Fowler in Analysis Patterns and related writing would have come to my mind first. Skipping all the implementation-related stuff in Streamlined Object Modeling, the twelve collaboration patterns described by Nicola, Mayfield and Abney seem highly relevant, too. (You also might want to read this.) And in many cases, the simplest thing that could possibly work might be just a plain old concept map. Furthermore, service ecology maps and the Tom Grave’s enterprise canvas (especially the scope level) come to mind (more here).

This is not an all-out criticism of the enterprise design framework or the intersection book–on the contrary, I find both extremely useful. My perspective and my experience varies somewhat, and consequently so does my approach.



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.



Enterprise Design Framework: Big Picture

I enjoyed reading Intersection: How Enterprise Design Bridges the Gap Between Business, Technology and People by Milan Guenther when it was published. Since then I keep referring to the book for insight and recommend it to other people who design and deliver digital services. I also wrote an Amazon review to prove it.

Milan and the folks at eda.c managed to put a set of different design disciplines in a meaningful context with their enterprise design framework. In itself, this accomplishment deserves recognition.

As every other model the enterprise design framework makes conscious decisions to include some aspects of the modelled domain while excluding others. With a respectful and appreciative nod to Milan and friends I’d like to discuss some things I view differently.

The big picture is the first of the five layers of the enterprise design framework. Its three elements are identity[enterprise] architecture and experience. The intersection of these elements is labeled enterprise design.

While many equally useful definitions of architecture exist, I find this one particularly useful:

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. —Grady Booch

Consequently, I have difficulties seeing enterprise design as a subset of enterprise architecture. If I have to speak about enterprise architecture, I’d view the relationship the other way around. (The term architecture is abused so much that I hardly find value in using it anymore. I’m quite happy with design as used by Herbert Simon.)

The enterprise design framework’s briefing poster says: “Take a few steps back and look at your enterprise from some distance. What is it all about, why does it exist?” To me, this asks about the why people choose to participate in the enterprise, i.e. participants’ motivation. This then seems to be fairly well aligned with the time-honoured tradition of exploring stakeholders and their interests.

Identity (described to relate to branding work) seems to be only one aspect of that exploration rather than a distinct concern at the big-picture level. Other relevant aspects are purpose and values (hat-tip to Tom Graves).

Experience design provides valuable methods for conducting this exploration, although I think I’d discuss this at a lower level of the framework. I’m not yet sure where, but the anatomy level definitely will have to talk about experiences. (More on anatomy in a later post.)

So, this post is not about the enterprise design framework being wrong or about me being right. I just view and do some things differently…and learn as I go.


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.