As we wind up the year I thought I'd share an issue in the architecture and project management spaces that I saw crop up repeatedly in 2006: data and architecture models (and the people who made them) getting trashed by IT managers and business execs as a waste of time and resources.
In one case, a client manager was presenting a conceptual data model to his management and other interested parties in a project kickoff meeting. As the primary focus of a CDM is to directly map business requirements to data entities at a very-high level, the model did not contain materials that would normally appear later in the design/development, such as the physical data model or the DLL code necessary to actually install the physical model into a relational database.
This guy couldn't get to the third slide in his Powerpoint deck before getting smacked upside the head by the VP, with other managers piling on directly after. The managers could have cared less about a conceptual data model - when were they going to get their data warehouse so they can analyze their costs and financials? One exec, a former techie, went so far as to begin a macabre bout of row-column engineering on the thing, right there in the meeting. Our guy very quickly lost control of the room and the meeting degenerated rapidly from there.
In a few other instances over this past year, I've seen some architects take it on the chin for producing models that were largely 'academic' in nature and of little use to the projects they were developed for. These unfortunate scenarios cause a lot of problems with job performance, project costs, and the time spent developing models that could have been better spent using modeling to directly influence the success of the project.
Does this mean I'm against architecture and data modeling? Not at all. However, it has to be done intelligently, expeditiously, and with the project/organization outcomes in mind at all times. With that, I offer some rules-of-thumb on modeling that I hope folks find useful.
The later a modeling effort occurs in a project, the less value it has to the project. Sometimes architecture and data modeling are brought in 'late to the party' on a project for various reasons political and technical. A CDM or logical data model developed right before or during development has little value to anyone working within the development process because it's essentially too late to change development plans and issues without taking a schedule slip. The value of a CDM at that point is usually for documentation/artifact purposes only, and I would think twice about that if it will cost the project more in terms of schedule and money that it will save.
Academically rigorous models have value only to academics. I saw a couple of data modelers fall on their swords this past year defending ornate, complicated data models that only made sense to them, not to others. Worse, the models had little or no value to anyone else on the project and even worse than that, the modelers in question got defensive and spent much meeting time defending their work. That might be fine for Ph.D dissertation defenses, but in business, as one of these modelers found out, it can cost you a job. Unless a model has direct and positive impact on directly-connected downstream development processes, it might be prudent not to perform the exercise, or to produce only enough to enable such processes. Watching these two colleagues "fail" their projects with ornate, over-designed models that 'took too long' leads me to believe that there is a definite line between the academic exercise in modeling and the ones that enable business projects.
"Taking too long" is usually fatal. Modeling efforts are usually in some proportion to the size and complexity of the project. However, modelers must keep in mind that even if things are generally going well on the project, timely and useful information from models must always be provided. Most project managers will question why a modeling effort is scoped at weeks or months, and rightfully so, particularly if downstream development activities are delayed because of it. Models need to provide actionable information as quickly as possible, which places time constraints on their scope and complexity. Modelers would be wise to re-think their approach if there are scope and time objections, because this is a leading indicator that project managers and developers are not seeing enough value in the effort to continue the process.
If the model is for documentation/artifact purposes only, skip it or produce the minimum required. Unless the model is: a) necessary to comply with some regulatory or project requirement; or b) directly actionable and useful to development and test teams, the only value the work product has is as shelfware in the modeler's cubicle. Not a good situation for the modeler, the project, and the organization.
Whiteboards and digital/cell phone cameras are acceptable modeling tools, particularly if time is short. I've observed that an excellent way to get on the wrong side of management and development teams is to state that entering and validating the models into expensive design toolsets will take a lot of time. I have validated this approach on more than one occasion by taking photos of whiteboard exercises and pasting them into documents unedited. Nobody ever complained about the format but many did remark that they got the information they needed promptly. Beyond the whiteboard sessions themselves, the cut-and-paste jobs took about 10 minutes each. Entering them into a modeling tool to produce and validate 'pretty pictures' churned out on expensive plotters can take days. Do the minimum required to convey the information and stop worrying that your toolset skills are less valued - because in a lot of cases, your ability to quickly get vital architecture information out to those that use it is much more valued on projects than being a good tool jockey.
While I realize that a lot of this will go against the grain with some of my readers, I felt I had to share it because these issues repeatedly came up on projects I worked on or had detailed knowledge of in the past year, and I really don't see the tide turning back to documentation-and-process-burdened development. Organizational needs and 'attention span' are too short these days for that luxury.
Tim Johnson described a recent experience being on what he termed the Bi-Polar Express with an executive on a project who, for lack of a better term, vociferously questioned Tim's judgment and authority about certain project expenses.
One has to be careful when casting diagnoses with respect to bi-polar disorder in a business context, particularly in the story Tim relates. Instead, I would look at this executive more as an alpha male exhibiting specific negative traits that command-and-control alphas often do - to the detriment of their reports and obviously, the organization. Two very different animals from a treatment and therapy perspective.
A confirmed bi-polar diagnosis in anyone, regardless of station, is almost always much more severe than an exec getting erroneously pissed off at an expense or some other event that they had wished dismissed but came back to bite them in the posterior - or so they thought at the time. Alpha Male Syndrome is not bi-polar disorder - its how some guys (mostly guys) are wired and how they have achieved some modicum of career success but have stumbling blocks in appropriately dealing with people and situations.
In my life-to-date, I know of 3 people with confirmed diagnoses of bi-polar disorder. All of them are on heavy medication and could not function whatsoever at the level necessary to hold any sort of 'executive' position. The fact that all three hold any jobs at all, much less executive/managerial, is a testament to how insidious this condition is, and the need for proper diagnosis is key.
So, where I'm going with this...don't confuse bipolar conditions with those exhibited by alpha males, and you all can find some of those answers between the two here.
Finally, this post isn't to plug the book, although it was by far the best money I spent while holing up in the SeaTac airport a couple of weeks ago waiting for my canceled flight to Portland to take me home the next morning.
I'm pleased to annouce the second Carnival of Enterprise Architecture that I'm hosting through Blog Carnival. If you have an EA- or IT-related post that you'd like featured through the carnival, you can submit the Permalink URL here.
The deadline for submissions is January 13, 2007, and the carnival will
be published on January 15, 2007. I look forward to your contributions!
I recently completed a six-week assignment that left little room for anything other than travel and sleep. Now that it's over, I can go back to blogging a bit over the holidays...which I have taken off from blogging in the past but not this year...strange...:)
Good to be back...I have a few stories to tell...:)