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.

 

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

May 26, 2014

I.T., Knowledge Management, and Innovation topics on Slideshare

Many additional articles on knowledge management and innovation are not on this site but instead are currently in a  Slideshare collection that has been building for several months. (Click here to go to the collection.)

The topics often look into the problem of terminologies, organizational roles, and to some extent the politics of performance management. Additionally, much more emphasis has been put on I.T. issues affecting the concept of the "enterprise", how its boundary can now be argued to exist, and what kind of information relates strategic competency to strategic effectiveness.

Some of that work will likely find its way onto this site in more extended narrative form. The format used on Slideshare is typically more generic or summary in its coverage in order to be presented quickly, leaving room for deeper dives later.

Posted by Malcolm Ryder at 7:37 PM

March 2, 2014

The Accidental versus the Intentional: Creativity as Discovery

If we could "tag cloud" global business writing today, chances are that "innovation" would be a Top Three tag. And if we could tag cloud all the things about "Innovation", chances are that "Creativity" would give "Agility" a neck-and-neck run for the money.

Almost no one tries to explain innovation without reference to creativity. But the definition of "creativity" -- something everyone needs and wants --  wears the persona of a debate.

So, this either adds fuel to the fire, or it douses some of the flames.

The value of creativity is discovery. 
The effect of creativity is invention.
The operation of creativity is experimentation.
The subject of creativity is structure.
The skill of creativity is composition.

In those terms, Creativity is intentional discovery, as distinguished from accidental discovery.

This will not make sense unless two other things are openly acknowledged:

- an invention may be new to its maker without being new to the world. It is possible that the same thing can get invented at multiple places or times, completely independently of each other.

- a discovery is not necessarily of a "new" thing. Things that have already been discovered may get discovered again through different means and/or by different parties, therefore also possibly at different places or times, independently.

And the point is that "Creativity" is sometimes a purpose or property of Activity.  In the terms above, it can be recognized when it's there, and it can be cultivated so as to become "in effect".

Posted by Malcolm Ryder at 2:07 PM