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?
Tridion-Influenced Business Analysis
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!
Tridion Target Types
The specific publication targets aren't visible during publishing. Users will see something like "Live" or "Preview" as the target type(s) to publish to.
I get nervous when I see target types other than the basic "Live" and "Preview." The specific terms don't matter so much--in other words, other words like "Production," "Staging," or "Acceptance" could be used. What jars me is when we occasionally have target types that aren't logical or based on an environment.