Interview with Zivtech

Please describe your company and your role there.

My company is called Zivtech. I'm the CEO and co-founder. We're a seven year old, open-source Web design, development, training, and strategy firm located in Philadelphia. I do all of the business development, which involves a lot of the selling and marketing that we do.

What business objectives does a client need to define before selecting how to build their website?

They need to have an idea about the end result, and about what they expect from the project. They also need to list out any specific requirements that they have, and if possible, prioritize them. If they have a different website that they used in the past, they need to take inventory of what they have. This is something that a developer can help them with, but it is also something that they are able to do on their own.

Clients need to consider all of the integrations that they are going to need. What other systems have to be integrated into this site? Are there customer relationship management tools, marketing tools, mailing lists, or analytics? Do they need personalization, video, or audio? These are all the sorts of things that clients need to take stock of before they get started.

What are the key features associated with choosing to build a site with Drupal as the content management system as opposed to building a completely custom CMS?

I don't usually see a lot of people that have requirements that wouldn’t make sense for Drupal. Drupal has many different features that set it apart from the rest. Number one is, it has a very rich application program interface. It is built in a very extensible, flexible way and it can suit a lot of different needs. It is also open source; there are tens of thousands of modules available to extend or change how Drupal acts, and they're available online for free.

Some of the key features that a lot of people are looking for are technical and functional features. One of the key functional features is access control. That means restricting pages or activities on the site to specific users or groups of users. Another feature that people turn to Drupal for is the flexible content types and content models. If someone has a lot of different types of content, Drupal has very flexible ways for making content types and then reusing the template from each of those types. Drupal also has very good integration with a lot of other software as a service applications, like Salesforce, MailChimp, and Google Analytics. It has very flexible front-end capabilities as well.

Between WordPress and Drupal, I always tell people that, if they can use WordPress and if it suits their needs, they probably should use it. They will know when WordPress is no longer able to support their organization, and that tends to happen with complex workflows or when they have a lot of different user roles that need to be able to do specific tasks. With WordPress, I often see sites that are basic publishing sites like blogs and news sites. Whereas a Drupal site might be a school site that has departments, and classes, and teachers, and FAQs. This site could allow those departments to control their own pages, but not other pages. Drupal is often used in more complex situations, with larger, more complex organizations.

One of the companies that we work for has four thousand sites; many of those sites have their own business owners and marketing teams. Drupal gives them a single platform that they can develop from and make a feature set, or an installation profile. They can have a set of features that they’re going to use across all of their sites. They can then hand it over to their marketing team and say, “This is the baseline that you're using. You can design for it, you can make it look however you want, and then you give it back to us.” Then the central IT department can support all of those sites. Before, there would have been all of these homegrown or proprietary systems. There could be hundreds of these systems in some organizations, making them unwieldy and hard to support.

One of the places where Drupal shines, and where we do a lot of work, is when a client needs some type of e-commerce within their site, but not necessarily a store. Drupal Commerce is great for these situations. If a client wants to sell textbooks, or sell access to content, or if they have memberships that are wrapped into a community site, Drupal Commerce really shines in these regards.

Do you ever find that there are any limits to using Drupal?

Sure. Drupal is a content management system, and it's a user management system, but it's not a mailing list. There are lots of things that Drupal doesn't do, and we use other applications for those things. As an example, we had to build a system for printing shipping labels, and querying some other system to get those labels. That's not really a content management issue, so we used Node-Webkit for that. Node-Webkit is a Node.js system from Intel.

Another example, we have a big ERP system that we're working on and we're replacing some of the core of it with an open-source system called Apache Kafka, which LinkedIn released. It is a repository for messages and things that are happening on the site. There are very few Drupal sites that don't use other technologies on them. For example, every Drupal site uses jQuery, which comes bundled with Drupal, but it's not Drupal. Almost every Drupal site uses Apache Solr, which is for faceted searching, and it works really well with Drupal. If you want a powerful, faceted search on your site, you're not going to try and do that in Drupal, you're going to leverage another system.

Content management, user management, and workflow management can all be done in Drupal. Whenever you need to do things that don’t pertain to those, you're going to leverage other technologies. You're probably not going to build your CRM right into Drupal; you'll use Salesforce. You're not going to build your mailing list in Drupal; you'll use MailChimp. You're not going to transcode and host videos yourself; you’ll use YouTube. You're going to leverage other tools when it makes sense, when it saves you time and money.

Have you ever run into problems integrating outside tools and software with Drupal?

It all depends on the quality of the other tools’ API and the limitations of them. There can be challenges to integrating any systems. There are notoriously difficult systems to integrate with like hospital-record systems such as EMRs. We can make Drupal integrate with anything, but is the other system able to integrate with Drupal? Is the other system able to integrate with anything?

One of the big problems that we run into is poorly documented APIs from software as a service organizations, or even software as a service organizations that claim they have an API and it doesn't work. They sell our client on some tool, and then, when we go and build the integration, it doesn't do any of what it says it's going to do. In general, if the group that's creating the API is able to fix their system, then we can work with them to fix it. I've never seen anything that Drupal can't integrate with. It has a robust Web services component to it.

Do you typically build any simpler types of websites?

Sometimes, but not typically. We do a lot of work with some of the top pharmaceutical companies. We tend to work on custom projects that require a lot of heavy lifting. We also will work with organizations to help them fix Drupal implementations that other people broke or built poorly. Somebody else may have underestimated the complexity of something, started building it, it didn't go well, and then we have to take over and redo it, or fix it.

With that being said, we do take on a fair amount of smaller projects. We do that mostly because we train a lot of our own staff, and we want them to get a full understanding of the whole system. On a bigger project, you need to be very specialized on what you're working on. If you work on a smaller site, you're going to get to understand the architecture of it; you're going to get to implement both the back and the front-end. In Drupal, that includes both site building, which is when you're just clicking around in the interface, as well as modular development, which is when you're actually writing code. We do some smaller engagements, but the majority of our work is certainly on more complex implementations.

What are some of the security advantages of using Drupal?

There are a lot of security advantages to using Drupal. You can always see what code is running your site. If you have the need, you can read through every line of code and try to understand what's going on, and try to find out if there are any holes. I think the number one security feature of Drupal is that when you see all of the possible problems on the million or so Drupal sites, you get this phenomenon of open source that's always talked about, ‘With enough eyes, all bugs are shallow.’

There's a lot of complexity in the system. There was a Drupal core update even last week, which is amazing. If you think about the fact that the White House is running on it, the ATF is running on it, the Navy is running on it. These are organizations that people are trying to attack, from outside of the United States, and possibly from inside as well. They haven't been hacked. It’s eminently securable.

Drupal tends to be as secure as the developers who build the site make it. There are a lot of features for admins that some people will just open up for anybody, and obviously, it's only as secure as you make it. The code itself is extremely secure, but the site is configurable in ways that might not be. If you don't have an understanding of how the system works, if you don't follow the warnings, you might do things like open up the ability for people to post executable PHP code to the site, which is a really big security hole.

If you work with a firm like ours, none of that is going to happen; we go through and do security checks. In Drupal there's actually a security check module that can do a lot of the security checks automatically for you. Drupal is extremely secure, and is being run by the largest corporations and governments in the world.

What are some of the key drivers of cost in building a website?

The number of integrations is definitely a key thing. The number of unique workflows or different templates needed on the site is key as well. How many decision-makers there are can be a driver of cost. If you have a lot of stakeholders involved, they can get very particular about every little piece and want it to conform to exactly how they want.

One of the drivers of cost that we see is poor design. People design and architect things in a way that isn’t really friendly for Drupal, or for the web. There are a lot of designers that still think the web is flash, and that has not been the case for a while. I think that can be a driver of cost. Commerce can be a driver. One of the things that can drive up costs for large organizations is testing. This means writing automated tests, so that as you build your site, you can see how a new feature will effect the processes on the site, or you can see that the site is up at all times.

If you have no tolerance for a site going down, or for anything breaking as you develop and maintain it in the future, those can drive up the costs. On the flip side, you're paying for assurance. It would be very embarrassing if the White House site went down, so they test everything extensively. That can be a key driver of cost. The complexity of the integrations is definitely a driver of cost.

Are there maintenance costs after the site is built? Do you bill hourly for that or do you provide general maintenance packages for updates and support?

We have a couple different ways we do support, but any piece of technology, whether it's a computer that you buy, or a TV, or a vacuum cleaner, it's a technology that needs to be maintained and updated. Generally speaking, any technology is going to require a certain amount of effort to keep it going. In Drupal's case, you need to at least maintain the security state of the site. Your site is not going to stay secure if Drupal releases a security update and you don't update your site.

Generally speaking, most of our clients want to improve their sites over time, and not just stay with whatever they get after it goes live. Once they’ve gotten feedback from their constituents, or clients, or customers, or patients, they're going to want to change some of what they're doing. Most of our clients do end up working with us for a longer term, and that work varies between normal maintenance, updates, and new features as they decide they want them.

We do bill hourly, and then we work pretty agilely with our clients. We do sprint-based work; if you can wait for two weeks for a sprint to start, and then two weeks for the sprint to end, so essentially a month, then we do the project under our normal sprint rates. If not, we consider it an emergency, and you have to use support rates for that. In general, that's just a way for us to encourage the type of relationship that we really need to maintain, in order to keep some sanity in the process.

What are the benefits of hiring a Drupal development company to build a website?

As far as why you should hire Drupal experts, the number one thing you're dealing with is a big, complex system that has a lot of moving parts. There are a lot of potential problems, especially once you get into the contributed modules that are available. There are a lot of things that you can do to mess up; you’ll think you've found a shortcut, but with experts - they've tried that shortcut and it didn't work. You can avoid a lot of those problems by hiring an expert.

If you think that you're going to have a large, growing site that needs to be maintained for a long time, then there are a lot of benefits of working with a firm that builds and maintains sites because they're going to do it with an eye towards sustainability of the code. With a Drupal shop, you're going to get a lot of extra things that you wouldn't get from an individual; you will get development tools, virtual machines for your development environment, and good workflows and practices around working together as a team.

I think it's especially important to hire people that have a lot of experience in the Drupal community. One of the big things that I try to relate to companies that are evaluating Drupal firms is to make sure that those firms are following best practices for working within the community. An example of that is making sure that, if they change code in some module, they submit back a patch that can be maintained by the broader community. In Drupal.org there are a lot of tools that you can use to look at the developers and to make sure that when they work, they're working in a way that's going to be within the flow of the open-source tool that they're using.

You also get a lot of diversity by working with a firm, diversity of experience and expertise. The bigger the firm, the more skillsets that are available to you, which can be a real benefit. We have people that are really good at Drupal and Angular, people who are really good at Drupal and Salesforce, people that are really good at Drupal and MailChimp. You might have some of that in one person, but they're not going to be able to draw on those other resources if it's just them.

Another important thing is that when you work with experts, they will have an understanding of the total architecture at the beginning. They will be able to explain the shortfalls of different approaches to different problems. One of the issues that we see is when people go ahead and implement different things within the system and really base the whole rest of the system off of that one set of implementations. Let's say that you want multiple sites. Drupal has six different ways to handle that and all of them have their pros and cons. How do you know which one you're going to use? Only an architect is going to be able to give you the intimate level of detail that you need to make an informed decision about that level of architecture. Sometimes if you make the wrong choice at first, it becomes a rebuild later on whereas if you're working with experts, they can build a site in a way that you don't necessarily have to have all the features, but at least they're open to you later.

What unique value does Zivtech offer?

One of the great things about being in the Drupal community is that we're surrounded by good developers and development shops; there are a lot of other firms that we respect and are contemporaries of ours. I think our involvement in the Drupal community, our deep integration expertise, our focus on quality and quality assurance all help us excel, especially within enterprise environments.

We’re pretty intense, we’re highly focused, but we’re also pretty fun to work with. We care a lot about our clients, and hopefully that comes across to them. Those are things that I think people really enjoy about working with us.

We're transparent and open with our clients. With some clients, it's taken them a while to get used to that; the fact that we're going to show them everything about how we're working and not hide anything from them. For clients that are used to working with consultancies where you put in specifications in one end and out the other end comes a site, our openness might be a little jarring. I think ultimately, once they see the results of working closely together as a team, then that value becomes pretty apparent.