The architecture of enterprise strategy.
Architecture creates spaces for functions; Strategy creates functions for spaces. On with the show. Featuring ...frameworks, models, riffs and reminders. Find or predict particular issues via the text-search tool, the archive categories, or (in the archives) the Topical Framework. To comment on any articles, click here to contact me via email.
December 12, 2014
Performing Innovation Under Governance
For those who manage performance, governance appears to offer a layer of security for meeting performance targets. But the scope of governance's concern naturally exceeds the scope of production performance, representing a need to protect opportunity above and beyond performance targets. Inappropriate performance management will hold back innovation unless governance is appropriately influential on production.
The notebook accompanying this table traces the influence on the production environment that governance brings, with regards to supporting innovation. Click here to access the notebook.
Posted by Malcolm Ryder at 3:11 PM
December 7, 2014
The Right Thing To Do
Companies trying to make innovation a routinely successful practice may have steep learning curves and deep-rooted habits preventing the necessary degree of acceptance of change. Complicating matters further is uncertainty about whether governance is present and supportive, or instead, more likely an inhibitor of change, in their organizations.A key part of clearing that hurdle is having a consistent understanding of what is getting done by the variety of efforts needed to allow innovation to succeed. The distinctions shown here are the basis of a recommendation to exploit portfolio management and strategic sourcing in order to accelerate practical adoption and development of innovation. Followup discussion will be added to this article's table during December.
Posted by Malcolm Ryder at 7:20 PM
December 4, 2014
Systemic Governance
Like “defense” or “offense”, governance is a high-level orchestration of multiple concurrent activities, conducted to create an overall state – in this case, a state of assurance of stakeholder values. Governance provides an orientation to activities that, by executing them under known constraints, aligns their impacts cooperatively towards assurance. This framework guides the orchestration.
The background notes for this framework are here on Slideshare.
(c) 20104 Malcolm Ryder
Posted by Malcolm Ryder at 4:09 PM
December 3, 2014
Recognizing Governance
Doing things the right way is most often looked at in terms of whether a desired result predictably arrives. Those results make sense for "share" holders as performance, but "stake" holders are different.Stakeholders want things done a certain way, and they base their support of the organization on that. To retain that support, assurance must be developed for stakeholders. It means discovering and aligning governance opportunities as an intrinsic influence throughout the organization's behaviors.
Get the notebook behind this overview diagram on Slideshare at this link.
(c) 2014 Malcolm Ryder
Posted by Malcolm Ryder at 8:44 PM
June 27, 2014
Managing Configurations in IT's Future
Configuration Management continues to both seduce and strangle IT organizations, despite the documentation of ITIL. What we're frustrated with is not the process of configuration management -- instead, we're frustrated with the procedures. Organizations need guidance on how to get procedural complexity in line with the justifying impact on the business. Alignment increasingly means understanding who has the architectural capabilities (both design and investigation) to do the procedures efficiently, and getting them to do it as a service to other necessary types of management.
Let's review "process" as well as history. Imagine the chaos that would result if bookkeeping was removed from financial management. We can easily show that investment forecasting and risk management are distinct from bookkeeping and closer to "generating business value" in some sense, but it is just not viable to do them without bookkeeping. The value of the bookkeeping process is not ambiguous, nor optional, to the responsibility of business finance.
What has always been aggravating about configuration management is that it is a process looking for a procedure without being able to warn us how hard the procedure will be. The process is simple; the procedure is often wickedly complex. The process can be described in five bullets; the procedure can be described in hundreds of pages and/or millions of lines of code. Even if the procedure was easy, doing it reactively has been necessary because of a weird, circumstantial flaw in the logic of operations. What flaw? The flaw is that systems engineering did not include, inherently, change alerting as a prerequisite of item deployment into *systems*. We've been relying for decades on ever-newer technology to fix that flaw, and now making fantastic progress as "sensors" (in many different forms) start coming into their own and data analysis can keep pace with sensor data streams.
But the fundamental management logic to be respected is going to stay the same in the future as it has been in the past, and ITIL neither owns it nor invented it. In non-ITIL language, Accountability is exercised in order to support Quality, in order to support Risk, in order to support Capacity, in order to support Capability. It's why we stick to the recipe, follow instructions, and do testing on things we make before we give it to someone and tell them that they can rely on it to live up to what we say they can do with it. It's the same story whether we're talking about meals, physical fitness, buildings, cars, or networks...
"Configuration" is just a fancy word meaning "how it was composed to behave the way we intended". If we say we will not manage that, then we're saying we don't care how it was composed, or how it will behave, or both. Once any pretense of reliability is gone, then the idea that it has utility is... well... wishful, and of course, mostly risky.
But change happens, affecting reliability. Configuration change is sometimes on purpose and sometimes not, so if utilization is a source of changes to configuration, then utilization must be managed -- which is the science of Administration. Administrators have *always* asked engineers to make things in a way that would make those things easy to administer!
Here's the key point: we don't do configuration management of things that were not "built to a design for a purpose". The problem is that we are forced to do configuration management on things that are not securely restrained to the purpose of their design. Automation offers the prospect of increasing the "secure restraint" by making it more persistent in real-time and also operationally simpler. So it would seem that we'll be herding the cats less.
But automation will still leave the significant pressures of on-demand use, innovations, variable performance targets, and the political side of asset management. In other words, the things that are thought to typify efforts that "generate business value" will predictably require us to do other things that make managed change a reasonable effort.
What we're frustrated with is not the process of configuration management -- instead, we're frustrated with the procedures. Organizations need guidance on how to get procedural complexity in line with the justifying impact on the business. Alignment increasingly means understanding who has the architectural capabilities (both design and investigation) to do the procedures efficiently, and getting them to do it as a service to other necessary types of management.
Posted by Malcolm Ryder at 3:04 PM
