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.
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.