One of the most valuable features is the website that sits on top of the database. There's a database of objects and how they are related, and you can make views and diagrams and visual elements out of that information on the website. The website is the part that is called Evolve and we use the Evolve Designer and publish the website out to our employees. They can click around and navigate and search, etc. Evolve enables people to look at the processes in multiple ways. Unlike a documentation repository of processes, where nano-processes are written up in a textual form, this allows people to make use of the processes in ways that they hadn't been able to before. They can go to the tool and say, "For this process, what is the application that helps us run it?" Or they can ask the question in the opposite way, and say, "For this application, what processes are involved? Or what processes does this application help us do?" Then they can see all the various processes that are related to a particular application, or a particular department, or location, or project, etc. We use the client/server version because it's more powerful. That's what we started with as the web-only version was not robust enough for us. They keep telling us that they're going to rid of the client and make it totally on the web, but I haven't seen that happen yet. I have a group of architects who do this kind of work and they're very accomplished and intelligent. We've learned how to use the more complicated client/server version. It suits us because there's more power to it and we know it. We don't need an easy-to-use, dumbed-down version because it's not that hard, and because we've used it for a long time. We have a stable group, people who have been here for the whole time that we've had it. The client/server version is perfectly fine, because it has the web module that sits on top and publishes the information. If it didn't have that, that would be terrible, but for years now it has had the Evolve piece on top of it. That lets the whole organization browse through the information quite easily. Another tool that we use in the erwin suite is called Collector and it allows us to integrate our enterprise architecture repository with other repositories of information. For example, we have all of our employees' information in a cloud system called Workday, but we need to have employees' information in erwin so that we can relate employees to processes and employees to applications, for responsibility purposes. Every 24 hours, we use the Collector tool to synch all of the employee information into erwin, which is already then related to these other pieces. We don't have to maintain that information in erwin because it's maintained elsewhere. We do that not only with our employees, but with a bunch of process documents as well as with projects and equipment. So Collector really is an important tool in the suite, if you're going to manage a lot of objects. We have 15,000 objects in our database.
