How to Classify Software Application Components: A Complete 2026 Framework

A practical, standards-backed system for sorting components by function, layer, runtime, and license — built from ISO/IEC, IEEE, ArchiMate, and the C4 model.

By Oyekale Olawale · Updated 2026

I rebuilt this framework after watching a client’s “simple” component inventory collapse under its own weight — someone had classified a shared auth library by what it did, someone else by where it ran, and the two systems couldn’t talk to each other. Below is the version that survived contact with an actual codebase.

What Software Component Classification Actually Means

ISO/IEC’s systems and software engineering vocabulary defines a component as a discrete, independently deployable unit considered at a particular level of analysis. That’s a formal way of saying: it has a boundary, and you can swap it without rebuilding everything around it.

Bertrand Meyer’s four orthogonal viewpoints are still the cleanest lens I’ve found for sorting components without forcing them into a single bucket. “Orthogonal” is the key word — you apply all four to the same component at once, because they answer different questions.

If you’re auditing a legacy system, this table alone will surface most of the mismatches — the components that were classified by one viewpoint but are being managed as if they belonged to another. If you’re weighing whether to bring in an outside team to rebuild the mess, this is exactly the inventory you hand them first.

Application Layer vs. Technology Layer

I think of an application the way I’d think of a body: organs that do the work, and a nervous system carrying signals between them. ArchiMate — The Open Group’s enterprise architecture notation — splits this formally into two layers.

A closely related split worth keeping separate in your notes: logical vs. physical. The logical view is the “what” — the shopping cart’s business rules. The physical view is the “where” — the specific cart_service.py file or the container it runs in inside Docker. Conflating the two is how teams end up with a component diagram that describes an architecture nobody actually deployed.

Application Software vs. System Software

Zoom out from individual components and you’re classifying whole application types. System software — operating systems, drivers, utilities — manages the hardware and serves the computer, not the user. Application software is split further:

• Horizontal applications — general-purpose tools like a browser or spreadsheet app. They work everywhere, for everyone.
• Vertical applications — industry-specific systems: hospital management platforms, banking CRMs, parking-lot management software.

Automated classification is getting genuinely good at the requirements level. A 2025 study using the PROMISE dataset — a widely cited repository of real software project data — reported an F1-score of 89.2% when using transformer-based models to separate functional from non-functional requirements automatically. Sandia National Laboratories’ decision-tree work for malware categorization, using system-call and cyclomatic-complexity signals, hits over 95% accuracy. Neither number replaces a human doing the final call on ambiguous edge cases — but both are worth knowing before you assume manual tagging is more reliable than it usually is.

My 7-Step Framework for Classifying Components on Real Projects

This is the version I actually run, expanded from a simpler four-step process I used to teach. The extra three steps exist because the short version kept letting licensing and ownership questions slip through.

1. Define the boundary. Is this a single function or a whole subsystem? If moving it breaks three other things, your boundary is drawn in the wrong place.
2. Analyze coupling. Trace the dependency graph. If Component A can’t survive Component B moving, they aren’t two components — they’re one component pretending to be two.
3. Determine the runtime. Static (compiled in) or dynamic (loaded at runtime)? Microservices are dynamic by definition. Embedded C is almost always static.
4. Assign ownership. Which team can change this without a cross-team meeting? Components without a clear owner are the ones that rot fastest.
5. Check the license. Pull the SPDX identifier if one exists. If it doesn’t, that’s a finding in itself — undocumented licenses are a legal risk, not a technicality.
6. Validate against a notation. Draw it with the C4 model — Context, Container, Component, Code. If you can’t place it in the hierarchy, you don’t actually understand the boundary you defined in step one.
7. Record it somewhere durable. A spreadsheet, a Structurizr workspace, an internal wiki page — anywhere that survives the next reorg.

Classification by Licensing: Where Technical Sorting Meets Legal Risk

You can classify a component perfectly on every technical axis and still end up in a legal review if you ignore the license. This is also where SaaS teams managing continuity and compliance risk most often get surprised — an AGPL dependency buried three layers deep in a microservice can force disclosure obligations nobody signed up for.

Where This Actually Matters: Security, Legacy, and IoT

Security and SBOMs. Sandia’s classification research feeds directly into malware detection — components exhibiting high cyclomatic complexity combined with specific system-call patterns get flagged automatically. This is also the same logic behind Software Bills of Materials, which regulators increasingly expect: knowing exactly which components you ship, and how they’re classified, is the difference between patching a known vulnerability in an afternoon and discovering it during an incident.

Legacy integration. Classifying by abstraction level (Meyer’s framework again) tells you which components are stale specs and which are live, running code — a distinction that saves teams from rewriting the wrong layer entirely. If you’re weighing an AI coding assistant to help untangle a legacy codebase, feed it this classification first; it dramatically improves the quality of what comes back.

IoT. The IEC 60050 vocabulary defines an IoT component by whether it has event sources and event sinks — a control interface. Without one, it isn’t an IoT component; it’s just a data feed wearing an IoT label.

Tools That Actually Support This Work

You don’t have to do all of this by hand. A few categories worth knowing, based on what I’ve actually run against production codebases:

• Static analysis / dependency mapping — dependency-cruiser, Madge, and similar tools build the coupling graph step 2 needs. Expect to spend real time tuning path-alias resolution before the output is trustworthy.
• SBOM generation — tools implementing the CycloneDX or SPDX formats will pull license metadata automatically from your package manifests, though private or vendored packages still need a manual pass.
• Architecture visualization — Structurizr and similar C4-model tooling force you to classify as you diagram, which catches boundary mistakes early. The learning curve is real; budget an afternoon before your first workspace looks the way you want it to.

Tool assessments above reflect my personal testing and workflow, not an official partnership or paid placement. Behavior varies by version — verify against current vendor documentation before making a decision for your team. This isn’t legal, financial, or professional software-licensing advice; for anything with real legal exposure, talk to counsel familiar with software licensing.

FAQ

What’s the difference between a module and a component?

Mostly deployment. A module is a logical grouping of code inside a single binary. A component, by IEEE’s definition, is discrete and independently deployable — it can be swapped without rebuilding everything around it.

Why does my classification system keep breaking?

Usually because two viewpoints got mixed. You can’t classify a login button (a UI element) using a database connector’s (infrastructure) standard. Pick one viewpoint at a time and stay consistent with it.

Can AI classify components for me?

Partially — modern transformer models hit around 89.2% F1-score on requirement classification. That’s high enough to speed up a first pass, but a human still needs to validate the ambiguous edge cases before you commit to a taxonomy.

Do I need an SBOM even for a small project?

If you ship to anyone outside your own team, yes — even a lightweight one. It’s far cheaper to generate at build time than to reconstruct after the fact when a dependency turns up with a disclosed vulnerability.

Conclusion

Classifying components isn’t paperwork — it’s risk management wearing a boring hat. Lose track of it and you lose track of licensing exposure, security blind spots, and eventually the architecture itself.

I keep three tabs for every project: Abstraction (“what does it do?”), Licensing (“can I legally ship this?”), and Runtime (“when does it actually run?”). It takes about an hour to set up and saves days of debugging confusion later.

Start with the ten components you touch most often this week. Run each through all four Meyer viewpoints, check the license, and write it down somewhere that will still exist in six months. That’s the whole system.