Technical info and insight on using Oracle Documaker for customer communication and document automation

Thoughts On Documaker Cloud Implementation

Andy Little
Technical Director

Defining the Cloud

The term cloud computing is a general-purpose word that describes provision and consumption of remote computing resources. If the question is posed: "How do we implement/migrate a software package to the cloud?" the necessary first response should be a clarification discussion to understand what the asker means by the cloud. There are common models applied to cloud computing which can help constrain the ask above, specifically the service model and deployment model. These are important to understand, because these models constrain the scope under which a software package or configuration must operate. There are multiple characteristics that are common to cloud computing platforms, but the most important are:

  • services provided are scalable, also called elastic, so that that you don't need to provision an infrastructure to support your peak loads.
  • services are billed on usage - meaning, you only pay for what you use.

Service Models

The service model includes some common terms that you might already understand: IaaS, PaaS, SaaS, and others. With respect to Documaker, currently only the IaaS or PaaS models are applicable, so the others will be ignored.

In the Infrastructure as a Service (IaaS) model a cloud services provider makes available a computing infrastructure onto which you can install your desired operating system, applications, tools, and data. In this model, you, as a customer, are responsible for the operating system, software and data, while the cloud provider is responsible for the infrastructure such as network, servers/virtual machines, storage, load balancers. Simply put, IaaS is like a sandbox in which you can build your castle, but you have to supply the molds and tools and the cloud services vendor provides the box and sand.

In the Platform as a Service (PaaS) model the cloud services provider makes available a set of computing services, such as a database, execution runtime, tooling, and other components onto which install your application and data. In this model, the customer is responsible for custom applications and data which may (or may not) use the cloud vendor's provided applications and services that are running on vendor's infrastructure. Continuing with the sandbox analogy, under PaaS you can build a castle but you must use the vendor's box, sand, molds, and tools.

To be complete we can briefly discuss SaaS, which is the model in which the vendor provides and manages the infrastructure, services, and applications while you the customer provide the data. A real-world example is a service like Oracle's Financial Services Cloud Communication service. The SaaS sandbox doesn't allow users to build their own castle, but you can play in your own section of the vendor's prebuilt castle.

Deployment Models

The choice of deployment model largely depends on requirement, risk, and cost. Documaker does not specifically require one model over another in terms of requirement, so long as the underlying hardware/software requirements are met in the service offering. Requirements become a primary factor in the deployment model when considering the solution and its integration points. For example, if your Documaker implementation contains integrations to upstream or downstream software components, these must be considered in the deployment model choice. There are three typical deployment models usually offered by cloud providers:

  • private cloud in which the infrastructure and services are provided for a sole organization, and are hosted either internally or externally. Such services may have gateways that connect the cloud services to the Internet, but this is not a defining characteristic of this model. Continuing the sandbox analogy, the private cloud is a sandbox in which only one customer can play, so the vendor builds a sandbox just for that customer - either in the customer's yard or the vendor's yard.
  • public cloud in which the infrastructure and services are provided through the Internet, and there is typically a direct-connection service provided by vendors to allow customers to link to their existing data centers for workloads that are not operating solely in the cloud environment. On the sandbox side of things, the public cloud is model is a big sandbox in which everyone plays, but each person can optionally have gated connection to their private sandbox.
  • public cloud in which the infrastructure and services are provided through the Internet, and there is typically a direct-connection service provided by vendors to allow customers to link to their existing data centers for workloads that are not operating solely in the cloud environment. On the sandbox side of things, the public cloud is model is a big sandbox in which everyone plays, but each person can optionally have gated connection to their private sandbox.
  • hybrid cloud is a combination of public and private clouds, the details of which vary per vendor.


There are a number of vendors that provide cloud services, such as Oracle, Microsoft, Amazon, Google, IBM, and others. As one might expect, each vendor has differentiating characteristics that may make them more suitable for one use case or another.

For example, Oracle's cloud approach is based on its history of security and governance, which has resulted in a cloud services architecture that enables silos for application control and data. Amazon Web Services (AWS) has a huge marketplace with global reach that makes it easy for startups to quickly create new applications from the ecosystem of AWS tools. Microsoft's Azure system is embedded with Windows applications and tooling, making it a good choice for businesses looking to migrate existing Windows-based workloads.

When developing a business case for moving workloads to the cloud, service offerings are a first concern, however they are not the only concern. Cloud vendors have shared characteristics in their design and deployment that is exposed to the customer. Most vendors have similar objects, nomenclature, and processes that are used to perform common tasks such as deploying a virtual machine into an IaaS environment. Underneath those commonalities there are differences in network topologies, infrastructure maintenance procedures, redundancies offered, service level agreements offered, and more.

All of these items are reflected in the price that you, as the customer, will ultimately pay to consume those services. It is important to consider these elements when making a business case and plan to migrate workloads to the cloud. We might consider the hard costs of cloud migration e.g. your workload is X, and the cost of X is X*Y1 for Oracle, where the workload is considered in terms of compute cycle costs or data I/O costs. It is important to consider soft costs as well: how is elasticity/service levels guaranteed and what happens when service levels aren't met? How is governance enabled and what are the potential risks and business costs if there is a data leak or non-compliance with regulations? This list is simply to spur thought, and is not conclusive.

Documaker in the Cloud

Undoubtedly the most pointed question will be is Documaker version X supported on Vendor Y's cloud platform? and the answer still still not quite straightforward as we still have variables to consider. Any long time architect of Documaker services probably understands that Documaker is at its heart an extremely capable set of tools with some prefabricated use cases to support common business operations for generating communication. This has been the case for nearly two decades until the advent of Documaker Enterprise Edition, which sought to push the envelope of Documaker into a more modular approach with established use cases, while still supporting existing Documaker libraries.

To answer the question we need to understand the Documaker solution that is being migrated. Your solution could be some or all of these (or more):

  • a Documaker batch system
  • a Documaker on-demand system, running Docupresentment (and possibly also EWPS)
  • a Documaker interactive system, running  iPPS or iDocumaker
  • a Documaker Enterprise System
  • a combination of any or all of these on homogenous or heterogeneous platforms and versions, running single- or multi-step, with feeds in and out of various systems, with different workflows for migrating changes across.

In short, there is not a simple answer, however there are some general guidelines that can be followed. First and foremost is you should being with a catalog and understanding your current system. You should know:

  • each implementation of Documaker in your application ecosystem and what it supports
  • every environment supported by an implementation of Documaker
  • what versions of Documaker are used in each implementation
  • any customizations (e.g. compiled code) that is executed within Documaker and what it is for
  • all data inputs and outputs to and from Documaker such as:
    • integrations that rely on data generated by Documaker
    • data used as input to Documaker
    • migration of resources from development environments to production environments (e.g. how form library components are migrated).
  • end-user requirements and workflows
  • performance characteristics and requirements of each implementation
  • hard/soft requirements of each implementation both of Documaker and ancillary applications (e.g. if Documaker is using a library that is stored in MS SQL Server, what version of SQL Server is being used? Is there a reason that specific version is required?)

With this information in hand you should be able to form a picture of what should be considered in a workload migration.

An overarching concern that should influence every facet of your cloud journey is the need to execute regression testing, both in the literal and figurative sense. Your private sandbox in your corporate data center that has never been exposed to the outside world may be moved to a public cloud, and your existing regression test suites may be nonexistent or may be lacking in scope to adequately test the wholesale movement of business processing onto a new platform. Consider the application boundaries presented by the solution and how those may be affected by migration to a cloud environment. Your corporate governance structures may lack the scope and depth necessary to encompass the wider security concerns presented by moving business applications onto a cloud infrastructure, and should be taken into account as well.

For example, if the entire business application suite is moving, the boundaries may be entirely non-existent. If only some of the business application components are moving to a cloud environment, there are now boundaries that did not exist previously. Those boundaries will need to be adequately tested in your regression test suite. Similarly, governance structures may not account for these boundaries since they do not exist currently. There may be some governance rules in place, but they may lack the scope necessary to address a cloud deployment, and so these must also be considered. A concrete example of a boundary is represented by Documaker Studio. This application runs on a user's workstation or in a virtualized workspace like XenDesktop or Citrix, and accesses the database for interacting with form resource libraries, typically in a development environment. The application may also be used to interact with other environments to facilitate migration of changes to downstream environments. If the Documaker solution is moved to a public cloud infrastructure, you will need to consider how to address the solution boundary presented by the separation of your corporate users and the application now running in the cloud infrastructure. Thankfully this is not a problem that is specific to Documaker, and is a common use case that is typically addressed by using virtual private networking between your corporate network and the cloud provider network.


Diving in the service models that you might consider, the simplest level is represented by a migration of a Documaker workload from an on-premise datacenter to an IaaS cloud offering. This migration presents the least risk and complexity, as long as the cloud vendor meets the requirements that you have outlined in your solution requirements catalog. The lift-and-shift into a like-for-like environment is not without risk so long as there is adequate regression test coverage and identification/mitigation of potential issues beforehand. A typical migration might involve a migration from Documaker on Oracle Enterprise Linux 7 machine in your corporate data center to an Oracle Enterprise Linux 7 virtual machine in the cloud infrastructure with similar characteristics. Not all vendors offer the same operating systems and versions, but Documaker is generally flexible in terms of OS, so you need to consider this scope in your regression testing to ensure it does not present any issues.

It is important to point out that on some platforms, Documaker does present some specific requirements that should be captured in your solution and requirements catalog. For example, on a Linux-based platform there are some prerequisite components that must exist, and must be at certain version levels e.g. libgcc and libgcc.i686 are required.

The next level of complexity is represented by the PaaS service model. Recall that PaaS provides a set of computing services, such as a database management services, middleware, and development tools. Under this model, more components are provided for you, and this represents additional risk since they may not be offered at the level required to match your solution and requirements catalog. There is also the possibility of mixing IaaS and PaaS in some implementations. For example, you may deploy Documaker to an IaaS platform, but take advantage of an RDBMS PaaS offering - you must keep in mind there may be some limitations in your ability to change some aspects of a PaaS offering. For example, you may not wish to use Azure DB with Documaker Enterprise Edition and support certain languages because your Azure DB may not be set up with the proper collation to support foreign languages. Additional risks may be present in other cloud-based services that have not been explicitly tested with Documaker.


Q1. Can I deploy Documaker to the Cloud?

A1. Documaker (both Enterprise and Standard) has been successfully deployed in Oracle Cloud Infrastructure (OCI), Amazon Web Services (AWS), and Microsoft Azure.

Q2. Who is running Documaker in Cloud environments?

A2. There are a number of large corporations who are currently migrating their Documaker workloads to the cloud. However, we cannot release this information publicly. You may consider joining the Documaker Client Advisory Board (CAB) whose membership includes many Documaker customers with whom you can discuss such matters.

Q3. Can I use my Documaker license in a Cloud environment?

A3. There is not a one-size-fits all answer here, but generally you should be able to do so. If you have a concern you should contact your Oracle license sales representative, or Oracle Support for additional information.

Q4. Which cloud vendor should I use?

A4. The choice ultimately depends on how well a provider's solution matches your solution and requirements catalog, so the answer depends on the scope and breadth of the catalog. Your catalog should also include soft requirements as discussed above. Finally, such a decision involves cost/benefit analysis, risk analysis, and return on investment. These elements are outside the scope of this paper, but as has been alluded to in the above, there are wider concerns than just putting your data and applications on someone else's computer - there are governance and security concerns as well. In any case, Documaker is an Oracle product, and Oracle platforms typically receive the most attention in terms of product development and support, so you can't go wrong with Oracle Cloud.

If you have additional questions, thoughts, or concerns, feel free to post a comment below, or head over to the Documaker community

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.