Software Product or Business Application?

Every technology request raises a modeling question that most portfolios answer by accident: does this become a software product record, a business application, or something else? Get it wrong and the damage is quiet. The application count inflates, rationalization starts treating platforms as if they were apps, and contracts and licenses have nothing to attach to.

Two records, two questions

• A software product record describes what the vendor ships. Licenses, installations and contracts point to it.
• A business application describes what the business uses to get an outcome. Owners, capabilities and dispositions live on it.

Every approved software acquisition gets a product record. Only some of them get a business application. The whole problem is knowing which.

The rule, in six questions

1. Are we getting, installing or subscribing to a software product? Then it needs a product record, unless one already exists. SaaS and free tools included.
2. Does it deliver a business outcome to business users, not to other IT teams? Then it needs a business application, unless one already exists.
3. Is it a platform other IT teams consume: backup, compute, network, identity, a container platform? Then it is a technology service, not a business application.
4. Is it a Dev, QA or Production copy of an application you already have? Then it is a service instance under the existing application, not a new one.
5. Is it a module of a bigger application? Then it is a component of the parent.
6. Is it a single-user or temporary exception? Then it gets a product record only, marked as an exception.

Check what exists through the request, not the name

"Unless one already exists" is where most mistakes happen, because people check by product name. Name searches fail constantly: a small utility gets filed under what it does rather than its brand, and a vendor renames a suite, so a request for the old name finds nothing even though the current product has been certified for years. Check what the request itself references first, then the product record, and only then the name.

The patterns I see most

• Platforms registered as applications. Backup, container and server platforms entered as business applications inflate the portfolio, skew rationalization, and attract business impact analyses meant for business apps. Their resilience belongs to the platform owner.
• Environments registered as applications. One integration running in three environments became three applications, each with its own owner and disposition.
• Tools in use with no decision about their future. A tool that predates the process gets registered with no disposition. Grandfathered is not undisposed: register it with a disposition, Tolerate until the next renewal by default, or Migrate with the target named.
• Certified products with no manufacturer. Certification without a manufacturer means licenses and contracts cannot reconcile. Make the manufacturer required before certification.

Decide at review, not at fulfilment

The architect decides which records a request produces during the review and writes the decision down, so fulfilment creates the right records instead of guessing. When a business application is needed, create it at approval as pre-operational, with a target go-live date. Ownership and capabilities are then set before go-live, not reconstructed after it.

Every approved acquisition gets a product record. Only a business outcome earns a business application.

Copy this: the record rule

## Which record does a technology request produce?
Decide at review. Write the decision and the reason on the request.

1. Software product we get, install or subscribe to -> product record
   (unless one exists; SaaS and free tools included)
2. Business outcome for business users            -> business application
3. Platform consumed by other IT teams            -> technology service
4. Dev / QA / Prod copy of an existing app        -> service instance
5. Module of a bigger application                  -> component of parent
6. Single-user or temporary exception              -> product record only

- Check "already exists" via the request's references first, name last.
- Create the business application at approval, pre-operational, with a
  target go-live date. Owner + capabilities set before go-live.
- Grandfathered is not undisposed: register with a disposition.
- No certification without a manufacturer.