Andre Genovesi On OUS

than done. As 90% of Conde Nast Tech are (very talented) JavaServer erpexts, and nearly everything at Conde Nast has to be done at the Enterprise level. Considering that most of Conde Nast tech would lose their jobs if they migrated to a CMS that didn’t run on JavaServer, it should be no surprise that Rails or LAMP alternatives aren’t exactly welcome at Conde Nast. Conde Nast Tech is too nervous about the security issues that come with the more agile server environments (they deal with decades of magazine content, worth billions of dollars it’s not just blogs), and let’s not overlook that they’ve already invested millions upon millions of dollars on a JavaServer hardware and infrastructure and hired dozens of engineers to run all the JavaServer hardware and maintain all of the databases. There are Information Architects who are expected to create shared working XML schemas to support all of the content needs of the 25 or so magazines each of which want different things from a CMS that was originally designed back in the 90s. Each new request for improved functionality from any of the Conde Nast magazines has implications that effect the shared libraries and schemas to run the entire CMS. Add in a subscription and registration layer to keep track of all of the subscribers and website users and it will make your head spin.There are preview servers, staging servers, development servers, an integrated legacy ticketing system (also awful), and a large Enterprise versioning systems to keep track of everything. Each and every magazine has their own set of server environments, and each developer has their own set of server environments that can run versions of all of these servers. It’s an extraordinarily complex system. The sheer complexity of the system makes it nearly impossible to innovate anything beyond what most popular blogging software can do out of the box. It’s part of the challenges of developing Enterprise-level technology. Nothing moves quickly.Add to the mix indecisive (and often clueless) editors from all the beauty and style magazines, and you can see why development crawls at a snails pace. 90% of the delays in the development process come from editors who spend weeks agonizing over the font choices and color schemes. Conde Nast can’t, and won’t, change their server environments because it would require rebuilding their entire tech team from the ground up. The people who run that side of the business will never allow that to happen. All of their jobs depend on things staying the way they are. They can’t change their CMS. They are stuck.Since they can’t change their CMS, every little bit of new functionality requested from any magazine needs to be coded from scratch. While other blogs and websites simply upload an open-source plugin and activate it with a click of the mouse, at Conde Nast they have dozens of meetings, development scope estimates, IA wireframe mockups, lots of designers and editors meetings, etc. Servers need to be configured and environments need to be set up and tested. It can take months to create dynamic element that takes seconds on any other CMS.I can’t say I envy the position that Conde Nast is in. It’s easy to say that Conde Nast Tech has their heads in their asses. But managing the websites of 25 magazines using their massive Enterprise framework to manage decades and decades of content worth billions of dollars is no easy task. You can be sure that Conde Nast Tech is open to solutions if anyone has them. In the meantime, they’ll be waiting for the next version of TeamSite to come out so everybody can keep developing the way they have been for the past decade. The only question is, how many more years can they keep that up? It will be interesting to watch.