More on the 'P' word - back to basics
Following up on
Neil's post about policy, I thought it was making a single point about whether or not the concept of "policy" could be in or out of vogue. Its a simple enough point, but one that took me years to work out - that a policy defines a set of rules. However the term "policy" is defined for whatever situation, but this principle should underly any definition.
So, for example, the statements "It's not business policy to allow that" or "we have a data retention policy of 30 days" both map back to simple rules that determine whether the policy is to be applied or not - then what to do about it.
I don't want to underestimate the complexity of business situations, but I do want to acknowledge that the building blocks, the central concepts are quite straightforward. I believe there are four fundamental concepts in any business or IT situation, all of which are related:
- policy - sets of rules to be applied by the business
- entity - what the business sees as the "things" it deals with
- service - things that can be requested of the business
- process - concatenations of activities to support service delivery
(there might be 5 - if you want to add state - but this is also about the relationship between entity and process so it can be derived from the above)
We can dress these up in whichever terminology is in vogue, but to say they should or shouldn’t exist is tantamount to saying that atomic particles shouldn’t exist - they'll still be there, whether we want them to be or not!
Given that enterprise IT exists purely to automate business models (another simple, yet fundamental principle), it follows that there are IT equivalents of the above, and that they are mappable one to the other. Any shortfalls between the mappings are more an indication of our failure to deliver IT in a way business needs it, than anything.
