Child pages
  • How To Share a Case Study or White Paper
Skip to end of metadata
Go to start of metadata

As an identity management, access management, or directory services expert, part of your work involves advising and helping people to deploy OpenIDM/OpenICF, OpenAM, or OpenDJ technologies for their organizations.

Perhaps you already partner with ForgeRock, and you are features on the partners page . Perhaps you want to become a ForgeRock partner .

In any case, you have expertise that people interested in the technologies should know about, because they may well need help from you. One way of demonstrating your expertise is to share a white paper or case study that showcases one of your success stories.

You can share content on the ForgeRock.org Wiki in different ways depending on how you want to license the content.

  • Sharing the content in a Wiki page itself makes the content available for reuse with CC BY-SA by default. One advantage of sharing in this way is that your content gets closely associated with ForgeRock.org and shows up in searches on that domain.
  • Sharing a brief description and a link to your content in a Wiki page leaves you full control over the license, while helping people coming to ForgeRock.org find the information.

Please feel free to post in the main language of your audience.

Case Study Template

The case study focuses on a particular deployment. Your case study summarizes a particular successful deployment in the equivalent of perhaps 3-10 printed pages.

The following outline is only a suggestion. Feel free to adapt it to your needs.

Case Study Title

by <author>
<Change this to your one-line description of the case study that sums up the entire deployment in a few words.>

Overview

<This executive summary recaps all sections of the case study on one page or less: Business Challenge, Key Requirements, Solution, Benefits, Quotes, About Customer (whose solution was deployed), About <Partner> (you/your organization).>

Business Challenge

<This section covers the opportunity/problem that led to the deployment, including constraints that drove the choice of solution.>

Key Requirements

<This section explains each primary requirement the customer expressed that further constrained the business challenge. Often key requirements pertain to interoperability, availability, security, scalability, and SLAs.>

Solution

<This section identifies components of the solution, including what hardware, software, and services were used, an overview of the solution design, particular value added for the implementation and deployment coming either from the hardware, the software, the services provided, or any combination of the three.>

Benefits

<This section identifies the benefits provided by the solution. Consider both value added directly in the form of increased revenues or cost savings, but also value added indirectly for example in organization agility, scalability, ease of maintenance, and so forth.>

Lessons Learned

<Real-world deployments do not always proceed as smoothly as initially anticipated. Lessons learned from one deployment can help to smooth future deployments, and influence solution and software design.>

Quotes

<This section provides testimony about the solution and the implementation that illustrates why the deployment was a success. You might prefer to insert quotes inline where they best fit, rather than adding a dedicated section.>

About <Partner>

<This section describes you/your organization, and why others see you as an expert in this area. This section also provides your contact details.>

White Paper Template

Your white paper explains how to take advantage of a particular opportunity or solve a widespread technical challenge in the equivalent of perhaps 5-20 printed pages. Rather than focus on a particular deployment, your white paper focuses on an opportunity or a problem that you solve using OpenIDM/OpenICF, OpenAM, or OpenDJ.

The following outline is only a suggestion. Feel free to adapt it to your needs.

White Paper Title

by <author>
<Change this to your one-line description that sums up the technical white paper in a few words.>

Overview

<This executive summary recaps all sections of the case study on one page or less: Opportunity/Challenge, Key Requirements, Technical Solution, Benefits, About <Partner> (you/your organization).>

Opportunity/Challenge

<This section covers the opportunity or problem that the solution addresses.>

Key Solution Characteristics

<This section covers the primary requirements and characteristics of the solution needed to take advantage of the opportunity or meet the challenge. Often key requirements/solution capabilities pertain to interoperability, availability, security, scalability, and SLAs. Key characteristics could include additional points such as avoiding vendor lock-in, or paying only at the point of value.>

Solution

<This section identifies the architecture and components of the solution, describing both and demonstrating how to use software to apply the solution. If hardware or services provide a key part of the solution, then also cover those in this section.>

Benefits

<This section identifies the benefits provided by the solution. Consider both value added directly in the form of increased revenues or cost savings, but also value added indirectly for example in organization agility, scalability, ease of maintenance, and so forth.>

About <Partner>

<This section describes you/your organization, and why others see you as an expert in this area. This section also provides your contact details.>

  • No labels