This installment of the Champions of Web Publishing series features Seth Miller, president and CEO of Boston-based Web engineering and consulting firm Miller Systems.

Miller is a true Web pioneer. He started Miller Systems in 1995 as an IT consultancy but soon began providing leading-edge Web design and development services as the Internet and browser revolution took off. In fact, a site his company built for MacWorld Expo was the first to include an SSL-compliant credit card processing event registration system, something that was truly bleeding edge in 1996.

Today, Miller Systems provides a unique blend of engineering, IT consulting and creative services that support strategic business objectives and focus squarely on delivering ROI. Miller took some time recently to speak with Publish about the evolving role of the CMS in today’s Web environments and what he sees as the future of Web publishing.

Publish: Can you give us an idea of your background? Did you grow up in Boston? How did you find yourself gravitating toward IT and technology?

Seth Miller: I actually grew up on Long Island but found myself sticking around Boston after attending Boston University. Although I was an English major with a minor in journalism, I've always been very technology-oriented; I put myself through school working in computer labs, mostly supporting the use of then-emerging desktop publishing applications like QuarkXpress, Aldus PageMaker and early versions of Adobe applications like PhotoShop. It was a great time to get involved with computing in a publishing context. I learned an awful lot about the process of publishing, since in 1992, as I like to put it, "the ink definitely dried". If you made a mistake, you paid for it, sometimes dearly. People sometimes lost their jobs over a publishing mistake. It gave me a respect for process. I learned that even more at my first post-college job -- I was a support engineer at Graphics Express, which at the time was New England's most well-known digital pre-press service bureau. It was an amazing learning experience.

While working at Graphics Express, I took a serious interest in the network and infrastructure side of the publishing business. I left and took a position at a local PR firm as a system administrator and managed two small networks -- one in Boston and the other in San Jose. Connecting those two offices would be a breeze today, but doing it in 1994 was a challenge from architecture and cost perspectives. I actually registered my first domain name in 1994, tying together a whole bunch of disparate e-mail systems for the PR firm. This had a dramatic impact on the business and gave us a competitive advantage at the time. It's funny how things become old hat in a few short years.

Publish: How did you build your expertise in Web publishing? What was it like to make the transition from IT consultancy to Web design and development?

SM: When I started Miller Systems in 1995, I kind of found myself with two skill sets that were emerging: publishing and networking. If you slap those two together with a good sense of how to abstract the two and then tie them back together, you pretty much wind up with the Web. Making the transition was as simple as asking my biggest client, an event management firm, to let us build their first Web site. As it turned out, that site was for MacWorld Expo. It was a big success, and we built 10 more MacWorld sites for IDG before we were done, along with sites for ComNet, E3 and Internet Commerce Expo.

Because we were IT infrastructure savvy, we were able to make good, cost-effective decisions about how to host the sites. We quickly started getting software and database development experience with a few key relationships and hires, and that put us in an excellent position to build e-commerce applications. We actually built the Web's first SSL-compliant, automated credit card processing event registration system on the Internet in 1996. Comdex, N+I and even the Netscape Developer's conference had "print and fax" registration; ours was browser-based and automated. It was a huge coup.

Publish: What do you think have been the biggest changes in Web publishing over the years? Does one technology stand out in your mind?

SM: So much has evolved. I think that the evolution of affordable, enterprise class content management systems from companies like RedDot are very significant. The irony of the big expensive systems is that the functionality that they enable is far more useful for smaller companies than bigger companies. Bringing these tools and features to the small and midsize business has a much more dramatic impact and allows a smaller player to be far more nimble both in presentation and execution.

Publish: Of Miller's most recent projects, which ones stand out in your mind -- which make you the most proud? Why?

A couple of recent things are great examples: The Priority Healthcare Neighborhoods (see link here and here) are excellent projects for lots of reasons. First and foremost, they help people dealing with very difficult diseases and conditions. Second, the tools that power those sites (RedDot, dataDriver ePush, custom .NET software) enable content administrators to keep fresh treatment research and information flowing to the patients and doctors using tech-free user experiences. Patients can collaborate and support one another. And from a business perspective, Priority was able to deliver these properties in such a way that they are very scalable, cost-wise; the cost of putting up a new "neighborhood" is a small fraction of the cost of the initial project. Membership is way up on both of these Web sites since the re-designs and the introduction of new content management tools.

On a smaller scale, the site redesign/overhaul we performed for Custom Fitness has been an enormous success for the small firm. The quality of leads and new clients that they are getting in just the last 8 weeks is astounding. The firm is getting their best-ever rates and getting much more qualified customers coming in to the site. The site positions them properly -- 4 new clients signed up in just the first week! We really made a big difference for Custom Fitness, and even though it's small in scale compared to some of our other clients, the impact we've had on their business makes me very proud.

Publish: Have your clients' business motivations changed over the years? What do they look to the Web to do for them business-wise?

SM: Since the dot-bomb, clients are (thankfully) a lot more focused on ROI. I prefer it that way; many frivolous projects don't even make it to RFP now. Unless there's a clear path to return on investment, it's not likely to get funded.

In terms of operations, a ton of self-service applications are really driving development. Allowing B2B customers to order online -- enabling traditional businesses with e-commerce connected to legacy systems has been big business for us, as has building self-service portals for customers to manage their own accounts. Self-service customer service is a real win for many companies. It's sort of the natural extension of the "FAQ". It's like transforming "Frequently Assisted Tasks" (FAT, how appropriate an analogy) to "Self-Service Tasks". I think the implementation of the RIA (Rich Interface Applications) in technologies like Macromedia Flex is really going to take this to the next level in the coming 24 months.

Publish: What are your biggest pet peeves about Web publishing?

SM: A couple of things. First, under "low hanging fruit," I'd say people's fear of publishing, which usually translates into unnecessarily complex workflow in CMS implementations. Most things don't need to go through four or five rounds of approval. Two or three steps max should be enough in a healthy publishing environment. It's been my experience that the more complex the workflow is, the less gets published.

Also, inflexible CMS systems that tie you to a particular applications server platform for the delivery of production content and applications. If you implement a CMS, it should not care what app server you serve the content up on. Many systems tie the delivery of the content to the CMS. That's restrictive and in my humble opinion, a bad idea. You can't predict what will happen on the bloody battlefield of the app server landscape, so don't fight. Publish your stuff to the platform you like best that month. Keep the CMS separate.

Lastly, and most seriously, I can't stand the idea that a 1-10 man shop can develop and support their own CMS. Don't get me wrong -- Miller Systems has built our own share of focused content management tools -- but never a site-wide, enterprise-class CMS. There are a lot of threatened developers out there that think just because they can design a decent database, write a stored procedure and create a form on an ASP, ColdFusion or JSP page, that they can build a CMS. Publishing, supporting and keeping a real CMS current is NOT a project. It's a venture. It’s a serious enterprise that's very human and cash capital intensive.

Publish: How do you see Web publishing evolving over the near term? What technology, innovation or development could take Web publishing to the next level?

SM: 2004 will see the death of many, many CMS vendors. There are hundreds of them, and there only need to be a couple of dozen.

As far as the future of innovation/technology, I think the vast majority of the infrastructure we could need for the foreseeable future exists today. Making implementation simpler is a big issue. You can publish anything you want to any place you want and make it look and feel different, translate it and make it consumable by any conceivable device. But making it do that stuff is still pretty hard. I think the implementation of RIA inside of CMS and Portal will be a huge step in the right direction. The document model works for a lot of publishing applications, but not so well in an application context. It's akin to the GUI revolution in the late ‘80s and early ‘90s. The Web will undergo a similar transition -- soon.

Publish: What words of wisdom can you offer to businesses looking to use the Web successfully as a business tool?

SM: You *really* need to get your requirements right before you build. If you are just building a 15-page Web site, this isn't rocket science. A site map and an exec summary will get you where you need to go. But if you have multiple content contributors, or any applications that sit next to your content on the same page, or a database you want to connect to, you'd better make sure to do it through a proper requirements discovery process. Otherwise you're going to be in for surprises on the calendar and/or the wallet -- and no one likes those kinds of surprises.