[via McKinsey Quarterly]

Sometimes, also high-level business consultants are analysing *exactly* in the same way as we are doing that in the ecenter (is it good? ;-).

custom-built applications are still very much a part of the IT landscape. Companies in many sectors spend well over half their applications budgets on custom software, used largely to enhance, support, and operate customized systems. For large companies in competitive, fast-moving industries such as telecommunications, financial services, high tech, pharmaceuticals, and media, those outlays can run into hundreds of millions of dollars. […]

Some pioneering companies have found a way to capture the benefits of packaged software in a customized-applications environment. They have adopted the approach of software vendors, which package and sell applications aimed at the common needs of many customers rather than of individuals, by writing an application once and then selling it many times. In this way, pioneering banks and media and pharmaceutical companies have reduced the complexity and cost of managing applications and speeded up the deployment of new or updated ones. […]

A company can define the management of common elements among applications as standardized “products” designed to provide for the needs of many applications rather than one. Similarly, it can assemble new, custom-built applications from common, internally built modules of functionality and then reuse services developed by its teams to undertake common tasks such as authenticating users or accessing attributes of customers or products. […]

The IT and business teams involved in developing a custom application decide independently on the type and version of the applications tools and deployment environment it will use—the server, the database, the portal, and so on. Decisions about service levels (such as availability) and policies on data storage also are made ad hoc. Such applications end up as complex beasts to manage, typically requiring a host of maintenance and support processes as customized as the applications themselves. […]

In response to such problems, companies have tried to reduce labor costs by, for instance, offshoring the maintenance of applications and consolidating them in shared service centers. Consolidation improves utilization (fewer machines and people are needed) but rarely raises the productivity of IT maintenance, because the diversity of maintenance and support activities doesn’t go away. Similarly, offshoring can reduce per-hour labor costs, but companies (either in their captive offshore centers or their outsourcing vendors) typically do little to reduce the underlying diversity in the maintenance processes for applications. […]

A company may have thousands of applications, but we’ve found that, for most organizations, they can be clustered into fewer than a dozen archetypes—our term for applications grouped by their key commonalities. Archetypes naturally vary by company. […]

Today companies bring some order and standardization to the process by using Internet-based service-oriented-architecture (SOA) standards.2 These IT advances help companies to codify business functionality in ready-to-use software building blocks much more easily and quickly, to scale up the kinds of functionality suitable for reuse in applications, and to ensure that such building blocks are employed more effectively across project teams and organizations—and maintained in a more standard fashion after an application has been deployed. […]

For early adopters, the benefit that really counts is a reduction in the time needed to develop an application: they are finding that they can roll one out 20 to 40 percent faster when they use common applications products. Furthermore, the reduced expense could eventually allow companies to leverage the advantages by using easy-to-assemble applications to test new business strategies. If the strategies work, the companies can scale up the applications; if they don’t, little has been lost, because such applications are inexpensive to build and easy to discard. […]

The following lessons from early adopters:

• Build the products “prospectively,” mindful not just of the existing base of applications but also of future needs.
• Organize groups to deliver products effectively against business needs and not just technology outcomes.
• Pay attention to organizational factors that will ensure proper governance and realize the business benefits.