September 17, 2008

Business Process vs. Business IT: again?

Eric R. Chabrow checks in with the September 17, 2008 CIO Insight in an article called "Do CEOs Get Alignment?"

Chabrow's citations of a now-popular survey by IT professor Jerry Luftman bring to light a few things that, as it turns out, "represent IT" with an impact unhelpful to forging the "I get it" moment in the CEO/CFO offices:
- Personal experience with replaceable devices...
- management decisioning about replaceable providers...
- and of course the implication that CIOs are replaceable without strategic loss...

These frustrate the chances of recognizing "a business process called IT".

On the one hand, this is hard to overcome if people don't say what aspect of IT they mean to identify when they say "IT". An interesting point to put on the matter is that the primary expectation of IT users is actually "process management automation" -- not the same problem to solve as "information management" nor the level-setting about which sanctioned company processes are strategic/tactical/operational.

On the other hand, the word "alignment" itself continues to provoke and refresh the difficulty of reaching "I get it". The more important term to emphasize is not "alignment" but "integration". Imagine that some decision-making sector called "Business" was not integrated with the decision-making sector called "Finance". Since managing IT, like managing Finance, creates and governs a critical dimension of the business operational environment, some businesses cannot be dis-integrated with it and still rationally expect to succeed.

What might be really interesting short-term is to see and compare what stances about "alignment" come from CEOs who are Lawyers or are Technologists as opposed to Finance alumni.

Furthermore, however, as long as the "alignment" banner keeps getting hoisted by analysts and pundits in the trade, they'll keep educating CxOs to think about things in the wrong way. When it comes to IT, CxOs should be working on the management process competency at all levels -- an approach that would make it more obviously the responsibility of CEOs and CFOs to cultivate, not just for CIOs to offer.

Posted by Malcolm Ryder at 10:04 AM

June 24, 2008

Business-IT Alignment: Who Do that VooDoo?

At Tech Republic, the online resource for IT management information, executive editor Jason Hiner's article "Sanity check: What’s the difference between CIO and CTO?" relays the following quick guide.

Chief Information Officer

• Serves as the company’s top technology infrastructure manager


• Runs the organization’s internal IT operations


• Works to streamline business processes with technology


• Focuses on internal customers (users and business units)


• Collaborates and manages vendors that supply infrastructure solutions


• Aligns the company’s IT infrastructure with business priorities


• Developers strategies to increase the company’s bottom line (profitability)


• Has to be a skilled and organized manager to be successful

Chief Technology Officer

• Serves as the company’s top technology architect


• Runs the organization’s engineering group


• Uses technology to enhance the company’s product offerings


• Focuses on external customers (buyers)


• Collaborates and manages vendors that supply solutions to enhance the company’s product(s)


• Aligns the company’s product architecture with business priorities


• Develops strategies to increase the company’s top line (revenue)


• Has to be a creative and innovative technologist to be successful

Given that picture, the two top observations are these:

1. Infrastructure affects the bottom line (what you get to keep), while systems affect the top line (what you get to get). Of course, this goes a long way towards explaining why a CIO would report to a CFO, while a CTO would report to a CEO. More importantly, it indicates that strategic resourcing can be a CIO's calling card, but that strategic positioning can be a CTO's calling card.

2. Much less explicit but still clearly in evidence is the difference between being a chief operations technologist (a.k.a. CIO) and a chief business technologist (a.k.a. CTO). Naturally, the easy way of understanding how to assess their respective progress and performance would rely on understanding the consequences -- of not having good infrastructure (provision of operations technology) and not having good systems (provision of market interaction technology). But getting it figured out in positive terms has stumped the panel often enough and long enough that these job descriptions still have to get spelled out long after the hiring has been done . What's still needed furthermore to get the dust to settle is a plan of co-production between them. Whereas neither effort alone could get the whole job done, the combined efforts of the two groups would offer a company an office of Business-IT Alignment...

Posted by Malcolm Ryder at 8:48 AM | Comments (0) | TrackBack

April 3, 2008

The Circumstantial Strategist

According to Edward Cone, in his CIO insight article CIO: The Accidental Strategist, most companies claim that information technology is strategic to their business.

This seems like a no brainer; competitive business is primarily a matter of matching a determined need with a defined opportunity to serve the need, and neither side of the equation can be handled at the necessary combined volume, speed and cost of sustained competition without IT.

But, says Cone, according to research by Diamond Management & Technology Consultants, IT executives say:
- just one-third of the execs play a significant role in the strategic planning process at their companies
- only about one-quarter of participating CIOs spend up to 50 percent of their time on strategic issues
- barely one in 10 spend more than half their time on strategy.

In other words, the average actual occasions of direct CIO influence on strategy amount to only about 1 out of every 16 CIO person/hours -- approximately one short morning a week.

Averages are good at promoting distorted mythologies, so having put that one out, let's immediately begin to ignore it rather than repeat it. But from the observations in Ed Cone's article -- in which several variants of "The CIO" are posed for inspection by actual CIOs and by industry management gurus -- a few other points jump to my mind:

- First: the article's title may have been more apt if it said, "The Circumstantial Strategist". The territory being covered is not so much about why CIOs should do strategy, but instead about how CIOs get to do it. Along those lines...

- Second: CIOs who report to CEOs have a fundamentally different "lay of the land" than do CIOs who report to CFOs or COOs.

- Third: A CIO doesn't have to see the whole company to be strategic; he or she has to see the whole information architecture on which relies a business operation that is directly accountable to a CxO. Certainly there are enterprise CIOs, but not all strategy is enterprise-wide. In fact, many companies have more than one CIO.

- Fourth: CIOs are often in a position to recognize an IT opportunity to alter the business model. But there is a huge difference between having (a.) both the responsibility and authority to do it, versus (b.) only the opportunity. The politics of the internal corporate governance effectively draw the boundary around the CIO's effective role. What's probably more interesting than the "CIO" title is what the other CxOs have agreed is the range of the so-called CIO role.

Posted by Malcolm Ryder at 2:47 PM

March 16, 2008

Innovation by CIOs: the Same Old Same Old

Proposed: Business is built on IT, and CIOs know more about what IT could offer to innovation, so they should drive the innovation.

On the one hand, it looks good on paper. It's not new, but it seems to make sense.

On the other hand... wait, where IS the other hand?

The CIO Insight Discussion hosted some talk from industry analysts Forrester and kicked off followup commentary.

Reader Jon McAdams had left an earlier comment there that saved the rest of us some writing... So I'll segue from some of what he was pointing at.

CIO's who don't feel very "chiefly" should rightfully question whether their compensation is in line with how they'll actually be measured. But in the world of performance measurement, speaking truth to power is personally relatively expensive. How do you afford it? There's the dilemma.

Proposed: Any CIO who wants to use the word "Innovation" more than once a business quarter should be prepared to provide the definition of what innovation is, by distinguishing its flavors from each other: the planned, the authorized, and the actual. If the CIO is a decision maker in all three dimensions, then there is, fortunately, no dilemma; there's just execution.

But in execution, there are two tracks to follow: priority, and production. If the CIO is not being paid to decide and validate their alignment with each other, then again there is, unfortunately, no dilemma. There's just the matter of whether other people around the CIO want to know what's real or not before they take the actions they actually take.

Let's face it, giving action orders to the "head of IT" doesn't require having a CIO or being realistic. Meanwhile, getting orders can be done with one hand tied behind your back. But being held responsible for the consequences of someone else's higher up decisions is clearly not a prescription for being the chief.

Posted by Malcolm Ryder at 10:59 AM | Comments (0) | TrackBack

September 21, 2007

CIO 2.0 part One

Faisal Hoque, father of the Business Technology Management Institute, talks about the issue of solving the right problem instead of the wrong one in the CIO Insight article "Convergence, Yes; Alignment, No." As CIO Insight put it, Hoque noted that "rather than a goal, alignment is a stage on a journey to a more complete merging of IT and business that he calls convergence." With convergence, Hoque explains, "The business model is so intertwined with IT that there's no separate orientation."

What are the key features of this view for the top IT manager, for the CIO of the future? The same as for the CIO of now.

The first is the working definition of IT, which must position IT as business technology. This means technology of the type of business, not technology owned by the corporation of business. Here is a brief primer on business technology:

The second key feature is the working definition of "management". In the abstract, this has to mean "drive and authorize all key decisions about the utility value of the phenomenon at hand throughout its lifecycle." Naturally, the scope of this responsibility may involve or even necessitate collaboration and power sharing, and this means that a model of value-generation must exist to which all can subscribe. If this is to occur with IT, the concept of "IT" must be "operationalized":

From there, the third key feature, the point of it all, is to apply the operational potential to the business needs: this is how the IT model becomes the "dynamic" of the business model.

dynamic

1817, as a term in philosophy; 1827 in the sense "force producing motion," from Fr. dynamique (1762), from Ger. dynamisch, introduced by Leibnitz 1691 from Gk. dynamikos "powerful," from dynamis "power," from dynasthai "be able to have power," of unknown origin. The fig. sense of "active, potent, energetic" is from 1856. Dynamics as a branch of physics was in use from 1788.

Online Etymology Dictionary, © 2001 Douglas Harper

Given the numerous points at which IT could be mapped to needs, it isn't hard to appreciate that the current state of a business operation may have to go through significant re-modeling (transformation) to base the business model itself on the influences of IT. Speaking of that, the evolution of IT's realization as a business enabler actually is a goal, not just a stage. But the sneaky punchline to this is that the business may not need to be its own "IT-enablement" provider. Fusing the IT model and the business model (value management) is not the same problem to solve as the problem of establishing competency in the role of IT provider (performance management).

(This discussion continues in the follow-on article CIO 2.0 part Two.)

Image credits:
http://www.how-to-draw-and-paint.com/images/BasicHorse3.jpg
http://www.chss.montclair.edu/~pererat/7751.jpg
http://www.tsc-global.com/index1.html

Posted by Malcolm Ryder at 5:29 AM | Comments (0) | TrackBack

September 19, 2007

Make IT a Business Strategy

In the CIO Magazine article Let the Business Drive IT Strategy, the visibility of many views on strategy helps to paint the map so that people concerned with IT strategy management can see where their relative starting points are, not just their goals.

But in that map, how did we wind up in so many different starting places that we decided to call by the same name?

Here is a 50,000 foot high view to consider. What does "IT Strategy" mean? Strategy for what? The candidates are found in two dimensions.

First - what is used:
- Services
- Resources
- Information

Second - how it is organized for use:
- Provision
- Architecture
- Property (assets)

Make a 3x3 matrix of the above, identify what needs to happen in each cell and who needs to care (owner, operator, consumer), and then on the business side at least everyone can see what they are trying to talk about.

With that view, it then becomes meaningful to talk about the business's ideas of performance (goals), value (impacts), and risk (policy and culture) -- with the objective of assigning people to be responsible for them and then investing to make those people successful.

This isn't about "succeeding with a strategy"... it is about actually managing with a strategy.

Posted by Malcolm Ryder at 8:44 AM | Comments (0) | TrackBack

July 3, 2007

In I.T., Time is Money

CIOs are usually asked to stop the spending! ...but actually they go on directing the spending of the most important currency of all.

In an interesting parallel, the McKinsey folks have been able to track the connection of IT assets to business performance not by simple cause-and-effect, but by naming the secret sauce in the middle, just as the people who discuss Operational Performance Management (OPM) have.

In OPM, the problem is often stated that something must show up to align execution to strategy. Although execution presumably exists to directly serve strategy, it often proves not to do it, and it needs an agent of some kind... a middle man. Disintermediation is not a good thing.

Well, some readers run, a bit carelessly, with the notion that McKinsey preaches better business performance through IT superiority. Picking the "execution-er's" nit, us contrarians say that while high-performing businesses may show IT superiority, IT superiority doesn't necessarily equate to getting high business performance. For starters, despite the promise of automation, we don't simply equate "I.T." with execution; nor business performance with strategy, since many companies gain even more by luck than by smarts. And instead, we think the good stuff happens in the middle (somewhere between IT and business performance).

To be fair, so does McKinsey. But to improve on their take: we like the elegant end-to-end trajectory of evolving the application of IT -- evolving it from practices (i.e., cost) to strategy (i.e. value). This line of thought is crucial to escaping the boring myopia of anxiety or thrill about "commodity" IT... And to avoid having the middle of the trajectory wallow in wishful thinking, it is necessary a la McKinsey to insert "alignment", but which here means "investment". The right investment is the secret sauce.

To put this investment in perspective, ask a business, "if you could have only one of the following -- more tools, more ideas, or more time -- which would you choose?"

On the main trajectory, investing in the best answer -- time -- will mean tracking and balancing what IT does to people versus what people do to IT. Why? For example, in execution, whether about innovation or about maintenance, time affects how people use IT; and in procedural design, people decide "how IT uses time"...

Looking for superior IT utilization? When time is granted to persons interested in trying IT, IT enablement is learned much more quickly -- which is then what allows IT to change business capacity. Without capacity, you can forget about agility, recovery, and growth.

Naturally, then, the business is strategically concerned with "buying time". So, take any organization and, in the trajectory, here is the alignment both literally and virtually: the organization's politics of "spending time" will determine how its people get the time, and thus whether its IT can actually advance the organization's strategy or not.

And guess where time is *controlled* ? Not in supply, nor in strategy, but in management. So, ultimately, in a virtuous circle, the CIO manages to ensure that time is spent on IT to actually "create more time" for the business, instead of losing it... But what is the #1 barrier to achieving this virtuous circle? Politics.

Posted by Malcolm Ryder at 4:25 PM | Comments (0) | TrackBack

June 18, 2007

How IT Assets come from Business Requirements

After twenty years of developing, managing, marketing and deploying IT, providers still have huge opportunities to miss the mark by giving the customer what the customer asked for instead of what the customer needed.

To see how much can still be missed in any new delivery, check this chart and ask whether the implementations you're familiar with came anywhere near covering what was important.

Key shockers to lookout for:
- Customers didn't know what they needed! How could they always be right?
- Providers weren't solving the right problem! Why would the quality matter?
- Most of all, requirements held no accounting for the difference between risk, complexity and difficulty -- so who knows when anything would actually "work"?

Posted by Malcolm Ryder at 11:35 AM | Comments (0) | TrackBack

March 11, 2007

The Ontology of Support in IT-Business Alignment

Business-IT alignment is an ongoing critical success factor of enterprise performance. There, "support" functions of aligning IT with the business are all part of just two basic management issues that describe the problem of responsibility in the business-IT relationship. One, how does IT production fare in providing the deliverables to the business? And two, how well do the needs of the business associate to IT's support? The issues mark the distinction between what IT can do on its own accord (production) and what the business finds valuable about IT (support).

.
Once fully articulated, the factors of the relationship's "operationalization" show the belief system that underlies the standing functional organization of the relationship at the given business.

From the bottom up, the layout reflects how the IT "service desk" attains a central role in the alignment. The primary responsibility of the service desk is to bring proper workflow to the support request incoming from the business. The nature of these requests follows along the type of concern that the business has, which falls within three main topics in the relationship's ongoing "conversation". Within each topic, the problem is to solve the potential imbalance or mismatches inherent between the subjects of the topic. These solutions are what comprise the ability of IT to properly align to the business.

As shown, the organization begins with taking what management has in hand -- SME's and assignment authority -- and codifying it for continual reuse by the business, in the form of two key interfaces: a catalog and workflow.

These interfaces moderate any mechanisms for systematically addressing the three key topics of the business-IT relationship:
- business (demand vs. supply)
- service (performance vs. operations) and
- IT (capacity vs. systems).
As seen below, catalogs and workflow each have roles in two of the three topics.

.
The substance of the three topics is found in the dynamics of the business-IT relationship, shown here as three factors -- effects, drivers and constraints. In each topic, those dynamics represent how the resolution of the topic's issues may arrive at a suitable level and type of affect on the business.

A key finding in the above is that we can count on the IT "effects" to be critical to the service "constraints", and count on the service "effects" to be critical to the business "constraints".
.
Another key finding is that any of the "effects" can be (and usually are) both categorized and measured, with the categorizations sometimes being both hierarchical and deeply detailed. However, management often gets lost in those "trees" to the extent of not being able to see the "forest".

At the higher level, the management effort must accomplish the following:

1. Define the business scope of the service responsibility: this means creating and "productizing" services. What are the SLAs actually covering?

2. Define most requests for operational support in terms of managing service quality. Classes of requests should indicate what depth of exposure must be addressed in the service's handling of the IT provision to the IT user (incidents, problems, changes, etc. a la ITIL). Within each request class, further categorizations should point at the two critical factors of continuity and quality. (Understand how incidents relate to continuity and quality; how changes relate to continuity and quality; etc.)

3. Based on evidence (probably "symptoms") from the IT user, categorize the suspected perpetrators in the request's issue about (or requirement for) continuity or quality.
.
This identifies, as seen below, where the touchpoint arises between the request and the workflow needed to satisfy it.

Posted by Malcolm Ryder at 4:38 AM | Comments (0) | TrackBack

February 1, 2007

I.T. Without ITIL

The most exotic thing about information technology has always been terminology. It is the key to the scientific success of the field. But quite naturally, the complexity of the science also has meant that the terminology works steadily against any increase of ease in the field's practical management. More and more cats pop up that need to be herded. The net result -- a nightmare of semantics -- caused what the Gartner industry analysts noted over five years ago: the overwhelming majority of cost in I.T. comes from not technology complexity, but management complexity.

Perhaps that's why it is that in these last three years or so, the I.T. Infrastructure Library, or ITIL as it is commonly now known, gained traction with the kind of momentum carrying an industry standard. ITIL describes a huge range of management processes using a vocabulary of enormous logical consistency, which can make the semantics of management suddenly unambiguous despite IT's complexity.

At the same time, the sheer scope of ITIL is fear-inducing. Many of those who would use it fall into one of two groups: those who look for evidence that there is actual practical import to sticking the toe in the bathwater; or, those who religiously convert. Analysts like Forrester Research say that the former group is about 60% of the gang, while about 10% are fully pious and immersed, leaving the rest either just thinking it over or dabbling.

On the spectrum between the larger and smaller group, the larger keeps its practitioners cordoned off (but not quarantined) in a swim lane... handling the semantics of ITIL as another special expertise hoped to achieve some natural ascendency, the same way an innovation outstrips or obsoletes legacies. The smaller "immersion" group swims the rough open waters of large-scale revolutionary change in culture. Because ITIL is primarily documentation, there is not a real threat that either approach will alter it's ability to provide consistent guidance. But giving good advice is not the same as causing it to be followed. The top obstacle to following ITIL, ironically, is still confusion. Why is this the case? Simply put, corporate IT groups are forced to move at a pace that is much faster than their ability to absorb ITIL, and they are loathe to risk, much less give up, hard-won benefits from pre-ITIL practices. Yet behind those benefits, they often don't have an effective overview of where they already are. Thus, following along ITIL's paths, they constantly run into forks in the road that don't offer the obvious correct choice. Net: ITIL is a maze.To get over this hump, they still need a way to see, in short order, how they can connect the dots between their current practices and ITIL's.

Following suit, the perspective represented in the picture below simplifies the identification of the pre-ITIL circumstances, locating the starting line for a move to ITIL without the threats of disruption or of time running out.

The key assumptions in this picture are as follows.

First, no one really cares about I.T. except for whether it is perceived and proved to be useful.
Second, there are only two major points of view on that utility: the lifecycle of items composing the IT infrastructure; and, the production that composes IT operations.
Third, all of the IT management, whether in infrastructure or in operations, is essentially about two things: how things are (i.e., states), and how things happen (i.e., transactions).
Those three assumptions, when aligned as shown, organize every critical aspect of driving value from IT utilization. From this point, the rest is a matter of additional levels of detail.

Since management is popularly understood to be impossible without measurement, and since measurement can't happen without semantics, it is hugely important that the perspective drawn so far does not rely on confusing semantics and meanwhile shows analysis as an ordinary, not exotic, activity covering the field.

Within the general framework, four main phenomena surface as the major management subjects. Driving these down into daily practices makes sense under the assumption that the point of the practices is to establish value in the utilization of the info technology involved.

The utilization is established on two fronts. One is to give form to the actual information technology that users can ultimately access and exploit; this is what is called "IT Services". The other is to give form to the mechanism that creates and sustains that access and exploitation; this is what is called "Support Services".

In an unconventional but easily proved distinction, IT Services is about the provision of the IT configurations; whereas, Support Services is about linking the IT to usage requirements, as systems for use. (These systems are essentially and primarily logical, and secondarily take on physical form as the peculiarities of the company hosting them might allow them to at any time.) Usually, in effect, it's the difference between supply and demand, between service level management and service level agreement, and so forth.

As seen in the picture, the two kinds of services cover (i.e., attend to) the four major subjects in a certain way.The types of services relate to each other because they work on the same subjects. But the services differ from each other in what it is about the subjects that are the key points of their respective concern and influence. These key points are added into the framework's quadrants to clarify the high-level of analytic detail that really matters for the services. This level of detail is the one that initially accounts for the co-existence and co-influence of the two generic types of services (IT and Support).

For followers of ITIL: the difference between IT Service and Support Service is not indicated in the normal ITIL vocabulary. Instead, the generic concept of "management processes" proxies Support services that bring IT services to the user or customer. ITIL largely provides a taxonomy of those management processes, and most observers first engage the taxonomy of "delivering" IT Services (defining and developing them) versus "supporting" IT Services (maintaining and optimizing them). But at least half of the trick in adopting ITIL is to orchestrate its management processes into standing "Support Services" as described in this discussion's framework, which is oriented towards managing the value of utilization.

Posted by Malcolm Ryder at 4:50 AM | Comments (0)

December 1, 2006

The CMDB as a Knowledge Base

An executive overview.

In the front-office world of a business, the holy grail of a "360-degree view of the customer" is already old hat.

Well, much of what is now happening in the middle office -- the IT world -- revolves around the criticality of utilizing a "configuration management database", or "CMDB". This database is the key to a 360-degree view of any IT asset. In particular, it is a centralized repository of information about how items are defined and situated as components of the information technology infrastructure on which the business runs.

As a singularly authoritative (or "master") source of information about the infrastructure's components, the database content is very involved in the documentation and decision support for almost any business process workflow requiring IT enablement. But what is it about the components that the CMDB describes?

Typically the components for which the CMDB holds descriptions are referred to as "configurations". A quick survey of the CMDB literature shows that would-be CMDB users can get mired in great controversy about what consitutes a configuration, because there are so many ways to segment a chunk of infrastructure IT and legitimately call it a component. After all, the notion of a component necessarily refers to the idea of some larger entity that the component helps to make up. The problem is that any entity's distinctive identity must be defined with a boundary around its scale, complexity and purpose -- but just as any category may be said to be a subcategory of something else, any entity may be a component of some other entity. Thus it may be unclear where to draw a boundary, create an object, and call it a "configuration". The question always begged is "of what entity is this item a component?"

This makes it very difficult to decide what to include and exclude -- the CMDB's catalog of entities should be neither too general nor meaninglessly specific. How many levels of categorization and subcategorization (so to speak) must the CMDB contain?

In the below, we skip all of that confusion by looking at "things" in a more objective way. First, we take the notion of configuration not as a noun but instead mainly as a verb that has a result. The focus is on the motive for action. That is, nothing in the IT infrastructure is there except through the labor of making it fit into the company of other things -- and our first emphasis is on the labor that takes place to respond to the perceived need for including something that wasn't there before. This allows us to think of a "configuration" as the output of a system of functions, and the CMDB first of all collects facts about that output (and other ones, similar or related, in the same infrastructure ) -- as accounted for by its system.

But why collect the information? The primary reason is to put management of these outputs on a foundation of knowledge instead of on hunch. The CMDB's content can fuel knowledge by organizing its information into the three main contexts that matter to the difference between being managed and unmanaged.

Managed conditions always compare the actual against the planned and the authorized. This indicates three forms of knowledge that the CMDB would support: respectively, models, analyses and histories.

The essential CMDB content will be descriptions of states generated by the functions (as illustrated above), to be evaluated in these three contexts.

However, management tends to root itself in the posture of "operations" -- with the difference being that operations are mainly about organizational responsibilities while functions are about activity. This distinction is more profoundly yet simply identified in the hierarchy of management as shown in the next table. Top-down, starting from a focus on business value, the table rows address the questions "Why are we doing something?"; "how are we going to do it?"; and, "what are we going to do it with?":..

It is easy, then, to recognize the same top-down pattern in management's attempt to associate the needs of the business with the infrastructure that would address it.

Arguably, tactics are derived from respect for the customer's agenda, and functions leverage the offerings of suppliers -- so the primary challenge for differentiated management is in the operational dimension. Not surprisingly, Operations lays out responsibility areas in a way that tends to generally reflect functions. For example, the operational chain of development/implementation/administration/support is, on the surface, an echo of the functional flow of build/release/monitor/maintain. But Operations must intentionally, not coincidentally, associate its responsibility areas with the functions it can govern, if the dynamic is to be called "management". Operations must decide what functions will "execute the infrastructure" and how.

Consequently, what management wants from the CMDB is content that helps construct the artifacts of management that should populate the following framework. In this framework, captured knowledge explains how Operations currently puts functions into the context of the bigger management picture -- the one that generates business value. That overall knowledge-based governance looks to the CMDB to fortify its perspective and acuity on what to change, when and why.

In the above article:

Posted by Malcolm Ryder at 11:14 PM | Comments (0) | TrackBack

October 13, 2006

How to measure IT's contribution

Flashback from CFO: Magazine for Senior Financial Executives, Spring, 2005 by Malcolm Ryder

Regarding the notion of estimating how much revenue to allocate to every kind of corporate resource in proportion to each respective resource's contribution ("Revenue Is What Matters," Letters, Fall 2004), I have to wonder what purpose there is to that.

Not being an economist myself allows, perhaps, my view on this matter to spawn a useful question. Namely, without a definition of "contribution" there is no logic to the presumed "proportion," and don't we already know from real life that contribution means impact and that impact is defined by the system of measurement?

What most of us in IT and everyone in science have learned is that we can't talk about impact without talking about complexity, which means talking about interdependencies and frequently about the obscure order found within apparent chaos. If at Company X a $50 spreadsheet program in the hands of a $100K--per-year employee results in a discovery that generates $10 million in revenue, that's a great trick. And yet even if Company Y copies the same set of "resources," it probably won't get the same results.

The reason why accountants have not set or proved the so-called value of IT is because value is not generated by resources but instead by dynamics, and accountants don't measure dynamics. I agree that what is needed is a look at the answers already found in other disciplines.

For example, meteorologists measure systems and motion, such as high pressure, low pressure, and temperature, and from that they can attribute daily and even hourly impact to real causes instead of merely to gases. Likewise, coaches who actually know how to coach can tell you that the influence of the most talented player on the team can turn the team into a loser, where a much lesser talent can influence the team to win and so gets put on the field.
So the key is to break free of the notion of "resource" that is rooted in a concern for corporate property and learn to see that the elemental dynamics of situations are the real resources.

For most companies, the closest they come to this awareness now is their understanding that some company assets, like people and technology, must service something that they call processes, with processes representing the company's hypotheses of desirable dynamics. Logically, then, the process is the closest they come to defining the resource that should claim some of the credit for the revenue. What does the process cost, and how well is it managed?

Malcolm Ryder/Chief Strategist/Renovance LLP/
COPYRIGHT 2005 CFO Publishing Corp.
COPYRIGHT 2005 Gale Group

Posted by Malcolm Ryder at 9:56 PM | Comments (0) | TrackBack

August 12, 2006

Should we measure the ROI of IT?

Imagine not knowing whether spending on IT had any beneficial economic impact.

Should we measure the ROI of IT? Of course we should. But first we should learn how.

The ROI of IT is not difficult to understand. Confusion often begins with a poor articulation of the so-called "justification" for spending on technology. It's convenient to think of the justification as being synonymous with the return, but that hasn't prevented corporate America from deciding that it doesn't know what the ROI of IT is, has it?

The way out of the usual confusion is as follows:

1. Begin by understanding that you are spending on an *effect*, and that the technology is just a means. As the famous saying goes, "people don't buy drills, they buy holes."

2. Understand that "means" are not the same thing as "causes"... Despite automation, people decide what tools do. Decisions will either subvert or support the desired effect. Decisions create or destroy ROI.(See various writers, notably Paul Strassman, on the subject "Return on Management".)

3. Naturally, if the means have poor quality and are unsuitable to the task, they will inject either compensatory or remedial costs that will lower the potential overall economic benefit. But this "lowering" is because the potential extra cost of using the lesser-quality means is really a resource taken away from other more viable investment options. Returns are not found in budgets. Returns are found in portfolios.

4. Understand the actual role of IT. IT is simply a player on the bench. The game is won by the value of the plays. If you give your players the right assignments, then the play is run well and the impact of the play moves you to the goal. Assume that a poorly designed or inappropriate play will waste even a great player.

In sum, understand the difference between having IT that is good enough to enable the execution of the play, versus having plays good enough to win. You must invest in both, not one or the other. But IT does not cause the win. Except as regards IT's affect on the play, you cannot measure the ROI of IT with arithmetic; and since spending on IT is not usually the same decision as spending on strategy development, the correlation of IT spending against revenue or profit deltas is actually arbitrary for companies weak on strategy and IT architecture.

Posted by Malcolm Ryder at 10:16 AM | Comments (0) | TrackBack

August 7, 2006

Read once, Write many

Gil Grissom of Las Vegas CSI drills into the remains of Archimede's diary, featuring lots of smack about various Greek colleagues and babes, written during any of a series of famous bubble baths by which Archimedes is said to have discovered both buoyancy and the principle that ink smears.

According to story, jealous Christian scribes drained the tubs and wrote retaliatory remarks right on top of the original texts, thus inventing "tagging" and setting the stage for the South Bronx grafitti wars hundreds of years later.

Credits
Gil Grissom: Uwe Bermann, Stanford University's Linear Accelerator Center physicist, points to ...
Words: from a manuscript by Greek mathematician Archimedes at SLAC in Stanford, Calif.,
Gizmo: a high-power particle accelerator, set on "tickle", not "stun" or "kill"
Photo: AP Photo/Paul Sakuma

Posted by Malcolm Ryder at 6:56 AM | Comments (0) | TrackBack

August 5, 2006

Write Once, Read Many

And now, from the folks who brought us People Process Technology, this just in. The world's oldest computer chip, custodianship credited to the IBM Museum of Technology.

NOT.

Hey -- remember "PalmScript" ?

"Etch-A-Sketch" ?

"Unified Modeling Language" ?

"Moses" ?

"Bite marks" ?

Credits
Concept: Renee Ryder Mellon
Artifact: A tablet, said to be 7K yrs old, found in Bolivia. Look it up here...
Picture: belongs to the Associate Press. Bug them, not me.

Posted by Malcolm Ryder at 12:16 PM | Comments (0) | TrackBack

July 4, 2006

Business Value in IT Strategy

This picture describes the way that IT planning perspectives share the responsibility for discovering, integrating and balancing business priorities stemming from financial, environmental and operational requirements.

Strategists should consider, for example, how to place opportunity versus risks, resources versus capacity, and architectures versus agility.

These placements will then call attention to the nearby surrounding influences of real options, change management and economy of scope -- influences on analysis and design efforts in developing strategy with the apparently available opportunities, resources and architectures.

Those influences set the perspectives from which opportunities, resources and architectures are considered. The picture shows that they are related perspectives. The relationships feature overlapping perspectives, such as "risk mitigation" being handled by both real options and change management.

As a result of organizing within these influential relationships, strategic positions can enjoy inherently systemic support from the interplay of financial, environmental and operational events. This alignment of support makes the positions more sustainable, allowing the business to use them as a reliable foundation for its ongoing execution.

Posted by Malcolm Ryder at 11:02 AM | Comments (0) | TrackBack

June 16, 2006

I.T. Been Berry Berry Good To Me, Part Two

Our colleague Howard Hastings writes in:

Fundamentally, I agree with your concluding statements: that statistics from "the analysts" based on relatively small survey samples using questions of a naturally subjective nature are NOT very useful - unless accompanied by the explanations (read: deep and broad thinking) behind those questions and the final premise.

HOWEVER, I believe that the CIO Magazine article highlighting the Forrester numbers largely misses the key point - "IT Decision Makers" are NOT well positioned to properly and successfully influence the business (i.e. innovation).

Why? For those of us who "stumbled" into IT from business backgrounds it isn't that difficult to understand - IT people too often can't/won't adjust their own mindset and delivery to effectively communicate and/or work with business people. Essentially, "logical thinkers" generally don't see the need to empathize with the "targets" of their ideas … the notion that "experts" should be required to understand the motivations and perceptions of mere "users" is, in itself, irrational.

Anyone familiar with "personality typing" (Myers/Briggs, Keirsey, et al) will easily recognize this behavior and the inherent challenges it represents.

That said, I would strongly question the validity of successful innovation driven by "IT Decision Makers" being awarded a score of .200!

I suspect that most, if not all, of the innovation success came as a result of IT being TOLD that they needed to achieve a particular objective. Anyone who has been involved long enough in IT at senior levels who can be reasonably rational with themselves will admit that technology itself addresses AT MOST 30% of the overall solutions to business problems. The rest comes from people, processes, knowledge/content, etc. -- H.G.H.

Which reminds me of what I left out last time... the best examples of IT effectively driving innovation are examples where the use of IT was the actual basis of the innovation. But this still leaves two other issues to deal with. One of them is that the innovation might have been a highly successful output of IT, but the business built on the innovation might still be pretty poor business. The other is that there is a difference between innovative technology and innovative use of technology -- the point being that just saying "I.T." doesn't tell you much about what is actually happening. For more on this difference, search Archestra for the discussions on (a.) operations and competency; and on (b.) invention versus innovation.

Posted by Malcolm Ryder at 1:06 AM

June 14, 2006

I.T. Been Berry Berry Good To Me

The best quote of the year so far: from Romano Prodi, former president of the European Commission running for prime minister of Italy against incumbent Silvio Berlusconi back in April. Said Prodi about Berlusconi, "you lean on numbers like alcoholics lean on lamp posts, not to be enlightened, but for support..."

Yeah. That's the spirit! Numbers should be fought over. A bunch of new ones from Forrester, in CIO Magazine, show IT organizations doing the same old same old, when it comes to providing value to the business. In this report, IT's top batting average of .380 against Business Pitching feels bad, but that's really hot in baseball.

Just Makes You Think: Oh yeah, that's right... this stuff is pretty hard...

For the sake of skirting copyright, I memorized the information so I can now fearlessly just "tell you what I remember"... OR you could go see for yourself online (or...the June 15th hardcopy includes the Forrester survey numbers chart).

I remember that Forrester said:

1 - Improving productivity or products/processes rates in the high .300's
2 - Optimizing cash flow or customer lifecycles hits the mid to low .300's
3 - Powering successful innovation in process collections or in product collections steps in the mid to low .200's. Wipe your shoes.

But what do these numbers mean?

First, the way Forrester set it up, the batting average actually represents the number of "IT Decision-Makers" who gave IT strong credit when given the chance to do so. For example, almost-but-not-quite four out of ten gave IT credit for improving productivity or likewise for improving products.

Now, looking at the numbers and what they are attached to, is it insane to say that the more complex a problem is, the less likely IT is going to make an obviously critical contribution?

We know the problem complexity rises as you go from the top of this list (e.g. productivity) to the bottom (e.g., innovation). Why?

Well, in each case, think of the number of variables that are reasonably under critical IT influence as they combine with each other. In order of appearance:

- There are simply fewer of them when it comes to improving productivity or improving products/processes. (We didn't say the tasks were any easier, we just said simpler.) That level of influence is a lot like construction work.

- But the next level -- optimizing cash flow or customer lifecycles -- is more like winning poker games. More participants trying to not be on your same page.

- And the remaining level -- innovating (reconceiving, not just improving) products or processes is more like herding cats. More participants who see your page but could care less.

Here's the main suggestion. As we drop down the list, and move from productivity to optimization to innovation, the necessary influence on the variety of participants who need to buy in becomes increasingly less a deliverable of IT.

Going along with that, we can still hope that IT can contribute to the necessary influence. But then of course, we must identify what kinds of influence are necessary, before we can understand whether IT can make a significant contribution.

What this calls for is a perspective in measurement that can recognize and understand the game-saving catches, the turning point singles, the continuity of getting players on base -- the things that go missing in games that are not winnable. Eveyone sees the home runs, but most of the time, most games are won by most players being good enough to allow a win. Their individual responsibility is to be good enough for the other players, not to win the game by themselves.

The Forrester numbers superficially tell the story a little differently, but let's decode them. Given what was argued just above, they suggest that very few of every ten IT Decision Makers understand the difference between how well IT does its part and how likely it is that the IT part will "cause" a win. This further suggests low understanding of what it takes to win at productivity, optimization and innovation. That is, statistically, some of the decision makers may have given 100% credit to IT for effectiveness, but those that gave little or no credit (due to lack of understanding) dragged the Forrester averages down.

Meanwhile, the reason why batting .300 in a game is good enough is because it's enough to allow the other parts of the operation to add up to a win. Batting .300 represents about 100% of reasonable expectations, not 30% of requirements. The decision-makers who gave IT high credit likely saw this.

So the numbers we see from Forrester are not what we really want to see. Instead, we want to see the explanations given by the decision makers who credit IT with high effectiveness, and compare those explanations to the ones given by the nay-sayers.

Post Script: Saturday Night Live was a hit before lots of IT people were old enough to tell a joke. If you're older than that, you might remember Chico Escuela played by Garrett Morris, who broke the line that we cloned for the title of this article, but who for all we know now works in IT somewhere as a decision maker.

Posted by Malcolm Ryder at 4:48 PM

April 2, 2006

Business-IT Alignment: Revisiting ActiveROI

By the time the Y2K threat got serious in the corporate mindset, IT innovation had already reached a point of viability where replacing old stuff had to be taken as a serious alternative to patching it.

But it wasn't just the technology that needed to be reconsidered. As it is almost automatically remarked in the business conversation about IT, related people and processes also were in the mix -- and here came the dot-com wave.

Among various other things that "e-business" did to reposition IT in the enterprise, it gave an old teaching instrument a new meaning.

You may remember the elementray school spelling aid "I before E except after C"... For it's new web-era use, I translated it to mean "infrastructure before engagement, except after customer." The problem new to the day was that the web was now allowing customers unprecedented aggressiveness in dis-intermediating the corporate mechanics that ordinarily actually provided services. Customers emerged who wanted "do it yourself" relationships, while others emerged who simply had no patience any more for companies that mired them in internal production technicalities.

Effectively, in both cases the customer's punchline was: "if your I.T. doesn't make me happy, change it or I'm gone."

The hugely superior economies of keeping existing customers versus gaining new ones made the most sense of my new translation. But the implications for IT organizations were not really so new. The point-of-view on IT's operational performance just shifted from I.T.'s "internal" customers (business units) to the company's "external" customers. Internal customers had already had this attitude for a while, and everybody knew it.

Still, despite external customers suddenly getting their hands directly on company infrastructure, it seemed brutally obvious that IT organizations should not be held responsible for managing external customers. (Otherwise, what were business units for?) So the message really needing to be drummed was that internal customers needed to be better empowered by IT.

By abstracting the basic management steps to that empowerment -- resources to operations to relationships -- the model I first proposed set a floor under a wide region of research, from which several key further items grew. Among those, a major one well-rehearsed by 2002 forecast the IT Organization agenda as in the article CIOs: Managing the business's IT Agency.

Then, what brought that agenda to the level of the full CxO group was the problem of linking IT performance to enterprise performance. This problem enjoyed a huge rise in importance due to the maturing acceptance of having enterprise applications automate essential operations cross-functionally, despite hair-raising complexity in integrations and change management. While I liked referring to the celebrity of the problem as "Enterprise Chance Management", it wasn't much of a joke since it was also becoming more obvious that business opportunity was relying more and more on IT-enabled responsiveness.

Given the huge level of investment recommended by Y2K, enterprise applications, and the internet, the business need to understand the value of its IT capacity hit a high point that called for a way to put the IT agenda into a model of being managed by the business. In reply, I created (and own) the ActiveROI model -- a construct signifying the generation of business value from IT resource optimization, achieved in a continuous and proactively matured discipline. Translating the model into practice methodology, the consulting firm Renovance, LLP went to market. Renovance's elaboration of methods for applying the ActiveROI model was indicated early on in the whitepaper, "ActiveROI: Achieving Business Processes and IT Infrastructure Alignment through Real-TIme Management". (As a consulting firm, Renovance developed and offered trademarked practice methodologies of my copyrighted model, in its lines of business.)

From a CIO's perspective, the ActiveROI model describes that the enterprise's engagement with the marketplace runs on an organizational platform created by architectural and portfolio management disciplines that can coordinate IT.

But overall, ActiveROI understands performance in terms of relationships and the services that maintain them, while it understands resources in terms of events and the investments that address them. The critical thing to note is that services and investments are the two most highly discretionary offerings of the executive management of the business -- effectively defining the identity of the business that will predispose its opportunity in the market. As explained by ActiveROI, this "drills down" to the IT agenda and its business alignment.

By way of ongoing explanations and by hosting comparisons and debate, Archestra will continue to elaborate the ActiveROI model and several of its already-in-progress successors or offshoots -- including Archestra Runtime by myself, and works that certain colleagues may finalize for presentation via Archestra in the future.

- Malcolm E. Ryder, April 2, 2006

Posted by Malcolm Ryder at 9:50 AM | Comments (0) | TrackBack

March 14, 2006

Finding the "Enterprise" in IT

In running the business with a strategy, strategy must increasingly factor IT into its equations, because of IT's power to affect most of the conditions to which strategies design a response.

Going along with that, the working assumption is that a business organization must have IT-based capabilities that allow it to beneficially maintain and change itself in its target environments. A standard caution is that IT can always make things different, but that "different" is not necessarily "better" -- and the definition of "better" must come from the business.

Given those points, there is a logical hierarchy of values in IT-based business solutions. To reveal it, however, requires clarity about the difference made by automation and the difference made by information.

Superficially, we always recognize that information directs decisions and automation directs labor. But decisions also commit that labor, while taking into consideration that automation can change the feasibility of the commitment for better or worse.

As a result, we see that decisions drive automation -- meaning that information drives automation, not vice-versa.

Arguably, then, the top business issue to address with IT is to govern information access.

This makes the overall affair of IT management primarily sensitive to the successful provision of information driving the decisions. But what is meant by "overall"?

I. Solving the right problem

Keeping in mind that decision-makers are placed at all levels and locations of business production, adequate visibility and control of provision is a gigantic and daunting task. Processes that govern information access are the ones that most need to be automated.

But the point of governing that access is to ensure that decision-makers are supported securely, appropriately and efficiently, so that they can pursue business objectives.

This point provokes a general model for the relative business values of IT-based solutions. The importance of having this model is to set expectations consistently and to provide the most basic logic behind changing existing investments in, and implementations of, IT.

The solutions should contribute to one or more of the following very broad objectives, which flow top-down from the main desired business capability to the supporting functions, architectures and assets:

Taken together, the four concerns add up to maximizing the quality of the IT infrastructure as a business resource.

Specifically, solving the combined concerns -- governance, rationalization and optimization -- results in a positive ratio of resource capacity to business demand, which then allows strategies to "close the loop" by exploiting #4's ability to enhance #1.

II. Optimization

In optimizing resources, businesses rightfully ask, "how capable can we afford to be?" Regarding IT, this is a general way of pointing at the problem of return on investment. It might casually be seen as a cost/benefit ratio. But the flaw in seeing things that way is that, with adequate production supervision, benefits are simply desired outputs that are more or less predictable according to their price; to generate real business value, those outputs must still be used in certain ways.

For example, buying a computer and using a computer are quite different. In the first case, an asset becomes owned; but in the second case a resource is deployed (committed). Ownership and deployment have different kinds of value. By linking assets to live functions, deployment makes IT serve the business.

With this commitment, the natural inclination is to pursue as much functional potency from the asset as possible, and discard the asset when it can no longer measure up. That potency may even result in enterprise-wide impact.

Yet more importantly, the method and opportunity for achieving that potency may not be scalable cross-functionally or enterprise-wide. So this is not the gist of the notion of optimization nor of "enterprise" IT. The enterprise-scale value proposition is not to optimize the commitment of "all X number of components" but instead the commitment of the overall IT infrastructure as a resource. By analogy, it is managing an entire portfolio instead of a collection of budget line items. It is seeing the forest first, not the trees.

At the enterprise scale, the deployed infrastructure essentially becomes an environment for business operations, and IT management accordingly must step up to an environmental perspective. From that position, optimizing the environment basically means programming its dynamics.

For example: business typically organizes its information demands with desired flows of business processes -- and business processes are highly sensitive to changes forced by competition, regulation and economies. Because of that, the related IT processes that help govern and enable information access need to be not just reliable but also adaptable (i.e., versatile and/or flexible). This involves a critical dependency on the underlying infrastructure. Thus, due to ongoing change, deployment of infrastructure is also a continuous "environmental" process, not just an event.

But the programming is not just about addressing deployment for demand. It is also about support for utilization and allocation for supply.

In coordinating all three dynamics, the key characteristics of environmental-scale management feature an extent of visibility and control that intends to establish productivity and conservation in balance with each other.

As part of the environmental programming, management establishes the generally required conditions for this balance through several means:
- policy (which protects priorities versus requests)
- standards (which protects regularity versus options)
- security (which protects integrity versus exposure)
- economy (which protects assets versus consumption

While those protections are a major deliverable of management for achieving balance, the value of that balance at any time is determined by its relevance to business goals. That is, management's other key objective is to have the balance actually promote business development.

The problem is that business development so frequently pressures management with local demands that challenge the global balance. This threatens the environment's equilibrium, which increases the uncertainty about its overall quality versus additional and future demands. Because of that, what management wants is the visibility and control to maintain the environment's equilibrium while knowingly raising its overall quality as a resource.

III. Rationalization

The strategy for having that visibility and control requires a focus on services and architecture. Services predefine the relationship of deliverables to demand; and architecture predefines the relationship of capacity to services. The predefinitions allow the organization's managers (or providers) to offer things already known to fit into economies and scales, and locations and permissions, that they can handle -- and to more readily recognize and decide about things that don't yet fit. Among those things that don't fit are not only newly-emerged requirements awaiting organized support, but also potential threats to the integrity of the established services and architecture.

Unfortunately, the growth rate of a large IT environment may often have outrun prescriptive efforts to define it -- raising the number of exceptions, silos and risks. This simply means that it now has to be retrofit within the terms and principles of architecture and services -- that is, those become the elements of rationalizing the environment. The descriptive language of services and architecture will supply a different perspective from which to identify and assess the environment. Subsequently, discoveries will be made that indicate a need to make changes that will conform the environment to business requirements.

IV. Governing with IT processes

What this really means is that the environment at minimum has to be "trained", not necessarily rebuilt, and programming the environmental dynamics begins to accomplish this. But eventually the programming might require reorganizing things in ways that reveal omissions, defects or obsolescence in the resources, whereupon rebuilding is appropriate.

The challenge is to have adequate visibility and control of any reorganizing. Critical information gains or loses availability and credibility according to how its channels are gated, groomed and connected. Knowing that infrastructure modifications will range in types -- from innovations to deployments to shoring-up defenses, and from strategic to hostile -- policy and change management take on an enormous significance. Meanwhile, the implementation of business policy and business change increasingly must be supported through IT, and this means that business policy and business change must also be translated into IT policy and IT change. That translation must not be speculative, and the outcomes must be explicit.

V. Business management

From the business point of view, the purpose of relying on IT is to bring significant assurance to the safety, competency and advantage of whatever the business tries to do. For IT to offer this kind of value, it must be manageable, and the complexity of its manageability is the main barrier to the business being successful in the driver's seat.

To the extent that complex technologies can make technology management simpler, complexity breeds value by giving the business more practical influence on IT, of the kind that it intends. (Today's automobiles are the most complex ever, yet they are easier than ever to drive.) But the success of the business is predicated on its ability to tailor responses in real-time to the particulars of each opportunity event. Any given response -- a blend of characteristics including safety, competency and advantage -- may need to be significantly different from others, yet crafted from a known available capacity.

Thus, from the business standpoint, the enterprise IT management goal is to achieve the lowest cost of predictably sustaining the necessary degree of enterprise-wide adaptability of the infrastructure. With that established, business processes and business performance can in turn be more readily managed to business targets.

Posted by Malcolm Ryder at 1:20 PM | Comments (0) | TrackBack

March 3, 2006

Driving IT Bang for the Buck: Evolution, Improvement, or Innovation?

When we think of effective IT spending, we're focused on making the best current use of the money, given competing alternatives or emerging options. But increasingly, the basis of effectiveness in business spending on IT proves to be in how the business manages its reliance on IT.

Sometimes we don't have enough visibility of legitimate alternatives and options. The urgency of our attention to the purpose that justifies the spend means that this lack of perspective could be left unsolved. But for that reason, a diligent evaluation practice looks for opportunity costs that should be factored in. As part of this diligence, what remains to be emphasized even more is not how the IT will make the organization work, but rather how the organization is going to make the IT work.

I.

In the full cycle of management, the business first conceives and identifies why IT is needed before it makes any other decisions. To avoid taking the need for granted, this first decision means describing the business model in terms of what potentials are granted it by available IT. That is immediately followed with a forecast of how sustainable those potentials are -- which necessarily means identifying and selecting how to make them sustainable.

When that architectural aspect is clarified, the next part of the decision cycle must create a "delivery" organization that can constructively practice the architecture. This means two things:
- establishing the sources and resources that will produce the infrastructure from the architecture, and
- establishing the processes that will link IT production cycles to business operating cycles.

At that decision stage, reliable design and reliable production easily wind up being qualifying criteria used to distinguish the various opportunities, organizations and risks that the business will incorporate as the elements of realizing of its model.

Thus, investments in their incorporation aim to relate reliability to the goals of business. That aim immediately offers a perspective from which a high-level assessment of the current business investments might be done. Normally this makes us think of metrics; but as pictured below, the main point is to allow the perspective to stage comparisons and guide questioning. Here we might just catalog known commitments by critical business goals.

II.

Those commitments might then involve or indicate spending on IT. But, as described there and below, the associated "IT investments" are not about IT per se but rather about the application of IT. We can understand the idea of "application" by considering the purpose of the IT utilization.

- At the highest level of distinction, the business goals of incorporating the opportunities, organizations and risks are recovery, health or growth.
- Within each of those goals, sub-goals are development, maintenance, and change.
- And within each of the subgoals, another sub-level features assessment, design, and control.

Consequently, it is possible to ask questions at the management level such as, "Can we control the maintenance of our health?" or "Can we assess the development of our recovery?"

These are not IT questions -- but they are questions that present opportunities for IT to enable successful management outcomes. In turn, management is focused on enabling successful business outcomes.

Taking that framework of IT incorporation as the main perspective, it is easy to appreciate that business utilization of IT is nearly always altering something -- either a behavior or a current state.

The importance of how IT is managed, though, is in how well IT supports management's ability to intentionally change how the business can behave. (From here on we'll consider "change" in this larger context.)

III.

The observation just made emphasizes that we can and should compare the kinds of value offered by different classes of change, and then associate IT's effects to those values -- as contributions.

To demonstrate that, compare evolution, improvement and innovation.

Relative to each other, these kinds of change differently affect the state of the business:
- evolution permanently modifies the fitness of the business's model to the dynamics of the environment in which demand develops;
- improvement modifies the fitness of its conduct to the current and targeted demand;
- innovation modifies the fitness of its output to the needs of the environment's population.

According to perceived conditions regarding recovery, health or growth, business executives must determine when any of these three modes of change requires higher-priority attention. A timely reaction is mandatory, but proactive change is potentially strategic to optimizing the benefit versus risk of those conditions. That may result in new or extended initiatives to create the necessary related sponsorship and opportunity, including competencies and technical support that might drive spending.

To support a proactive stance, a good device to have would be a framework for envisioning, monitoring and ultimately predicting circumstances that we can agree will signify a need for change. Not coincidentally, those circumstances have the look and feel of key ideas offered within the business justifications for IT spending. That device might look like the following:

IV.

But given those considerations, executives and managers together should ask the "big picture" questions -- for example, whether an improvement initiative is the most likely candidate to produce better recovery, as opposed to an innovation initiative. At the same time, it is important to recognize that one kind of change may be an element of another kind and acquire priority that way. After all, form allows conduct, and conduct (i.e., production) allows product. As another more specific example, innovation may accelerate evolution, and improvement may create more opportunity (security, income, knowledge, etc.) for innovation. Thus, an improvement initative can strategically foster the goal of accelerated evolution. But likewise, the requirements for supporting an adopted innovation may obsolete improvement efforts dedicated to earlier production, eliminating that legacy cost while potentially releasing resources for new purposes.

These interrelationships are characteristic observations in portfolio management.

IT management must be focused on applying IT to business operations present and future. On the one hand, it is typical that an IT budget might be evaluated in terms of how much spending goes to "maintenance" versus "R&D" and so forth. Those generic classes correspond to how IT responds to the business requests for support.

But the rollup of dollars into those classes can easily obscure the more important and time-sensitive issue of whether the right things have been selected for maintenance, or the right things are being pursued through R&D. By calling for a distinction between wise spending and merely approved spending, we get to a conversation about how management leverages IT for the business -- as opposed to mere responses. In that conversation business and IT organizations together find the logical path to measuring the effectiveness of the decisions, and to measuring how much that effectiveness was worth.

The view that unifies their concerns is not one about how "IT investments create business value", but rather one that business value subscribes IT.

Posted by Malcolm Ryder at 8:16 AM | Comments (0) | TrackBack

March 2, 2006

Optimizing IT for Business

Business always enjoys the ability to directly engage IT resources as a response to business needs and robust technology markets. The business can directly drive the sourcing and provision of IT into its operations.

But the consequences of that engagement extend far beyond functionality and expense, into the broader ecologies and economics of the organization's health and growth, affecting business value and business risk.

Designing the business reliance on IT as a strategic outcome of resource management requires logically managing the investment of IT assets into models of service governed by accountability standards for business relationships and business performance.

Inserting management into the Business-IT engagement, IT operations create effectiveness on the basis of service capabilities that balance for the business demand and supply (of IT) over designated periods of time within the boundaries of funding levels.
- Catalogs and Contracts prescribe demand.
- Portfolio and Lifecycle management prescribes supply.

Between the value propositions associated with demand (justifications) and with supply (options), standards for practices in sourcing (buy/build) and provision (deploy/support) create more predictable and secured scenarios for balancing costs, risks and quality -- in both the availability of IT enablement for business functions, and likewise in the capacity.

The logical linkage of Services, as established by architecture and agreements, provides a basis for continuous measurement and improvement of the alignment mechanism established between IT impacts and business operations. This rationalizes resource allocations and optimizes the IT enablements of the business.

As a critical mediating influence on the business leveraging of IT, management brought by the IT organization (gray boxes above) sees to it that the business builds it expectations with proven alternatives.

Supporting the business visibility of the alternatives, and controlling the development and delivery of the alternatives, become logically collaborative strategic efforts between the IT and Business organizations.

Posted by Malcolm Ryder at 3:48 PM | Comments (0) | TrackBack

February 17, 2006

Executive Agenda for IT

In the diagram below, we have a bird's eye view on the major business initiatives reconfiguring the management of the enterprise's reliance on the IT infrastructure.

The view identifies that the key high-level motives of the organization are related in certain ways.

The enterprise wants to maximize the value of its autonomy and identity through decisions and actions that:
- differentiate itself in the market,
- optimize its modes of establishing impact and presence there,
- sustain the mechanisms that it uses to do so, and
- control the dynamics of its organization's internal makeup and external behaviors.

These possibilities are systemically related to each other. That is represented by the perspectives that are used to monitor the general states and conditions that presuppose the enterprise's health and/or growth. These perspectives -- governance, performance, architecture, and security -- collectively describe the approaches and models for monitoring the enterprise. The general understanding sought is of whether the way the the organization has chosen to structure itself and to act is viable for achieving its intended goals in the environment it has chosen to inhabit.

Also shown in the picture is the prominent place that stakeholders have between processes and performance.
Likewise, the key intermediary position between security and processes is typically occupied by policies.
The chain of influence formed by their inclusion explains how security is linked to performance -- meaning that the enterprise continually must balance the opportunities to which it commits against the constraints that it can recognize.

For the time being, though, this discussion focuses on the chain of influence that runs between the enterprise's two more overtly discretionary states. Governance and Architecture are both highly complex but they are also more fully synthetic designs than are security and performance, because they are less dependent on external forces to realize and maintain their intended design. As such, they are closer to the issue of the competency and maturity of the organization that can be established directly by management. The picture above expresses the target competency and maturity through identifying issues such as that standards mediate the dependency of processes on infrastructure, or that change mediates the production of infrastructure from architecture.

Taking this picture as a bird's-eye view on the top "surface" of the enterprise's structure, what lies underneath are layers of composition, for example such as "assets". The picture shown here allows us to consider enterprise assets in terms of each motive, perspective and linkage illustrated, detecting discontinuities and strengths of impact. While financial evaluations, functional evaluations (which include intangible assets), and physical evaluations of assets are already three ways to understand how assets become enterprise resources, we see more clearly in the picture here the circumstances in which any of that matters. Likewise, operations, relationships, and strategies are each layers to be interpreted.

The presumption of the different underlying layers highlights that the terms shown in the picture are necessarily abstract -- but it is that very abstractness that allows us to understand that they influence each other in an "essential" way, not just a circumstantial way. Understanding the enterprise from this model is mainly an act of interpretations. For example:
- From an organizational viewpoint, it's not hard to see the organization defining itself in terms of the linkages such as rules, systems, services, etc. by which it institutionalizes itself for attending to the primary motives.
- From a practices viewpoint, it's not difficult to understand from the picture things such as that compliance is a management responsibility that derives from the influence of rules, policies and requirements.
- From a disciplinary viewpoint, BI and BPM have evident locations and sensibly share influence on agreements or "contracts" by discovering and then formalizing the conditions for assuring appropriate deliveries.

While the abstractions and their interpretations cover a wide range of management phenomena and business objects, we'll always eventually wind up back at the huge reliance that the business has on information technology in order to just stay on the playing field. As a result, it is appropriate for IT executives to interpret IT plans, operations and impacts with this same picture of the enterprise, acknowledging that the portfolio of IT implementations can be evaluated for its completeness and effectiveness by considering how much support is being generated for the alignment and balancing of the items in the picture.

Posted by Malcolm Ryder at 3:49 PM | Comments (0) | TrackBack

February 11, 2006

Linking Economy to Profitability

After a five-year pendulum swing of spending to cutting to spending, we've managed to stretch across four chapters of the IT-Business relationship: Y2K, dot.bombing, BackToBasics, and now Compliance Versus TheTopLine.

In these chapters, the story of transitions also features patterns overlaying other patterns.

For example, over the phases, we'd see that:
- the role of an IT infrastructure was swinging from being a risk factor to a success factor, back to risk, and back again to success. Meanwhile...
-The business model credibility was swinging from supply-chain angst to demand chain angst, back to supply, and back again to demand.

With patterns like those to find and juxtapose, there is plenty of room for examination of cause-effect relationships in how technology evolution and architecture may have precipitated new phases or ended them.

No question, this examination must necessarily acknowledge both intended and unintended effects. Business reliance on IT is a double-edged sword and, as shown with space exploration, we get to know how to reach a place too soon-- but only later how to stay there, and sometimes almost too late.

Yet, respectful of the need for wariness, we can honestly look at each of the aforementioned phases and, with the clarity of 20/20 hindsight, see for each one the gigantic "DUH!" that shouldn't have had to be. Obsolecence, irrational speculation, anorexia, and opacity if not arrogance... all of them butt-kicking poisons from the business side, not the IT side.

Because of that, where the topic is "intention", there is another big story, too, about the glacial maturation of what must be considered "business intelligence" (BI). Although at the moment mired in the learning curves of collaboration and analytics, BI's ultimate goal of achieving a sufficiently comprehensive perspective is perhaps represented most clearly by models such as Kaplan and Norton's Balanced Scorecard and European systems for systematically including the measurement of intangible assets, such as Karl-Erik Sveiby's Monitor and Juergen Daum's. At any rate, the rush is on for businesses to actually get smarter through intelligence -- with the twist being in the emphasis on having the right kind of smarts.

So, lessons learned: while IT makes action almost too possible and makes info almost too widely available, these are relatively intrinsic qualities of IT -- characteristics that have the great potential to simply erupt without regard to management, and therefore are not reliable barometers of business value in IT. In turn, that means we can't build value management on the basis of those characteristics.

The real issue for management is not to "enable IT" to do those things but instead to harness and leverage IT's innate ability to be an enabler itself. Business management is the source of return on IT investment.

In that light, some interesting points surface:

- The characteristic dimension of the business focus on IT management is, except for professional developers, not technology development!

- Neither, despite all the rage and benefit, is "business-IT alignment" the essence of IT management's focus on the business; that is really a business management issue.

- However, abstracting and separating the business and the information technology, the common challenge of managing IT is that IT's impact on business activity is so intense. In IT's role as a business "enabler", the critical success factor is the degree to which IT impact organizes the business rather than dis-organizing it.

Business management must step through the logic of that success. The logic has at least these three pillars:

(1) From the business perspective, for IT to be nutritious and non-toxic, the basic business need is to deal with what it is about the business that IT aligns and how IT does that.

(2) The responsibility for managing IT's role belongs to the business, not to IT. Responsibility for appropriate production within the role belongs to the IT management organization.

(3) What business needs IT to do in the business, just as business needs other functional elements to do, is to align economy and profitability, so that having one of them doesn't diminish the other. The way IT does that is to optimize capacity.

I.

The way business uses IT for optimizing capacity is by modeling business management of IT's impact through processes and portfolios.

IT inherently offers the kind of speed and scale with which a business must build and sustain capacity in today's marketplace. With capacity as a mandatory "given":
- Processes are responsible for economy versus capacity; and,
- Portfolios are responsible for profitability versus capacity.

Managing the contribution that IT makes through processes and portfolios allows IT to align economy and profitability through the organizing of capacity.

The huge top-level significance of that observation is in its implications for strategy and change management. Strategy presumes to model the competitive advantage that the firm can capture from perceived opportunity, while change management presumes to stabilize organizational resiliency and thereby keep the business positioned for opportunity. But in the effort to balance risk versus value, strategy reflects demand, and change management reflects supply, while neither must actually include financial optimization to be logically valid. The fact is that they both are simply designs that are fully able to get "their" jobs done while being benignly neglectful of financial stress. The organization actually has to figure out whether it can use these designs, but if it can't use them it doesn't mean they are broken; rather, just inappropriate.

Thus, with IT being such a dramatic enabler of both strategy and change, managing IT should in particular target helping to fit the strategy or change to the organization's terms of self-sustainability. In this regard, Process helps ensure that capacity is effectively useful, Portfolios help ensure that capacity is effectively directed, and IT supports both of them to get it all done.

II.

One analogy for this is that capacity is the "stored energy" or "battery" of the business. IT is what charges the battery. Consumption of that power is where processes do their work (economy), but the application of the power is where portfolios do their work (profitability).

By another analogy, processes make capacity into skills, and portfolios make capacity into value commitments. Furthermore, between those two, management creates behaviors, from which actual outcomes derive. Since the behaviors can either propagate or negate the potential of the skills to address the commitments, the benefits of skills (economy) may or may not apply to the opportunity represented by the commitments (profitability). Business management, through generating behaviors, makes the link, using decisions to deliberately leverage the skills for the commitments. IT supports that management, by literally incorporating the decisions -- that is, by making them "actionable" (functional) and thus producing behaviors.

In short, IT must produce resources; managers must deploy them, and the business must commit them. This perspective guides the assessment of IT's relation to both performance and return on investment. IT-generated capacity can give managers of business behaviors more options, but the value of the capacity is not created by IT -- rather, by the business modeling of both the consumption and commitment of the capacity. High performance presumes successful execution of good models, but meantime the models must be relevant to the strategy. Finally, strategy must be sensitive to the possible capacity that IT can generate, without arbitrarily "assigning" value to the possibility.

III.

In what follows over the next several iterations of this document or in other followups, we can illustrate that concept in more ways, as well as more specifically. For example, business process management (BPM), business intelligence systems such as configuration management databases (CMDBs), and performance knowledge systems like operational performance management (OPM) bring implementations of information technologies to more directly bear on the model-oriented management that optimizes capacity.

But the immediate general statement to be made is that the business needs appropriate capacity to address its desired opportunity; and it uses IT to provide itself with not just capacity in general but specifically with appropriate capacity.

Understanding business from an IT perspective is of vital importance to IT providers who must come up with useful resources. In that regard, superior architects power superior IT providers.

But more important is the flip side: understanding IT from the business perspective means understanding what business management decides to do with IT. IT management must take its direction from business management. The directions it takes are mapped out in processes and portfolios.

Posted by Malcolm Ryder at 7:52 AM | Comments (0) | TrackBack

February 9, 2006

Optimizing Business Services

"The more things change, the more they stay the same."

With major transformations of computing foundations happening about every seven years, this phrase doesn't seem to apply to the alignment of business and IT. Some industry writers point out that in many business organizations, by the time the enterprise was sufficiently mobilized to do client-server computing, it was practically too late -- because the internet had already arrived as the new baseline platform. For those organizations, this meant that the difference in computing from old point A to new point B was even more drastic.

But did these organizations do the same old thing with the new technology? Likely not. Executive commitment to new technology is more likely the result of first becoming aware that the right things to do now are different from the earlier things, and can't be done properly with the earlier stuff.

On the other hand, how about the parties that want to do business with the organization? Did they want the same things as before? Over the timespan of the technology transformation, new products and services were envisioned and launched in the markets, in some cases creating new businesses. Some of those new businesses were possible because the new technology made it viable to be a producer or provider of the new product or service. But all of them were possible because a customer, partner or other sponsoring stakeholder made it worthwhile to spend what it takes to create the necessary quality of the product or service. There was always a limit, though, to the amount of spending that is tolerated -- pressured not so much by the level of demand for the product or service as instead by the need for the "investors" to preserve their other ongoing opportunity.

In this scenario, spending on IT has had the very large burden of efficiently and desirably linking the timing and level of production investment to the level of quality delivered on demand.

This investment-versus-quality perspective sounds and feels like "cost-vs.-benefit" but it is primarily sensitive to the idea that both the inputs (investment) and the outputs (quality) are defined as "acceptable" by parties external to the organization. As it turns out, that imposes an excellently sobering discipline on the management of the spending -- and naturally there is then a question of whether management can live up to the discipline.

As an intermediary force between investment and delivered quality, managing the organization of information technology in the enterprise structures the spending allocations around business terms like "effectiveness", "performance" and "compliance" -- major indicators that the use of the investment is reliably headed towards the goal of delivering sufficient quality. For the recipient of the product or service, quality is not an imbedded characteristic of the product or service; instead, it is actually a measure of the compatibility and impact of the product or service under conditions of use. Producers can always aim for "good enough" quality, but they have to be diligently attentive to when and how the user raises, lowers or otherwise changes the standard.

We are generally accustomed now to thinking of IT assets synonymously with "investments", since the assets proxy for the actual original investment inputs. But in that, the inherent problem is the difficulty of assuring that the asset will in fact support outcomes that get measured as positively effective, highly performing, and reasonably compliant regarding the objectives of the associated stakeholders.

Effectiveness

To ensure that the asset does provide appropriate support, it is managed for its availability, its functions and its interactions -- through requisitioning, engineering, deployment and support.

The results of those management approaches are inventories, systems and processes that are used as building blocks for services that the business will provide.

The most general challenge in this management c