Introduction

When people talk about common solutions, you probably start thinking about a few specific technologies right away. A few examples of the ones most often thought of are Java, .NET, Oracle and Documentum. While it’s true these technologies can be used to implement common solutions, it’s not quite as easy as it sounds.
Here at Blue Fish, our experience with clients and our own independent analysis has led to the conclusion that there are at least three different types of common solutions. These types, or approaches to building a common solution, highlight differences in how common solutions are built, deployed and maintained. This article will explain the three different approaches we’ve identified and present a model we’ve developed to help you select the right approach for your common solution.

Understanding the Different Approaches to Common Solutions

The three approaches we’ve identified are specifically targeted at enterprises with departments, divisions or business units large enough to make their own IT decisions. This generally means they’re also large enough to create custom solutions to address their specific needs. The goal is to find a common solution across these departments that both meets their unique needs and minimizes development, deployment and support costs.
In this environment, identifying the right approach to a common solution is critical. Implement a common solution that doesn’t provide the flexibility departments need to support their unique business processes, and they won’t adopt it. Deliver a common solution that requires significant department specific customization to be useful, and you’ll end up with a bunch of department specific solutions that don’t look very common to your support and maintenance teams. These outcomes highlight the need to understand the different approaches to common solutions and the importance of selecting the right one for each enterprise solution.
It’s important to note that it will very likely make sense to use different approaches for different enterprise solutions. Organizations can successfully implement one approach for their enterprise accounting solution but may need to use a totally different approach to achieve the same success for their enterprise content management system. Since most of the solutions Blue Fish builds for our clients are built on Documentum, I’ll focus on Documentum based solutions for much of the article. However, the reality that there are different approaches to a common solution and the model we present for selecting the right one applies to many other technologies and solution domains.
So, let’s dive right in and talk through the three different approaches.

The Configurable Solution Approach

The ‘Configurable Solution’ approach is what most people think of when picturing a common solution. It’s the archetypal common solution because technically it is the same solution for everyone. This approach gives everyone the exact same technology solution, but then presents a few, well defined configuration points that enable departments or users to tailor it to their needs. All requests for new or modified functionality are reviewed, consolidated and implemented by a central group that owns the solution.
One great example of a configurable solution is Microsoft Word. It’s the same technology solution installed the same way throughout your organization. However, each department or individual user can configure Word to best suit their needs.

For example, departments can create their own templates and macros to support their business processes. Individual users can organize the toolbars and configure the interface to help make them more productive. In our example, the central group that owns this solution is Microsoft. If you need new functionality that Word doesn’t provide, you can’t just go change the code yourself. You have to find a way to get that need on Microsoft’s radar and hope that it makes it into the next version.
Similar to Microsoft Word, Documentum can be deployed as a configurable solution. Out of the box, Documentum comes with all the features necessary for a basic content management system. You could use the default object types and configure your users, groups, roles and security using the out of box capabilities, and be up and running with no customization whatsoever. However, we’ve never seen Documentum deployed that way. Here at Blue Fish, we’ve been helping clients deploy and integrate Documentum for over nine years, and have never deployed it completely out of the box. That said, with each release Documentum moves closer to a completely configurable solution. For example, Documentum 6 added several new configuration points for scoping what menus, templates and other object types are visible to a particular user. This was a common type of customization in the past. Some day, Documentum may achieve the goal of providing a completely configurable solution, but for now some level of customization is almost always required.

The Customizable Platform Approach

The ‘Customizable Platform’ approach is the default way most organizations build common solutions. This approach leverages a core of commonality to build a starter kit of sorts. With this approach, the common solution isn’t complete by itself, but rather provides departments with the “80% solution” they can use to build the solution they need. A central team owns and maintains the core platform, and each department is free to customize this platform as they see fit. The central group isn’t necessarily involved, or even aware of the department specific customizations.

Just like Linux, Documentum can be deployed as a customizable platform. EMC expects their customers to extend and customize Documentum, which is why they invest so much in developer tools like WDK and DFS. EMC understands that Documentum can rarely be deployed with configuration alone. The vast majority of Documentum customers use it as a customizable platform by customizing core functionality such as the user interface. Unfortunately, in large enterprises you often find individual departments customizing the platform to meet their specific needs. Over time, the department specific customizations grow further and further apart, and the enterprise ends up with multiple individual solutions that, although they share a common platform, don’t look so common to your support and maintenance teams. This is how many efforts to implement a common enterprise content management system fail. A company buys Documentum thinking it will be common in the way Microsoft Word is common, and they don’t plan for the necessary level of development and support.

The Extensible Framework Approach

The ‘Extensible Framework’ approach provides a set of components and tools that enable departments to assemble focused, complete solutions that meet their unique needs. This approach leverages techniques from both the ‘Customizable Solution’ and ‘Configurable Platform’ approaches to provide users with the ability to assemble exactly what they need, but prevents the expense of divergent solutions by enforcing standards. The standards define basic rules for assembling a solution, documentation for how components interact with the core framework and the specification that new components must align to in order to operate with the framework. Using this approach, departments assemble exactly what they need from an existing set of components. If the functionality they need is not provided by an existing component, they can use the provided specification to create a new component to plug into the framework.

Similar to Firefox, many components of the Documentum platform can be deployed as an extensible framework. Documentum components such as lifecycles, workflows and the Business Object Framework (BOF) provide the ability to extend the core platform without creating custom builds. However, it’s important to note that the entire Documentum platform cannot be directly deployed as an extensible framework. Many components, such as the user interface, do require the creation of customized builds in order to deploy changes. This doesn’t mean Documentum can’t be deployed as a 100% extensible framework; it means that you must invest in design and development to create your own extensible framework for the components that typically require customization. Once you decide to do this, you can build an extensible framework that will enforce enough consistency across solutions to drive down support costs. Because this solution approach will provide extension points that enable departments to build their own components, each department can construct a solution that meets their needs. For example, you could construct a configuration driven, rules-based Documentum framework that uses services to perform tasks such as document numbering, document filing, lifecycle event management and security definition. These core services are shared and any department can plug them in to their solution if they meet the department’s needs. However, if a department needs to number their documents according to a different standard they can implement their own document numbering extension, and plug it in to their solution. The custom extension can then be shared with other departments who may have similar requirements. Because the new extension aligns to the extension framework standards, other departments will be able to plug it into their solutions in a predictable, repeatable way.

Comparing the Approaches

Now that we understand the three models, there is one more important concept to discuss: governance. Applying the appropriate governance model is critical for driving value out of a common solution and governance boils down to one key thing. The way you manage and support differences, or business process exceptions, within your solution is the most important aspect of governing a common solution. We’ll discuss governance in more detail in the next section. For now, the following table sums up the three solution approaches we’ve discussed so far, and provides some initial insight into the characteristics of an effective governance model for each approach.

Selecting the Best Approach for Your Organization

Understanding the different approaches is half the battle. Unfortunately, it’s the easy half. Identifying and successfully implementing the most appropriate approach for your situation is the real challenge. Do this well and you can drive down solution development and support costs while protecting, and even enhancing, the competitive advantages built into your business processes.
So how is the savvy CIO supposed to select the appropriate approach that fits his/her unique business? Our experience tells us that it mostly boils down to solution governance. But governance doesn’t just mean locking down the system and forcing all changes through an authoritarian change control process. As the table above hinted at, there are different ways to govern your solution. The key thing to understand is that no single governance approach is always right or always wrong. Depending on your organization’s size and governance capabilities, one may be more appropriate than another and ultimately this should impact the solution approach you select.

A Governance Based Selection Model

Below, Figure 1 depicts a model we’ve developed for helping select the right approach to your common solution. The model measures the amount of business process commonality in the departments that will use the solution on the X-axis, and the number of times the solution will be implemented (i.e., instances of the solution) on the Y-axis. This is not a quantitative model. There is no discrete amount of commonality or number of instances that should move every business from one approach to another. A thoughtful analysis of your business and an understanding of your roadmap for the future can’t be replaced by any model. However, this model will help you think about the most important drivers for selecting the right approach to your common solution.

Figure 1:
Our selection model leverages a governance-based approach to analyze the number of solution instances within your organization and the amount of business process commonality across those solutions.

We view this model as governance-based because measuring the amount of business process commonality is another way to look at the number of exceptions to that commonality that are present in your business; the more commonality, the fewer exceptions and vice versa.

Managing Exceptions

I introduced the concept of exceptions in the table that summarized the three approaches to common solutions. Let’s define exactly what an exception is so that we can discuss their importance in selecting the right approach for a common solution.
Exceptions are essentially the inverse of business process commonality. Let’s use the business process of creating, reviewing and approving purchase orders to identify a specific example. Assume that your hard working team of analysts has defined a standard purchase order process to be used across your enterprise. However, one business unit isn’t able to implement that process exactly because of a specific requirement with a key supplier. They can use the majority of the process as-is, but must make one key change to support integration with their primary supplier. This change to the standard purchase order process is an exception.
A typical goal of business process standardization is the identification and elimination of exceptions. For some common solutions, such as your accounting system, word processing technology or desktop operating system, this is an achievable goal. However, other common solutions, such as Content Management systems, are more likely to contain exceptions that business units will want to be supported. Regardless of the specific solution, new exceptions will be discovered throughout the lifecycle of the solution. New business units with new requirements will come online and adopt the solution; your business processes will evolve to adapt to a changing market; there will always be new exceptions, and therefore it is critical that you have a plan for managing them.
The process used to identify, evaluate and ultimately decided how, if at all, to support exceptions is one of the most important aspects of successful solution governance. As we discussed when describing the different approaches to common solutions, each approach requires a unique governance model.
Let’s look at each approach individually. As we discussed earlier, the ‘Configurable Solution’ approach typically requires high business process commonality across your organization. This is because the ‘Configurable Solution’ approach generally supports the least number of process exceptions. The governance required to support this type of solution must be centralized and empowered to challenge the nature and value of exceptions that are brought forward for implementation. Otherwise the central team will be swamped with changes and the ‘Configurable Solution’ will quickly suffer from feature bloat.
On the other hand, the ‘Extensible Framework’ approach requires this strong, centralized governance only for the core framework and the standards that define how components interact with that framework. This core framework and set of standards will change far less often than a complete, configurable solution. By distributing the capability to extend the core framework through well defined components, the central team significantly lightens the load on their governance responsibilities.
Similarly, the ‘Customizable Platform’ approach requires relatively little governance compared to the ‘Configurable Solution’. Exceptions are directly built into the individual department solutions through their own customizations. The central group that owns the core platform is responsible for making changes and extending that platform. Because each department is free to customize their own solutions as they see fit, the departments aren’t required to go through a formal governance process to implement the features they need.

A Detailed Example

Let’s use an example company, Acme Inc., to look at how this selection model is applied.
Acme, Inc. is a large, distributed enterprise with many divisions and departments that require content management. Acme is looking for a way to meet the diverse needs of its business units at the lowest total cost. Acme has selected Documentum as their common technology for content management and now needs to decide how to roll it out to the many divisions and departments across their enterprise.
Acme’s CIO has decided that initially, this common content management solution will only be used to store and manage business critical documents required to support regulatory compliance. Additionally, all implementations of the common solution will standardize on Documentum’s Web-based interface to minimize differences in the way users access and interact with the solution. This is beginning to sound like a relatively standardized solution, right? Might be a great candidate for the ‘Configurable Solution’ approach you say? Not so fast! Let’s take a closer look.
As we’ve said, Acme is a large, global enterprise. They’ve grown to their present size through a series of strategic acquisitions over the course of several decades. While there are only a few distinct lines of business across the organization, the business units within each of these business lines are scattered across every region of the globe. Further, each of these business units have their own unique history and, to a certain extent, culture. The business units themselves are also generally large enough to make their own IT decisions and implement their own custom solutions. There appears to be a great opportunity to drive standards and reduce costs through a common solution.
Using the selection model presented in this article, Acme creates an initiative to analyze the two key dimensions of the model:

1. The number of business units, departments and divisions that will implement the common content management system
2. The amount of commonality in the business processes used to support the generation and management of regulatory compliance documents

The number of implementations is relatively easy to determine. Acme has 50 business units around the globe with as many as 10 different departments within each business unit. Ultimately, there will be several hundred unique departments using the common solution.
The amount of business process commonality is more difficult to measure precisely. However, Acme realizes that there are significant differences in the regulations and compliance laws across the many regions where their business units operate. While the basic process of generating and managing compliance documents can be abstracted to look common, the details are often different enough that many, legally-required exceptions begin to materialize.

How do we know Acme arrived at the right answer for their common solution? What does Acme need to do to make sure their investment in a common, extensible framework has a positive impact on the overall business?
If Acme had not used the selection model and simply decided to use the ‘Customizable Platform’ approach they would have quickly experienced a maintenance and support nightmare. By building only the customizable platform of the content management system, each individual business unit or department would then be responsible for customizing that platform to address their specific requirements. With several hundred departments to come online, the core platform support organization would eventually have to worry about several hundred unique solutions each time an update to the core was ready to be released. This situation would almost certainly overshadow any benefits gained from sharing a common core platform. For this reason, the selection model only recommends the ‘Customizable Platform’ approach when the total number of instances, or implementations, is manageably low.
Had Acme decided that they could manage the regulatory difference across the regions, they could have selected the ‘Configurable Solution’ approach. However, this would require that a central team identify and drive out enough exceptions to achieve a high level commonality in their compliance document management business processes. For Acme, achieving that level of commonality may not have even been possible as many of the process differences are driven by regulatory statues that are non-negotiable. Additionally, because the ‘Configurable Solution’ approach requires a central team to manage the initial implementation and all subsequent changes, all the process variations would have to be identified and implemented as configuration points by the central team. The team will certainly miss a few necessary configuration points with the first release. Additionally, some of the configurations will almost certainly need to be refined or corrected. Every department will have to wait in line for the central team to address their specific need before they can use the solution. Depending on the capacity of the central team, the departments could end up waiting so long that they give up and implement a custom solution themselves. The entire strategy of a common solution is lost once departments abandon the common solution in favor of their own custom solution.
By selecting the ‘Extensible Framework’ approach to their common solution, Acme has positioned their common solution for success by defending against two threats:

1. Mass solution proliferation of customized versions of a common platform
2. Low adoption of a configurable solution delivered by a capacity constrained central team

To be successful with their extensible framework, Acme must understand and plan for the up-front development investment that is required and must implement an effective governance process. The up-front development will focus on building the core framework and the interface between it and extensions developed by business units and departments. The governance model must ensure that the core framework is not customized when deployed and that extensions align with the standards and are shared across implementations.

Summary

If you take nothing else away from this article, remember that there are different types of common solutions. Whether it’s the ‘Configurable Solution’, ‘Customizable Platform’ or the ‘Extensible Framework’ approach, selecting the right type of common solution is a critical first step on the road to a successful implementation. From there it’s on to the fun part; designing and building the common solution that fits your organization like a glove.