Few posts back I embedded the Grandaddy video made by Stewart Smith. The video he directed for Tomas Halberstad is now released and Mr Smith continues to be a genius of simplicity.... and Tomas makes great music.
tisdag 5 oktober 2010
Triad of complexity
I really like Gunillas discussion around complexity, it is really simple but somehow it just gives me a new perspective.
Next time you are discussing a complex issue, think about what's complex about it...
Is is functional, dynamic or computational complexity?
Often you simplify by just stating it is complex ending up trying to solve a e.g. functionally complex issue by using a "dynamic approach"... or actually the most common case is that you have a complex dynamic problem that gets even worse when you apply a tool designed for functional issues.
Next time you are discussing a complex issue, think about what's complex about it...
Is is functional, dynamic or computational complexity?
Often you simplify by just stating it is complex ending up trying to solve a e.g. functionally complex issue by using a "dynamic approach"... or actually the most common case is that you have a complex dynamic problem that gets even worse when you apply a tool designed for functional issues.
The vampire's gaze
Why is it that models seems to entice us engineers to use a means for simplification and just make things more complicated? Too often we forget the most important part of modelling - the Why! Instead we get caught up in discussions such as:
- Tools
- Model structure
- More tools!
- Process and roles
... and in the end we seem to crank as much information we can into one big model and hope for the "one size fits all" wonder.
But really we should just repeat why why why and try to use models to fit that purpose.
Say you work with the electrical system of a car, how would you apply modelling to:
- Vizualise dependencies between components?
- Analyze power consumption?
- Structure the software of your engine controller?
Would you use the same model? Would you use the same modelling language and technique? Would you consider a table/matrix to be a model? It all depends on the why.
Being interested in software/system architecture I seem to be forgetting the why a lot myself, or at least in the past. The most common pitfall I've seen in different industries is architects becoming "trigger happy" in models and get caught up in details that really shouldn't be their concern.
Don't get me wrong and think that I blame the models, I do believe MBSE is necessary in order to keep a competitive edge but we need to be a bit less amazed with the beautiful "pictures" we draw and a bit more focused on... Why.
- Tools
- Model structure
- More tools!
- Process and roles
... and in the end we seem to crank as much information we can into one big model and hope for the "one size fits all" wonder.
But really we should just repeat why why why and try to use models to fit that purpose.
Say you work with the electrical system of a car, how would you apply modelling to:
- Vizualise dependencies between components?
- Analyze power consumption?
- Structure the software of your engine controller?
Would you use the same model? Would you use the same modelling language and technique? Would you consider a table/matrix to be a model? It all depends on the why.
Being interested in software/system architecture I seem to be forgetting the why a lot myself, or at least in the past. The most common pitfall I've seen in different industries is architects becoming "trigger happy" in models and get caught up in details that really shouldn't be their concern.
Don't get me wrong and think that I blame the models, I do believe MBSE is necessary in order to keep a competitive edge but we need to be a bit less amazed with the beautiful "pictures" we draw and a bit more focused on... Why.
Prenumerera på:
Inlägg (Atom)