Here is a quick wrap up of day 0 (September 24th) rather than a long article.
Track 1 – Data modeling to represent business information needs – Keith Gordon
Keith talked about the importance of using models that does not take 6 months to draw and are difficult to understand by ordinary people. Despite the session was mostly about Entity Relationship diagrams (that in my humble opinion are less scary than UML class diagrams, can be scary to most business people) looks like it’s time to find other ways to describe organizations, domains, processes, because companies cannot wait so much time from change program kick off to implementation. Today on a Linkedin’s forum someone was commenting that is time to automate with native intelligence the way humans model concepts. Hence for those that want to take challenges its time to free our mind for thinking rather than drawing.
Lot’s of emphasis on the classic problem: business does not understand IT and vice versa, but this makes me think that:
Like any other knowledge domains, there are lots of methods, but all are wrong if they cannot align different tacit knowledge domains.
Also on teams, regarding the solo Analyst:
The single person modeler makes me remember the problem in human reality perception.
And on Analyst’s cognitive illusion, this example from Keith says it all:
What are the valid domain names for the gender? Make, Female? What abut In transition from male to female?
This one came from a chat during a break and is headed to BPM professionals:
The idea is BPM is complex and no one understands because professionals make it hard.
Track 2 – System thinking Emma Langman
Emma, take off with the importance of system thinking is about being fun and empathy. Rather than prescribing methods it dived around some useful approaches to understand concepts, like for example CATWOE defined by Peter Checkland as a part of his Soft Systems Methodology, or POSIWID from Stafford Beer on complex system analysis. I remember sometimes using CATWOE for stakeholders expectation assessment that is useful to reach to outcomes when implementing change. If you know from the start that a particular outcome is not going to see the light of the day, it’s time to start thinking how to tackle it, before strong opposition from a stakeholder group tackles you.
Another good point was:
If you want change happen, use simple language and metaphors.
The one above makes me remember the days I was in manufacturing and I need to listen to sport programs (that I hated) to proper communicate and joke with assembly line works to make things going.
There was one intriguing example about how the ideas and assumptions are formed. I was about two companies that produced pens. One factory produced blue pens and other red pens. The red pen factory had quality problems with the lid, the blue pen factory was one of a kind of a factory. Then the exercise was regarding creating ideas about the infrastructure and people’s culture for each company. Attendees painted a picture of the red pen factory as something filthy and dirty with screaming and desperate people. On the other hand, the blue factory was the perfect place to work.
I tend to admit that this exercise was more about prejudice and bias from the typical business analyst, because it’ possible (based on my experience) that most of the times you can have a shop floor you can kiss and that kind of company excels, but the contrary can also holds true (you can still kiss he floor but its not capable of doing things properly).