What is our primary use case?
The use case is that we are building a backend application for the tax office here in Curaçao. The tax administration sends out documents to people who need to pay taxes. All the communication, all the letters, are designed using Windward products and are also generated by Windward engines.
We are not using it as a report-generation tool. We are using it more as a letter/document generation tool. With the functionality of Windward, we can adjust the documents dynamically to the individual needs of every taxpayer. The "if this then that" functionality in Windward allows us to design the documents dynamically so that there is only information on the document that is relevant to the taxpayer.
How has it helped my organization?
Before using Windward, we were using another document creation tool and this old tool required some very specific, technical, XSLT knowledge, which was scarce. We didn't have a lot of people with this knowledge and it's also scarce in the market. By changing to Windward, the whole technical challenge of creating a document has been eliminated.
Our business users who are like business consultants in our company are now able to design documents together with our customers. Before, the business consultants were only able to draw up specifications which had to be sent to the technical guys who would actually create them. We eliminated one step in the whole process of development.
In addition, in the future, we are aiming for a situation where our customers will be able to maintain their reports or their documents by themselves. Because it is a Microsoft Office plugin, and our customers are familiar with Microsoft Office, we expect that in the future they will be able to maintain their reports by themselves. That would be more efficient for everybody and eliminate yet another step in development.
As for the ability to design templates within the Microsoft Office Suite, it works fine. We primarily use Microsoft Word, but lately we have also been generating reports with Microsoft Excel. Excel requires a little bit more technical knowledge, especially about Excel, of course, to be able to create good documents. But the document creation process has been simplified a lot and we can now allow colleagues with more of a business background and knowledge of Microsoft Office to create documents that work. The technical XSLT guys are not required in this part of the process anymore, so they are now spending their time on other technical issues.
These technical guys were really scarce in our company, so if we had had to the pull off the project that we did here in Curaçao, that went live with Windward, we would have had to hire more technical guys or train more technical guys to get all the reports, all the documents designed, doing it the old way. That wasn't necessary.
What is most valuable?
The most valuable feature is that it provides good, dynamic document-generation performance and the documents are being generated reliably. These are very important features to us.
In the report-designing area, we are using quite a bit of functionality to adapt all the documents. We're using Import Tags and Out Tags, we're using For-Each loops, we're using headers, footers, custom font types, watermarks & barcodes. We're using a whole bunch of functionality and it all works reliably.
For the designer we use AutoTag which is a Microsoft Word plugin. In general, it's easy to use, it doesn't have a very steep learning curve. It's not difficult, for people who know Microsoft Office well, to start using the AutoTag tool. The plugin has an easy look and feel. It feels just like you're in a Microsoft Office environment with some extra functionality. It's well done. The quality is good, there are no layout glitches, no design glitches in the front end of AutoTag designer.
What needs improvement?
Regarding AutoTag, we do notice that when you want to refactor a little bit of your template design or when you want to implement changes, sometimes you need a lot of clicks to get the change done. For instance, if only one identifier's name is changed and you need to change that identifier throughout your documents, it would be helpful to be able to do a find-and-replace, find all the identifiers with the old name and replace them with the new name. We haven't found a way to do that with a find-replace tool. Throughout the Windward user interface, you need a lot of clicks to get that done. That can be a somewhat tedious task. If you want to do somewhat more technical tasks, the front end can be a little bit slow or inefficient because you need to perform a lot of clicks to get the technical change done.
Also, there's always a little bit of a struggle for our customers to get the licensing done. That is because we develop on a platform that would prefer a Java Engine. The platform will communicate better with a Java Engine. The platform also does install with many instances, and the problem is that for every instance you have to pay for a license which will then increase the cost enormously.
Instead of using the integrated Java Engine we are now using th RESTful engine, which is kind of like a standalone Windward instance that we can call as a service. It generates documents for any of the instances that we want. So instead of having ten Java instances, we only need one RESTful instance for the same functionality, and for one-tenth of the cost. So even though the preferred technical implementation is Java, we are using RESTful, simply because the licensing costs are a lot less. I find it a bit of a shame that the business model doesn't allow us to use the preferred technical implementation.
For how long have I used the solution?
Three to five years.
What do I think about the stability of the solution?
It's very stable. We haven't had any issues.
We have only done one update of the Windward product, after we asked for some error-handling functionality, and Windward built that for us. They released a new update that included error-handling and we updated our product at that time. That caused some issues. Upgrades are usually when some templates will start working a little bit differently and we might need to change little things here and there, but there wasn't anything big. As long as we don't upgrade the product again, I don't expect any stability issues.
What do I think about the scalability of the solution?
With the RESTful engine, we are able to very easily scale, because the RESTful engine is set-up as a standalone service: we just call it with a Rest-message and it returns a document. We can send requests to that service from any application that we want and generate documents.
The Java Engine, on the other hand, needs to be installed on every instance of the product that we are building. Even though that integration would be preferable from a technical point of view because it would eliminate a lot of requests to another server, requests that create overhead, the business model simply is not scalable. We cannot pay for every instance that we install.
How are customer service and technical support?
Whenever I have an issue, I submit it to technical support and they always answer within the same day, mostly within a couple of hours. Usually, the problem is solved that same day. Within Windward support there are two lines of support. There's the lighter helpdesk and if they cannot fix the problem you get through to the more technical guys. All the problems that we've encountered so far have usually been fixed within two or three days. It's been a pretty good experience.
Which solution did I use previously and why did I switch?
We are using the BeInformed platform which is a low-code platform, a process-modeling platform to build applications. This suite had document generation tool integrated. It's not a very well-known tool but it was an FOP and XSLT-based technology they used to generate PDF documents.
We switched because our document generation process was tedious generating a lot of errors. Our business consultants would draw up specifications and send them to the technical guys who would then use the FOP and XSLT technology to design those documents. Of course, the technical guys don't always understand the business so the documents would come out differently than expected. There were a lot of issues, and by eliminating that whole step, the whole document generation process is a lot more efficient. It's a lot easier to design the right documents with a customer looking over our shoulders while we're designing the documents in Microsoft Word.
How was the initial setup?
We did a proof of concept when I started a few years ago. It was not straightforward for me but I also had almost no experience with this whole integration of platforms and tools. It was the first time that I was integrating a new tool into an IT system that already existed. I was surprised that I got good results within one month, when going back and forth with Windward support. I was surprised that it worked out so quickly and so nicely. If I were to do it again today and I things might be more obvious, but I was surprised that everything was working pretty quickly.
Things that came across as complex included connecting with a database or installing the right forms on the server. They were technical things that you forget or you don't know how they work or haven't seen them before.
The setup is a continuous process. Until today, we are reconfiguring things, adding new functionalities. It never really finishes. We got the first version up and running after one month for the proof of concept and another month for implementing it into the actual product.
Our implementation strategy was "just do it."
The easy part of this project was that it was a new project, so there were no documents being generated yet in an old-fashioned way. We do have customers running with our old technology, which we did not migrate. So it was kind of easy for this project to just implement Windward because there was nothing else anyway. Instead of going down a known route, we took an unknown route which turned out to work pretty well.
What about the implementation team?
We did everything in-house, mostly by myself, with the support of Windward and my colleagues.
We had one template designer who focused on the AutoTag part. We had our general deployment guys, our deployment department, that configured all the servers and the engines - not only internally but also for our customers. We definitely needed their experience as well. There were three people working on it most of the time but not full-time.
What was our ROI?
It would be difficult to measure whether Windward has reduced cost in our organization. It would be very difficult to measure because we don't have a "before and after" situation. The only thing that I do know is that the whole process of document design has been a whole lot smoother with fewer errors, which, of course, means less cost to fix them. But as the whole thing just happened under the umbrella of an even bigger project in which we didn't use an alternative document generation technology, it's very difficult to measure the before and after situation.
What's my experience with pricing, setup cost, and licensing?
From my experience in this field, the product is reasonably priced, at least with the RESTful engine implementation. It's definitely not a cheap option. People say, "That's a fair amount of money to pay for a document generation tool." At the same time, you do get good functionality and the support is good. You do get something back for your money. So that's good.
We work in the Caribbean with small island developing states (SIDS). We do notice for some small island communities the license costs are a real bottleneck. So we cannot implement this solution in their environments because the license costs are too steep. It's a matter of a scaling disadvantage in this region because some islands just have 20,000 or 30,000 inhabitants and they need a whole independent IT system for tax administration. That's a big investment for such a small community. Sometimes, just because of cost savings, we cannot implement the preferred solution. That's part of being here in the Caribbean.
You need some kind of scale to be able to afford something like $16,000 to $17,000, for a document generation solution, and we are not always able to reach that scale with our customers here. That simply eliminates Windward as an option. It limits the business of Windward in this region.
Which other solutions did I evaluate?
Before we started the proof of concept on Windward two-and-a-half years ago, we did market research on document generation tools. I did download and try out Crystal Reports. The look and feel of Crystal Reports is something like Windows XP, or it was at that point. The look and feel of the AutoTag plugin and the designer of the Microsoft 2017 plugin was a lot better.
We also went with Windward vs Crystal Reports because we had in mind that our customers, at some point, would be able to maintain their own reports. Our customers are mostly proficient in Microsoft Office and not in another tool. So we found that to be a big plus.
What other advice do I have?
I was contacted by a Dutch guy recently who was considering using Windward for one of his projects. So I told him more or less what I said above: that we have had a good experience, that it's a solid tool and stable tool, which is not too difficult to use for a Microsoft Office user. Also, the support is pretty good. We use other third-party software as well but in my opinion, the Windward support has been the best support I have experienced so far.
We don't use PODs (Portable Object Doclets) because we prefer to use Import Tags and sub-templates. Once you insert the PODs into a template, they're physically there in the template and they will not update as you update the POD. However, with the Import Tag, when you update the sub-templates, the change will automatically be committed to all the main templates that call the sub-templates. It's easier, for maintenance of your template repository, to use the Import Tags with the sub-templates rather than the PODs, where they physically insert the code or a piece of functionality into your template. We're not using Windward as a reporting tool to report, like people who have management reports based on database information. Rather, we're using Windward as a document creation tool which generates thousands of almost identical documents, that are specific for each taxpayer.
Staff requirements for day-to-day maintenance depends. Once a document is finished, our customers have agreed on the template, there's not much maintenance left to do. It's only when the customer requires changes or sees bugs that we need to do changes. We don't spend a lot of time with maintenance at this point.
We have two projects that are using Windward at the moment. With these two projects, there are about ten people who touch the Windward solution. They include the AutoTag designer and the more technical RESTful engine and deployment area.
For me so far the Windward document generation software is the preferred solution for creating documents. That means that we will always advise our customers who need documents created or who need to update their document generation process, to use Windward. We will implement Windward with them. We have one big project going on now that has Windward implemented, and one smaller project. Our company runs three or four big projects at the moment, and about ten or 15 smaller ones. There's still a lot of room for change and there's a lot of room for Windward implementation.
We've recently started to use Windward not only for document generation but also for actually creating management reports. I believe that that is how most Windward customers use the tool, to generate management reports based on data in a data warehouse in an SQL database or any database. Whereas our initial use case was document generation, which has a slightly different philosophy, because in the document generation you don't want to necessarily always display the most recent data, you want to display data from the moment that the document was initially created. We have more static data saved in XML files. Our data source is not a SQL server, but rather they are XML files.