IBM & Red Hat on AWS
To build or buy on AWS, an IBM Filenet story
As customers explore the adoption of AWS as part of their broader business modernization it is common for teams to migrate existing software investments and possibly refactoring or replacing these investments. In this post I will explore the drivers leading to customers’ considerations of whether to lift and shift, refactor or replace IBM Filenet. I will also lay out the issues and possible ramifications of some of these decisions, and then go over the available options.
What is IBM Filenet?
IBM Filenet is a document management solution, which in some functions could be compared to document storage functions within Microsoft SharePoint. At its core is the ability to store business assets (various document types) and related metadata. IBM Filenet provides API layer for application integrations and for end user interaction such as search. Filenet has several layers of storage including file or object storage for the actual customer documents, and a relational data base for the product configuration and document metadata.
As such it is common to see Filenet customers make use of some form of shared storage solution such as Red Hat OpenShift Data Foundation (ODF), IBM Storage Scale or Amazon Elastic File System (EFS), Amazon FSx for NetApp ONTAP on AWS. Relational Databases such as IBM DB2, Oracle Database, or Microsoft SQL Server (MSSQL) are the primary repositories for metadata. If using DB2, other IBM Products such as IBM DataStage may also be used for extract, transform and load (ETL).
In order to meet business functions, customers commonly make use of IBM Operational Decision Manager, or IBM Engineering Workflow Management to cater for automated document workflow and approval. Full text search functions and AI often compliment user interaction. IBM also offers Cloud Pak for Business Automation (CP4BA) which combines Filenet and other services customer use into a turnkey product offer running on Red Hat OpenShift. CP4BA is available via the AWS Marketplace via Bring Your Own License (BYOL) or license included options.
Why do some customers start to explore replacement or building their own?
There are several reasons customer explore replacing IBM Filenet or Cloud Pak for Business Automation with AWS native services, these vary depending on customer and use case. As part of modernizing a business customers may simply be exploring their options, while other customers may be looking to address a more specific concern:
Lack of resources or Skill set: There are customer who either do not have he resources, or skills to manage their existing investment or have a preference to move away from managing these themselves and rather focus on other business goals.
Top down directive for AWS and native service adoption: AWS native services are build from the ground up to be scalable, resilience, secure and are managed providing reduction of undifferentiated heavy lifting thus teams may be encouraged to explore their adoption as part of business modernization.
Product versions, licensing and costs: Customers looking to renew existing investments may be forced into the latest product version or need to move to new architectures such as in the case moving from a stand along version of IBM software which may be replaced by a Cloud Pak offer which is only available as a containerized offering running on Red Hat OpenShift. This may result in concerns around how does the customer support and maintain something new like OpenShift, or is the customer procuring components and features they may not use as part of the turn key new versions.
Building your own, lets do it … on face value:
On face value this could be as simple as making use of Amazon Simple Storage Service (S3). As a base it scales dynamically, has impressive durability, is resilient, caters for version control, and has attractive storage tiers which help address cost concerns for longer term document storage. Create a simple front end for end users or make use of AWS API Gateway and AWS Lambda to create integration points for users and application workloads. Metadata related to the documents stored in Amazon S3, could be stored in a relational database taking advantage of Amazon Aurora, or a noSQL approach using Amazon DynamoDB.
Figure 1 below, illustrates a high-level architecture for that approach. The following blog may be a great starting point: How Liberty Mutual build a highly scalable document management solution.
Figure 1. Document storage solution using AWS Native Services.
When you peel back the onion and dive deeper into use case, requirements and what is actually being replaced there are major factors which need to be considered in order to achieve success.
Considerations
What is actually being replaced?
For the majority of customers using IBM Filenet it is not as simple as creating a solution for document upload and storage, diving deeper you will find that there are multiple layers and aspects which need to be catered for. Careful assessment of the existing solution needs to be completed.
Services such as Amazon OpenSearch, can provide a meaningful full text search option for end users, Amazon Simple Workflow Service , or the serverless AWS Step Functions can cater for all the workflow aspects of the existing solution. You will need to ensure you understand and cater for each workflow, that often results in many teams, departments and internal stakeholders providing insight into who they consume and integrate with the existing solution.
Filenet customers also have the option to create customizations using IBM WebSphere Application Server (WAS), each of these could be custom application workload in its own right which should not be over looked and become a candidate for refactoring or replacement. These customizations are going to be built and run as WAS Java Virtual Machines (JVMs), and each may need to be refactored or re-coded. At the very least you should be exploring what if any custom integrations exist and the implications they carry. For some customer this may represent decades of customization and thousands of workloads which need consideration and potential business impact.
Assessment of all aspects of the current solutions and use case may yield a far more complex endeavor.
Build vs Buy?
Though AWS does provide services which provide the building blocks to meet the current implementation and use case. We have to be realistic that what is being considered is not a once off activity this is really building a replacement for every aspect of the existing solution as well as future improvements maintenance, we will own the full life cycle from where on. Though this may yield benefits it may not be what some customers are willing to under take. Yes there are options such as a strong Amazon Service integrator (SI) partner network which could provide consulting resources to be build and even maintain, alternatively exploring other 3rd party products.
What is the desired time frame?
Time frames and objectives will play a role; for customers with the goal to exit a data center and get into AWS in next few months, building an in house solution to replace all aspects of a document management solution, work flows, integrations and custom applications may be overly ambitious. Conversely it is more realistic for a customer to eat such an elephant over time and do it well. It is not uncommon to see customer lift and shift existing investments or go through a smaller re-host when moving to AWS and then later gradually working towards a more complete modernization or replacement of a solution.
Does this actually address the underlying concerns?
Building and maintaining a end to end document management solution will yield benefits, it may fit well in to the modernization strategy for who developers build and approach workloads on the cloud. Each AWS service does provide value in that they solve challenges such as scale, security, resilience, so the customer can consume instead of invest effort solving these themselves. That said there may be shorter, simpler ways of addressing the actual concerns which started this exploration. If the customers concerns are around new or old versions, adopting an application platform such as OpenShift, or moving to a turn key solution instead of stand alone building and maintaining may or may not be the best way to address these.
Options and alternatives
Stand alone Filenet on Amazon EC2, or Amazon EKS
There is a middle ground for customers with existing investment and licensing for the stand alone version of IBM Filenet. This could be the non-container version which does not require Red Hat OpenShift, that can be deployed on Amazon Elastic Compute Cloud (EC2). Or, a containerized version which is supported on various flavors of Kubernetes such as Amazon Elastic Kubernetes Service (EKS) or OpenShift. These Licenses are completely compatible with AWS and customers can bring that directly to AWS.
I would strongly recommend taking advantage of how AWS and IBM Software can compliment each other. IBM Filenet can be configured to use Amazon S3 as the document storage gaining benefits of the services, scale, resilience, cost benefit etc, this could translate to a 30% cost reduction. For the relational database moving to Amazon Relational Database Service (RDS) means the customer focuses on the database itself and AWS perform the undifferentiated heavy lift of managing the the database infrastructure. Amazon RDS caters for multiple supported database engines (MSSQL, Oracle, and DB2).
Filenet or CP4BA on managed OpenShift
For customers moving to new versions running on OpenShift, firstly the modernization to a container platform has introduced note worthy benefits. The Kubenetes Operators which now under pin the latest version, add automation and resilience improvements. This is especially beneficial for customers going through Filenet upgrade processes, the operators cater for improved upgrade times as well as less failures, combined these translate to less admin over head and business disruption.
Customers with recourse or skillset concerns around OpenShift should explore running on a managed version such as Red Hat OpenShift Service on AWS (ROSA) where Red Hat site reliability engineering (SRE) teams manage OpenShift for he customer making sure the OpenShift Cluster is healthy and available. Taking advantage of managed OpenShift can go a long way to alleviating the concerns of adopting something completely new to your business such as OpenShift.
Whistles and bells with Cloud Pak for Business Automation
Cloud Pak For Business Automation licensing includes subscriptions for self managed Red Hat OpenShift Container Platform (OCP), these subscriptions are not compatible with ROSA. Customers can take advantage of discount programs to offset ROSA subscriptions as they already have OCP subscription as part of their Cloud Pak purchase. Email the AWS Red Hat partner team for more detail on incentives and promotions.
Don’t fear moving from stand alone Filenet to something like Cloud Pak for Business Automation, yes it may contain features and functions not in your current implementation, this provides an opportunity to explore the benefits of new functions to compliment your business. AWS and IBM have a rich partner network which can not only help explore these but also assist with the transition.
For a deeper dive of the architecture you can watch the following video:
What’s under the hood IBM Cloud Pak for Business Automation | Amazon Web Services
Summary
Whether exploring lifting and shift or replacing IBM Filenet with a build your own approach, AWS provides options to make a customer journey successful. That said customers need to ask the correct questions and ensure they are going down a path that is right for the business and actually addresses the true underlying concerns and goals.
It is important for customers to be aware of the full scope and implications of building their own solution to replace IBM Filenet and then assess what is the best way forward within the context of their business. Teams supporting customers need to dive deep and help peel back the onion on all the aspects and drivers in the conversation, helping to address the actual business goals or address the actual underlying drivers. In most cases the true customer concerns can be addressed having to build and own your own software stack.
However if a decision is made that building your own is the right thing to do for the business goals AWS provides a rich collection of products and services which cater for all the required building blocks.
Call to action
If you are migrating existing IBM Software investments to AWS or if you are exploring lifting and shifting, refactoring, re-platforming or even replacing, let AWS and our partners help you achieve success. Contact the AWS IBM Partner team via email and we will help you get the correct resources. Explore Cloud Pak for Business Automation on AWS as a managed Software as a service Saas option allowing you to focus on your business instead of managing administrative overhead.