By Paul French, VP, Strategy, Axway
IT governance isn’t new. It’s been around for years, beginning with the noble goal of aligning IT and business interests. Sure, there were the inevitable “track and monitor our IT spend” and “make sure we protect ourselves” goals, but they were secondary.
Soon, “governance” was a branded term, and infrastructure, reporting, and even complete solution categories were dedicated to governance. And in most cases, aligning IT and business interests was no longer the primary goal, falling a close second behind risk management.
With changing interests came changing measurement and expectations. IT was expected to “lock it down” — to control the experience from access control to data availability. And while this likely removed the perceived risk, it also seriously reduced the business agility the changing environment required. The pendulum had swung too far in the other direction.
So, we tried to have the best of both worlds — control and flexibility. Leading the charge were Service Oriented Architectures (SOA), a new way that promised increased availability, re-use, control, and a modified definition of governance. More inclusive than the “risk management is job #1″ criteria of old, this new governance model promised all the control but with a reduced risk profile. Nirvana was upon us.
Except it wasn’t. Quickly we recognized a limit to what we can control. Humans, trading partners, complex business processes — these didn’t fall neatly into the realm of SOA governance. We were close, but not quite there. What we missed in the process was the difference between governance and governing.
Quite simply, governance is establishing the rules, trusting the participants to follow them, and closing the loop on how well they behaved. Governing is taking those same rules and having continuous involvement in the process.
Let’s consider an analogy.
A parent forbidding their child from eating cookies before dinner is a form of governance over the child’s diet. In this case, the parent is counting on the child to behave according to the guidelines the parent established.
By dinner time, the parent will know if the child followed the process. Does the child eat their dinner? Do they have cookie crumbs on their shirt? Are there cookies missing from the jar?
The parent set out a clear process, hoped it was followed, and was limited to some data analysis at the end of the process. Did they get the results they expected?
Governing takes a more proactive approach. The parent still needs to establish the rules from the outset. They still need to analyze the data at the end to ensure compliance and provide opportunities for continuous improvement. But governing accounts for the control of the flows as they move through the process.
To follow up with our child — now there are guidelines as before, but there are also guide rails to help deliver the desired results. Want a cookie? Here’s an apple instead!
Governing takes the promise of IT governance one step further. It includes the design of the expectations and desired results, connects the participants (whether they are systems, applications, trading partners, etc.) to the process, controls the flow of data to guarantee the defined goals are achieved, and closes the loop with analysis. Governing is the action that delivers on the goals of governance. It includes the parameters to work within, the connection of the participants in the flows, and the analysis of the flows against the expectations.
It also includes that step previously absent in the middle: control.
Control is governing’s secret sauce. It makes the rules reality, engages the participants in a way that matches their workflow (e.g., human or system, real-time or batch, mobile or desktop?), and aligns directly with the expectations established.
Governance is (mostly) passive. Governing is active. You’ve long embraced the former, but now’s the time to embrace the latter. It’s not enough to insist upon a set of behaviors, outline the consequences of failures to comply, and oblige users to sign agreements they surely haven’t read. You must make compliance effortless. You must make it more attractive than non-compliance. You must make it all but impossible for your users to disappoint you.
If you don’t, and they do, will you — knowing what you know now — be satisfied that you did everything you could to help them succeed?