Cataloging your applications to get rid of those you don’t need makes so much sense it’s easy to forget how hard it can be to build such a portfolio. Here are six rules for simplifying your portfolio so you can cut costs and align your spending with your business needs.
Rule 1: Keep it flat
Avoid defining applications as hierarchies of the same type of component, such as “applications within applications.” These hierarchies fail to clearly capture the key differences and similarities among applications, such who owns which application, what business processes it supports and its dependencies on other applications. It is these details that tell you which applications are most critical and which you can junk. This approach also leads to confusing and inconsistent application counts.
If you really need to inventory groups of similar applications, represent the “parent” and “child” applications as different types of components. In the example below, the parent component is a “Logical Application” which refers to all the instances of SAP an organization owns. The child components are the instances of SAP that serve specific geographies. (Such child components could also be broken out by the business function they serve, the department they serve, or any other meaningful criteria.) The point is to end up with an accurate count and description of your applications so you can begin optimizing them.
SAP Worldwide – Logical Application Type
SAP (EMEA) – Application Type
SAP (APJ) – Application Type
SAP (Americas) – Application Type
Rule 2: Use common sense in naming
You probably own multiple instances of an application because they serve multiple sites, business units or types of users. Why not name them according to those divisions? That helps you identify both the differences between them (such as version and supporting infrastructure) and the commonalities they share (such as which IT unit supports them.) One obvious example is:
- Shipping (Factory in Utica, NY)
- Shipping (Factory in Chengdu, China)
- Shipping (Factory in Dresden, Germany)
Using the proper naming standard can pave the way for analyzing if they’ve been deployed in the proper, consistent way using a tool like our own Troux Standards.
Rule 3: Break out big packages based on infrastructure
How do you catalogue a massive software package (think SAP or Oracle Applications) with a ton of optional modules? First, follow our rules (above) to define the components in a flat hierarchy and to use common-sense naming conventions. Your next step depends on how they are deployed.
If the package relies on one large, dedicated infrastructure and is managed as a single unit, capture it as a single application instance, even if its components serve many business functions and processes. But if you have multiple deployments of the package, each on a separate infrastructure and used by a different business unit or geography, define separate instances along the lines of their supporting infrastructures. For example:
- Oracle Apps (Accounts Payable)
- Oracle Apps (HR)
- Oracle Apps (Corporate Accounting)
Rule 4: Watch Your Semantics
We often find application portfolios that contain a lot of things that are not applications at all, but are related technologies, projects, and even processes. This, of course, makes it almost impossible to maintain a common, straightforward model of the application across the portfolio. For example, “Oracle Backup” might mean a database instance, a server devoted to backup, a storage volume or even the rules governing the Oracle backup. Using a Semantics model, like the one we provide, can save you from reinventing the wheel by creating your own definitions. Use an established definition and move on with the important work of cataloguing and then prioritizing your apps.
Rule 5: Separate Out Middleware/Infrastructure Applications
If an “application” is really middleware, categorize it as such. Examples include Enterprise Application Integration platforms or an SOA (service-oriented architecture) platform that aggregates common business logic, provides data as services, or abstracts common application functions. Because these applications are “plumbing” that support multiple business functions, architects sometimes get bogged down in trying to define all their dependencies up-front. Instead, simply identify them as “interface” or “middleware” applications that require cost and support. It is obviously important to capture which business applications depend on each infrastructure application, but don’t try to capture every detail unless the infrastructure automates that process. The run-time environment can often supply the specifics if you really need them.
Rule 6: Don’t Let Clouds or Virtualization Muddy the Water
Just because an application moves dynamically among servers, or server farms, in a virtualized cloud doesn’t mean you can’t, or shouldn’t, define it carefully. Even if you can’t tie it to a specific physical server in your data center, there are probably stable application elements, such as the business process it supports or its owners, you can define it by. Not matter how vague their physical presence may be, these applications cost something to run and need to be listed in your portfolio so they can be evaluated for their importance.
There will always be special cases, complexities and curve balls as you define and evolve your application portfolio. But when in doubt, remember the aim is to understand how the portfolio applies to the business, and what each element in it costs. Don’t get distracted by the universe of modeling possibilities until the basic application portfolio has been captured and provides the guidance you need.