No!
It's just that I've been brought up on "Component Modelling" (after the fashion of UML), with the strong belief that the CM approach makes application development and delivery so much more straight forward when the "lumps" are bounded, broadly independent, and focused on doing one or a few things well (encapsulated, loosely coupled and cohesive).
In other words, a component "owns" it's data and functionality, and uses its interfaces (or services!) to get the data and/or functions it does not have from other components (via their interfaces); thereby co-operating with other components in the application to deliver business value.
But we do not have to model in this way.
There was a time when Data Modelling and Functional Decomposition were popular analysis and development techniques for application development - and for the OMer such an approach means the "deployable functional parts" of an IT system are immediately obvious - using matrices and other mechanisms to explore what function needs which data, thereby lending themselves far more naturally to OM.
So in these non-component based cases, the various sorts of "functional lump" can be directly placed in the "operational viewpoint" without any manipulation - a data entity can be placed (and distributed) without confusion, as a Data Deployment Unit (DDU); as can an application (maybe with some negotiation between functional and operational designers if a client-server approach is adopted) as a EDU. Not only this, but also the functional viewpoint's data/function (CRUD!) matrices directly inform our needs for communication between DUs, and therefore the connectivity needs of the system. Sounds like OM nirvana!
No comments:
Post a Comment