Platform (Service Inventory) Funding

This level of funding is focused on service inventory architecture and infrastructure. The intent is to establish an environment capable of hosting and enabling the runtime utilization of a collection of related services. One of the key factors here is that services need to be repeatedly leveraged as part of new and reconfigured service compositions.

Generally, the emphasis is on infrastructure components, such as service registries, ESBs, and various forms of service management frameworks. The important distinction is that this funding is not for the actual definition or creation of services.

There are three common platform funding models:

• Project Funding Model – This model identifies appropriate projects to acquire or to extend new or existing SOA platforms.
• Central Funding Model – With this model, the funding of the platform is provided centrally.
• Usage Funding Model – The initial platform is funded centrally but usage fees are charged for ongoing maintenance and support.

Let’s look at each model individually:

Project Funding Model (Platform)

This model calls for attaching platform costs to individual service delivery projects (Figure 1 and 2). With this approach, projects are required to purchase and implement (or upgrade) any new infrastructure components necessary to automate their planned services. These implementations are limited to the pre-defined scope of the service inventory architecture.

The project funding model enables a service inventory architecture to grow organically, based on individual project requirements.

Pros

• fits well with traditional, silo-based funding models

Cons

• high potential for conflicts with other projects that need to use platform resources or services funded by initial projects
• platform costs may inflate project budget
• project scope may not address service inventory-wide needs
• may result in unclear support and ownership requirements
• standardization issues may arise when different projects build upon a common platform

Although the simplicity of this model can be beneficial, it has several drawbacks. Despite this, there may be circumstances where a project funding model is the only option supported by stakeholders, primarily due to the familiarity of this model with traditional application development projects.

Central Funding Model (Platform)

The Central Funding Model entails funding all of the SOA platform build-out and growth activities centrally (Figures 3 and 4), as they apply to a given service inventory. The central funding source is established and used for new acquisitions, expansion of existing platforms and related maintenance and support efforts. This also includes any resources or labor required to effectively manage the platform and adjust it to accommodate the needs of new services and solution requirements.

Central funding allows an organization to establish an independent roadmap for introducing and upgrading SOA platforms because cost, scaling, and availability issues are no longer relevant to individual projects.

Pros

• covers the platform needs of an entire service inventory with no additional funding sources required
• high visibility into platform expansion, scalability, and usage needs
• highly predictable support and ownership model
• funding occurs independent of individual project demands

Cons

• it can be difficult to secure consistent and ongoing enterprise level funding
• more accountability for spending and budgets may be required to increased scope and responsibility

This model places increased emphasis on careful and diligent management in order to continually demonstrate how and where the funds went, while continuing to provide the necessary platform and infrastructure support for a growing service inventory.

Usage Based Funding Model (Platform)

This approach can be considered an extension of the Central Funding Model in that the platform builds out and expansion is still funded centrally; however, services and solutions that make use of platform resources are charged fees in order for investments to be recouped (Figures 5 and 6). The Usage Based Funding Model is especially commonplace when sharing resources via cloud environments. Depending on whether a public or private cloud is being used, usage fees may be charged by a central department within the organization or a third-party cloud provider.

Regardless of whether a cloud environment is being utilized, common types of fees can include the following:

• Entry Fees – These are standard one-time charges for new projects. These charges may be uniform across each service inventory platform or determined independently. Entry fees are typically calculated based on the general effort required to setup and support a new project on the platform, plus the prorated cost of the platform? portion being utilized.
• Per Use Fees – These charges are calculated using formulas based on unit costs and total fees for a predefined period of time. Total charges are based on the amount of units used within an invoiced period.
• Supplemental Fees – This approach allows a project to surrender a portion of its budget to address its needs. The more projects utilize a specific platform, the more funds it takes in to cover its build out, maintenance, support, and growth.

The following pros and cons apply to all forms of usage fees. Note that the pros and cons listed under the Central Funding Model generally also apply to the Usage Based Funding Model.

Pros

• can rapidly recoup the investment made in the platform
• charges are proportional to platform usage
• return on investment can be more easily demonstrated

Cons

• efficient and trusted chargeback mechanisms needed to monitor and bill for usage
• recovery of funds requires new billing processes
• improperly priced usage charges can deter projects from using platform resources