Aggregated enterprise architecture wisdom
We previously discussed Options Analysis – our method for evaluating multiple viable technical solutions. We also facilitate numerous smaller design choices at all levels of the architecture. We often need to document these as “design decisions,” and use a common approach and format to document at all levels of design (conceptual, logical, physical, component, etc.). […]
While we often find ourselves advocating for design documentation, we typically are referring to “some” design documentation vs. “more” design documentation. When it comes to design documentation, more is actually not better. We have encountered customers, and even other consulting firms, that deliver design documentation by the inch – measuring design quality horizontally across the […]
Although I have been practicing enterprise architecture for more than 10 years, I still find it challenging for me to explain to others what exactly I do. I am a systems designer and engineer at heart, but not necessarily in the way in whic…
Although I have been practicing enterprise architecture for more than 10 years, I still find it challenging for me to explain to others what exactly I do. I am a systems designer and engineer at heart, but not necessarily in the way in which a typical IT function defines “systems.” I feel what I do…
I thought I might buy Sketch – a vector drawing application for OS X written by Bohemian Coding. They put a lot of emphasis on ease of use and so do I. This is how they sell it… Sketch is a professional vector graphics app with a beautiful interface and powerful tools. We set out […]
This post is number nine in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with. […]
This post is number eight in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with. […]
There are two misleading ideas (espoused theories) about how architects and designers make decisions.According to classical decision theory (Herbert Simon), one or more designers develops a series of alternative options, working collaboratively or in c…
In my post From Sedimented Principles to Enabling Prejudices(March 2013) I distinguished the category of design heuristics from other kinds of principle. Following Peter Rowe, I call these Enabling Prejudices.
Rowe also uses the concept of Sedimented Principles, which he attributes to the French philosopher Maurice Merleau-Ponty, one of the key figures of phenomenology. As far as I can make out, Merleau-Ponty never used the exact term “sedimented principles”, but he does talk a great deal about “sedimentation”.
In phenomenology, the word “sedimentation” generally refers to cultural habitations that settle out of awareness into prereflective practices. Something like the “unconscious”. (Professor James Morley, personal communication)
“On the basis of past experience, I have learned that doorknobs are to be turned. This ‘knowledge’ has sedimentated into my habitual body. While learning to play the piano, or to dance, I am intensely focused on what I am doing, and subsequently, this ability to play or to dance sedimentates into an habitual disposition.” (Stanford Encyclopedia of Philosophy: Merleau-Ponty)
This relates to some notions of tacit knowledge, which is attributed to Michael Polyani. There are two models that are used in the knowledge management world that talk about tacit/explicit knowledge, and present two slightly different notions of internalization.
Some critics (notably Wilson) regard the SECI model as flawed, because Nonaka has confused Polyani’s notion of tacit knowledge with the much weaker concept of implicit knowledge. There are some deep notions of “unconscious” here, which may produce conceptual traps for the unwary.
Conceptual quibbles aside, there are several important points here. Firstly, enabling prejudices may start as consciously learned patterns, but can gradually become internalized, and perhaps not just implicit and habitual but tacit and unconscious. (The key difference here is how easily the practitioner can explain and articulate the reasoning behind some design decision.)
Secondly, to extent that these learned patterns are regarded as “best practices”, it may be necessary to bring them back into full consciousness (whatever that means) so they can be replaced by “next practices”.
Bryan Lawson, How Designers Think (1980, 4th edition 2005)
Peter Rowe, Design Thinking (MIT Press 1987)
Wilson, T.D. (2002) “The nonsense of ‘knowledge management‘” Information Research, 8(1), paper no. 144
Thanks to my friend Professor James Morley for help with Merleau-Ponty and sedimentation.
In my post From Sedimented Principles to Enabling Prejudices(March 2013) I distinguished the category of design heuristics from other kinds of principle. Following Peter Rowe, I call these Enabling Prejudices.
Rowe also uses the concept of Sedimented Principles, which he attributes to the French philosopher Maurice Merleau-Ponty, one of the key figures of phenomenology. As far as I can make out, Merleau-Ponty never used the exact term “sedimented principles”, but he does talk a great deal about “sedimentation”.
In phenomenology, the word “sedimentation” generally refers to cultural habitations that settle out of awareness into prereflective practices. Something like the “unconscious”. (Professor James Morley, personal communication)
“On the basis of past experience, I have learned that doorknobs are to be turned. This ‘knowledge’ has sedimentated into my habitual body. While learning to play the piano, or to dance, I am intensely focused on what I am doing, and subsequently, this ability to play or to dance sedimentates into an habitual disposition.” (Stanford Encyclopedia of Philosophy: Merleau-Ponty)
This relates to some notions of tacit knowledge, which is attributed to Michael Polyani. There are two models that are used in the knowledge management world that talk about tacit/explicit knowledge, and present two slightly different notions of internalization.
Some critics (notably Wilson) regard the SECI model as flawed, because Nonaka has confused Polyani’s notion of tacit knowledge with the much weaker concept of implicit knowledge. There are some deep notions of “unconscious” here, which may produce conceptual traps for the unwary.
Conceptual quibbles aside, there are several important points here. Firstly, enabling prejudices may start as consciously learned patterns, but can gradually become internalized, and perhaps not just implicit and habitual but tacit and unconscious. (The key difference here is how easily the practitioner can explain and articulate the reasoning behind some design decision.)
Secondly, to extent that these learned patterns are regarded as “best practices”, it may be necessary to bring them back into full consciousness (whatever that means) so they can be replaced by “next practices”.
Bryan Lawson, How Designers Think (1980, 4th edition 2005)
Peter Rowe, Design Thinking (MIT Press 1987)
Wilson, T.D. (2002) “The nonsense of ‘knowledge management‘” Information Research, 8(1), paper no. 144
Thanks to my friend Professor James Morley for help with Merleau-Ponty and sedimentation.
Somehow it is a recurring theme in computer science: create a “programming” system that is easier to use and learn than the existing programming approaches. I am not just talking about better tools, like IDEs, but also new languages. It seems as if each self-respecting programmer creates his/her own language or tool-set nowadays, right? Okay, I have to admit that not all efforts are focused on making things easier, often.
The post Designing the next programming language? Understand how people learn! appeared first on The Enterprise Architect.
As practicing solution and enterprise architects we regularly present our work to our stakeholders for feedback. Those stakeholders range from mentors to peers to project teams to executive sponsors. In any and all of those situations, it is important to be able to accept feedback. In some cases the feedback will have been solicited by […]