If "governance is not so much a question of 'why,' but rather about 'how' and 'when' ", let me ask what does mean compliance with governance? IMO, governance is a mechnaism that transforms 'why' into 'what', 'when', 'where', 'who' and 'whom for'.
'How' is for the management. It is the manager who realises the governing controls, collects results against metrics defined by the governance. Manager has to have certain freedon in 'how' to apply governing policies and ... become compliant with them. Governance is not about 'how'. - Michael ________________________________ From: Gervas Douglas <[email protected]> To: [email protected] Sent: Sun, August 15, 2010 11:06:20 AM Subject: [service-orientated-architecture] Karas on Governance <<As any architect will attest, governance is not so much a question of 'why,' but rather about 'how' and 'when.' More specifically, conversations and debates usually focus on how much governance is really necessary, as well as when and where to apply it. Now, three initiatives are bringing a lot of these conversations to the forefront: cloud computing, SOA and mainframe modernization. There are similarities in the way governance is approached in each of these categories. Each is intended to break down silos, protect and preserve the integrity of information, and provide IT with more agility to create business value. As more applications and services are exposed and potentially proliferate throughout the Web and across composite applications and services, the greater the risk associated with access and reuse of these technology assets. This gap will continue to widen as more products and services are introduced and integrated. As the infrastructure continues to evolve, there will be a demand for improved transparency due to the higher likelihood of policy violations and coding errors. Yet, governing those assets as they evolve with the infrastructure can be tricky in terms of responsibility and ownership. That's because it's hard to clearly define the boundaries of an application or service once its used by different teams. This becomes increasingly more complex once an application or service is tweaked to address a specific business need; more changes to the software increase the vulnerability of coding errors if governance is not appropriately applied. Applying governance after the horse has left the barn can often be difficult and somewhat ineffective. In this context, governance is regarded as a tactical effort focused on tools and functions within the infrastructure, as opposed to a more strategic initiative designed to align technology with the company's larger business goals. There are several reasons, or excuses, as to why governance sometimes takes a back seat in the overall IT strategy. It usually takes a combination of culture and software development processes that view governance as the step to take when things go awry or to be applied to only the most critical applications and services. While governance may be a priority for certain departments and controls may be in place with regard to how much of an application or service is shared, inconsistent governance practices will eventually make themselves known in unexpected ways.>> You can read this at: http://www.ebizq.net/topics/soa_management/features/12905.html Gervas
