May 2014 – In Search Of

In my last post on Software Capabilities and Feats I said that feats are better [to model in a software capability] than processes, because processes are merely organized, consistent, managed ways to accomplish the feat.

A process is one way to accomplish a feat. The feat is the result you want.

Process is constrained by capabilities. So when I am modeling new capabilities, I should not be constrained by existing capabilities. When I introduce the new capability into the wild, the process will need to “re-form” around the new capability.

A process has steps. If we build software capabilities to support a process, we treat the steps of the process like “feats”. I can model a capability to make that step faster or more effective. That assumes that the step is necessary. In order to decide whether a process step is “necessary” I need to understand how it contributes to the valuable result. I need to understand why I do the step.Continue Reading

In some recent conversations, I find that it is hard to explain the notion of a capability. People want to talk in terms of software features or project requirements.

Software capabilities define value in the following ways:

enabling the user to accomplish a “feat” in less time than they otherwise would.
enabling the user to accomplish a “feat” at a greater scale than they otherwise would.
enabling the user (or a group of users) to accomplish a “feat” more effectively than that they otherwise would.
enabling the user to accomplish a “feat” that he could otherwise not accomplish at all.
enabling the user to accomplish a “feat” better than he otherwise could.
enabling the user to focus on “feats” that require decisions, rather than repetitive steps.

Every other benefit of software can be composed from these.

To define value, a software capability must contemplate (model) the “feat” that the user wants to accomplish.Continue Reading

Articles from May 2014

Feats Instead of Processes

Software Capabilities and Feats