 |
| David Cuykendall Click for Index Page |
The intensional meaning of a system is the meaning that includes all of a system’s functions, characteristics, qualities, and implications. In other words, a system's intensional meaning is the "proposition," in totality, a system presents to all of a system's stakeholders collectively. A system’s intensional meaning could be defined by ALL possible views of a system taken together. Examining these views in detail (which includes the entire technological solution stack that enables the system) makes apparent WHY systems are so costly.
It crucial to understand and it bears repeating; most systems are delivered without detailed validation of what the value add is going to be. A host of process implications (management overheads) are imposed on your business, without detailed assessment of the costs and benefits of each additional process involved.
Part of a system's intensional meaning rises from system designers and developers focused on how to split and map system functions onto architectural contexts (a modeled separation of functional concerns) to reconcile the needs of the real world domain they aim to serve. Their aim is optimization within the paradigm of information technology — a paradigm that includes a lot of dependencies and is structurally relatively frozen and inflexible.
On a lower, hands-on level, they are merely trying to fit the controlling concepts embedded in their design and development tools onto a domain. They have no guides except the inexactitudes of requirements engineering, user stories, the communications perspective of their clients, the biases of domain experts, and strategies for coping with requirements volatility.
System designers and developers recognize that a gap is inevitable between the models embedded in their products and the actual needs of a business domain. They work to close the gap. Nevertheless, they expect users to work within the constraints of a system’s overall intensional meaning. It is an expectation they charge for, and it is part of their business model. The business services offered in information technology assume business needs that may not exist and ignore business needs that may exist, meaning a system may serve aspects of worlds of no concern to a business's actual business needs. These failures are particularly true of the core business domain of a business where most of a business's bespoke requirements exist.
Moreover, a system's customization features that purport to address the problem of the non-alignment of a system with business needs merely extend the social-technical paradigm of a system. Systems are almost always mismatched with business needs, their customization features and so-called “platform services” notwithstanding. Process pipelines are shoehorned into a frozen social-technical paradigm; it is the constrained social-technical conceptual paradigm that governs, rather than straightforward business needs. Contrivances are forced to fill the gap. Or worse, the gap remains unfilled.
