The client where I work has a set of analysts, a majority subset of whom are used to looking at a software application as “database-driven,” meaning they need to see the database table schema in order to understand the flow of the application. They’re technical enough that they can use the “language” of a database’s table diagram, its glyphs, to understand the business logic that it represents. They’re familiar with a database’s Entity-Relationship Diagram (Database ERD). They consider themselves masters of creating a database ERD and using that to communicate to a DBA what sort of database to create and to give that to a .NET developer to tell what to build around.
With Microsoft Dynamics CRM, as with other Enterprise-class software applications and many ORM-driven applications, the underlying database schema isn’t the “language” the business is written in – that underlying table schema is the representation of the CRM framework’s data store. The CRM Database ERD doesn’t contain only the business’s logic but also CRM’s. If CRM’s power is enabling business processes, then when these types of analysts look at a reverse-engineered database ERD of CRM’s organization database for insight, they come away bewildered, not understanding how such a different schema could even manage to encapsulate their business, or worse, irritated that it’s so difficult to read the database table ERD and can’t see how CRM would make application development any faster than if they just created a custom ASP.NET application.
One of the major issues they have is with a classic CRM Design Pattern – the Denormalized Attribute Pattern. This pattern provides one way of solving the need to display information on an entity from one or many related entities – copying them to the main entity in question. From a database ERD standpoint, it appears that there’s duplication of information, a major red flag from a database design perspective. Even when not using this design pattern, looking directly at a CRM database with its two tables per entity on custom entities and its attributes for related “foreign keys” for N:1 and N:N relationships tend to confuse analysts who aren’t familiar with the CRM framework.
What’s the solution to satisfy an analyst who feels like they’ve lost their primary means of communicating business data storage and logic via a db ERD? A better “language” or glyph system would be UML, a notational representation of an object model, or a more abstract (actual) Entity-Relationship Diagram.
In some following posts, I’ll describe communicating business and technical analysis via UML and a custom CRM ERD language and how it relates a traditional database ERD, particularly one reverse-engineered from a CRM organization.
Claudio Ciborra's
The Labyrinths of Information relates these problems with constant continuous process improvement in the IT field:
- Excessive
idealism - encouraging disillusion, frustration, and cynicism
- Speed
and oblivion - "new" endlessly supplants the "incompletely implemented"
- Carbon copy projects - followed "disgruntingly" as bureaucratic
procedure
- Narcissism - "strong actors" become the main driving force,
creating a double bind: is this systemic rigor or forceful
leadership?
- Technical bias - creativity is evicted by the "concern for
the careful management of the means"
- Totalitarian bias - drastic
simplification of reality
- Ideological drift - preaching
encapsulates science
Claudio Ciborra claims that his research concludes that
"Painful and slow alignment of people, methods, and systems
is the stuff of which actual implementation processes are made."
One of the biggest gaps in knowledge and education out there with regards to agile methodologies, a process improvement framework, is the area of introducing agile methodologies successfully to an organization which is either mired in self-hate or has a culture of resistance to change. People claim successes with small teams, and that's not to be denied, but that's clearly the "happy path" where (smaller) companies realize they have to align with the improvement process and try something new or cease to exist or a pilot team of 5 or less can "show successes" and then evangelize to the larger organization. (I'd argue that if the larger organization is resistant, no matter how successful the smaller canary team is, they'll be ignored.)
Further, constantly looking for process improvements and grasping for leadership seem to have similar appearances of desperation.
In my experience with attempting to improve the processes at my work, I find these symptoms to be prevalent as well as the conclusion to be true: it's painful and slow and aligning people and methods is not easy.
Shut up. Be professional.
That's what I've learned from
So You Think You Can Dance. I'm not a dancer, but the meltdowns of the dancers with potentials have lent some insight into my daily life. I'm a software architect and manager (albeit without authority, but that's for another post) and have opinions about a whole lot of things. I'm pretty confident about what I know and about what I don't know and where I can improve. And I have opinions about other people, processes, and systems as well. All that's well and good, but in the thick of it, I have definite opinions on what needs to be done and will express that. Sometimes, though, it's best to keep quiet and let other people have their say and let ideas have some space to air. Humility and silence can be your friends.
Here's Lizz Plott's audition:
http://www.youtube.com/watch?v=JOZNsaXnLc8&feature=relatedOnce someone puts up her mouthing off and subsequent denial in the top 20, I'll put that up here.
This is a sordid tale of my first bad technical experience with Dell.
I bought a refurbed XPS 420 Quad core for a VM server. It arrived on Thursday, heavy, packed with stuff I didn't expect (earphones, chamois, lcd status-y deal, media card reader); then again, it's an XPS, as Jack pointed out (who got one, too). We were Dell buddies, except I got shat upon. Here's how it went:
Jack opens his, plays around with it, has some trepidations about Vista x32. With the box able to handle 8gb of RAM and the general instability that I've had with Vista x32, he wanted x64.
I wait a day to open mine because So You Think You Can Dance becomes more important and pay the price. It only reboots itself on first turn on. I speak with Elizabeth (tech support, incident 19636455) who asks for my phone number then tells me to reseat the memory and then promptly gets cut off. The XPS's indicators are nice - apart from the LCD (which seems to be useless at this stage) there are 4 blue leds placed vertically next to the LCD and they light up as the boot process occurs, doing a diagnostic check. When I mentioned to Elizabeth that 1, 2, and 4 came on she knew it was a memory issue. That seems handy.
That gets the machine to boot, but then it shuts down during Vista install. She gets disconnected.
I speak with Davidson (tech support, incident 19636455) who asks for my phone number tells me to remove the memory and reseat it. It boots, but only into Windows Error Recovery. Trying to restore to factory Dell settings bombs and the computer doesn't even power on after a reboot. I mention this. Then he gets disconnected.
I speak with Amith (tech support, incident 19637936) who tells me to take out all the memory and the power cord hold the power button down for 10 seconds then restart. That apparently resets the motherboard or discharges any held charges on it, who knows. Promptly after asking how it's going, he gets disconnected.
I speak with Kiran (tech support, incident 19638312) who tells me that the diagnostics LEDs (1 2 3 ) indicate Hard cables not properly connected to System board. He thinks the motherboard is fine and wants to disconnect the drives, the cpu, and various other items to determine what's bad about it. By this time I'm really hating the whole process since my whole objective for buying a Dell was that I'd receive a machine that was well put together and quiet - having to reseat things, although trivial, is beyond my tolerances. No.
I'm on hold with customer support to return the thing. Luckily, Dell allows a return within 21 days of invoice.