Multiple Modeling Methods

I'm down to three classes in my BSIT. Tonight we reviewed ways to model an information system through interviews. According to authors Blaha and Rumbaugh in Object-Oriented Modeling and Design with UML, you can create a model using one of three approaches:

• back room 
• round robin
• live

A back-room method of modeling is simply interviewing the domain stakeholders and coming back with a model. It's fairly straightforward and is easier to do. The interviewees (typically end-users) don't get to see the diagrams. Grab the info and run (away) with it!

For more of a challenge and slightly faster method, consider a round-robin approach where the analyst creates the models with the interviewees and then revisits the model over several iterations.

Not for the faint-of-heart, the live modeling method is to create the system diagrams in a live everyone's-invited session. Meeting and diagramming skills are crucial for such live sessions.

Depending on the system and the audience, I've seen a mix of all three types even on the same project between myself, programmers I've worked with, and other analysts. It's nice to finally have a name to the different ways of conducting model-design interviews and sessions.

It's akin to that "aha moment" when someone describes various software (system) development life cycles (SDLC) that you've already been using.

Tridion-Influenced Business Analysis

I'm wrapping up my bachelor's of science in information technology (I find the abbreviation "BS IT" amusing and odd at the same time). One of the last few classes is covering ERP implementations and as much as I try to think in broad terms of software that touches the enterprise, I keep coming back to my experience with Tridion for comparison.

I'm sure there's just cause to ridicule my narrow view, but I feel I've seen a good deal of the "typical" concerns and issues in the smaller subset of "enterprise" WCMS (Web content management systems), specifically SDL Tridion R5.3 in a corporate environment!

We had requirements, a procurement process that included expert advice and an RFI (we skipped the RFP), demos, and paperwork. We had to design the architecture, get training, and develop a phased/parallel implementation plan. Servers, troubleshooting, and testing... we seemed to have most, if not all the pieces of a sort of "mini" enterprise system.

I've learned, however, not to brandish the term "enterprise" so easily. Sellers may like to refer to their enterprise software--it may be enterprise-class or used by much of the company, but there's a distinction between such software and an ERP.

Thoughts? Does learning, working with, or implementing a WCMS like Tridion prepare analysts to better understand larger systems? Do the skills translate to something like a SharePoint implementation or SAP?

San Diego Code Camp 2011 is June 25-26 at UCSD

I highly recommend the San Diego SoCal Code Camp, a free, developer-focused conference.

Read more about it and consider attending, helping, or even presenting. Free-to-attend!

Analyze This!

I was considering changes for a website for a side project and almost missed a crucial part: business analysis.

My entrepreneurial experience goes way back. Though most side projects have been in some sort of job + hobby capacity (a "jobbie" according to Carol Roth's book), a recurring lesson for "gigs," corporate life, and  school projects or independent research (I read leadership, technical, and technical leadership books for fun) is to clarify expectations up front. This early analysis helps avoid huge issues later on.

Project managers use a project charter and scope statement. Clients or internal business units have business requirements,  business analysts (BAs) write functional requirements, and systems analysts (and BAs) or system architects may create system requirements or technical specifications. Scrum masters and other agile practitioners (is that a small "a" or big "A?") rely on user stories. Recipes, blueprints, directions, user guides, and instructions all fall into the bucket of analysis and/or up front communication. Pause. Evaluate. Understand. Then execute.

Now with all this being said, why is it did I practically skip all this and attempt to start hacking away at some chunks of HTML? Code monkeys, techies, or uber geeks love to either play with the code or want to solve things as fast as possible (read about "Rand's incrementalists"). Perhaps the dark side of the power to manipulate  markup, code, or systems will continue to tempt knowledge workers, programmers, and other implementers.

I'll stay in the light and do some proper analysis and documentation up front. The balance between analysis and coding could make a whole other post or even book!