Policies, as related to governance, are declarative electronic rules that define the correct behaviors of the services. However, they can be rules that are not electronically enforced. An example would be policies created by IT leaders who create rules that everyone must follow, but the rules are not automated. Or, they can be policies that enforce the proper behavior during service execution, typically enforced electronically using governance technology. Both are important, and thus why we discuss polices as things that may exist inside or outside of governance technology.
For our purposes, we can call policies that are more general in nature macro policies, and policies that are specific to a particular service as micro policies.
Macro policies are those policies that IT leaders typically create, such as the enterprise architect, to address larger sweeping issues that cover many services, the data, the processes, and the applications. Examples of macro policies include:
• All metadata must adhere to an approved semantic model, on-premise and cloud computing-based.
• All services must return a response in .05 seconds for on-premise and .10 for cloud computing-based.
• Changes to processes have to be approved by a business leader.
• All services must be built using Java.
The idea is that we have some general rules that control how the system is developed, redeveloped, and monitored. Thus, macro polices do indeed exist as established simple rules, such as the ones listed above, or set processes that must be followed. For example, there could be a process to address how the database is changed, including 20 steps that must be followed, from initiation of the change to acceptance testing. Another example is the process of registering a new user on the cloud computing platform. Or, any process that reduces operational risks.
Many have a tendency to roll their eyes at these kinds of controls that are placed around automation. I'm sure you have many that exist within your IT shop now. They may also push back on extending these governance concepts to cloud computing. However, the core value of implementing macro policies is to reduce risk and save money.
The trick is to strike a balance between too many macro policies that hurt productivity, or too few that raise the chance that something bad will happen. Not an easy thing, but a good rule of thumb is that your IT department should spend approximately 5 percent of their time dealing with issues around macro polices. If you spend more time than that, perhaps you're over-governing. Less than that, or if you have disaster after disaster happen, perhaps you can put in more macro policies to place more processes around the management of IT resources, on-premise or cloud computing-based.
Micro or service-based polices typically deal with a policy instance around a particular service, process, or data element. They are related to macro policies in that macro policies define what needs to be done, whereas the micro policies define how a policy is carried out at the lowest level of granularity.
Examples of micro policies include:
• Only those from HR can leverage Get_Sal_Info services.
• No more than 1 application, service, or process at a time can access the Update_Customer_Data service.
• The Sales_Amount data element can only be updated by the DBA, and not the developers.
• The response time from the get_customer_credit service must be less than .0001 seconds.
Micro policies are very specific, and typically destined for implementation within service governance technology that can track and implement these types of policies.