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


Chief Technology Officer

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

March 18, 2008

The End of Irrational Execution

Faisal Hoque, Chairman of BTM, appeared in Baseline Magazine with a brief discussion on the three elements needed for "Transformation: Inertia to Agility" (BTM innovates new business models and enhances financial performance by converging business and technology.)

As usual, Faisal offers a wonderful summation of what levers to throw and why to throw them. Here, he observes innovation, efficiency and abandonment.

Sound familiar? Perhaps the most interesting aspect of his article's proof point -- Amazon -- is that it shows how far we have recovered from the dot com era assumptions, particularly when it comes to understanding that in a business we actually have to get paid for making people happy. What Hoque really pins down, though, like a refreshed road marker, is that the "making" part is not the business, but is instead the competency.

Amongst the problems in the mix, the inertia that Faisal details is arguably the description of how business frustrates competency (“We have to meet this quarter’s numbers or we’re toast.” ), while on the other side of the coin Hoque highlights how competency, through enterprise architecture, can drive a business ("the first step is to get a clear picture of the entire enterprise...").

Meanwhile, that flashback we easily have on older preached wisdom like "Fail Faster!" and "Destroy Creatively!" still seems to apply, but the difference is that we have actual history on that now. The history begs the question, "why are only the exceptions successful?" Hoque's answer looks to be a turnaround on the old saying "If you don't know where you're going, it doesn't matter how you get there..." The turnaround is, "If you don't know how to get there, it doesn't matter where you're going." But we can't make the mistake of joining the casual crowd exuberance for "execution": the point is that enterprise architecture is the competency enabler that then delivers execution for the business.

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

February 6, 2008

Proof Politicizes Architecture

Management requires an ongoing accountability for effectiveness. Normally, this accountability is the recognized set of terms for "proof". The accountability includes some model of measures, and while the model may be good or bad, the agreement by interested parties to use the same model makes it the argument that counts the most, even if it is wrong.

The model then represents the ruling hypothesis about effectiveness and, in short, memorializes the belief system in place about how to make progress. This fuels, in turn, a prevailing culture of proof that casts its influence over the several necessary layers of enablement that allow for effectiveness to result. The problem is that this influence may be inappropriate, and to avoid being misled by it we need to know why.

The answer is that the layers of enablement are variables, and the combinations of their variations offers more than one path to effectiveness. To describe an occasion of how effectiveness resulted, we would monitor variations within threshholds on as many as seven layers:

  1. Effectiveness is usually a measure of the degree to which an actual outcome matches a desired outcome.
  2. But the outcome is a strength of reaction to an impact generated by some agent.
  3. The level of impact observed can itself be more or less than expected, or desired, or needed -- and often there is insufficient attention paid to distinguishing the three characteristics (which is what allows the seeming inevitability of unintended consequences).
  4. The cause of the observed level of impact is a state or an output.
  5. The agent of that state or output is a quality level of process.
  6. The runrate of the process consumes inputs.
  7. The level of supply of inputs allows the processing.

In this view, the bottom four layers predispose whatever can happen in the top three, which is why the bottom four are so routinely captured by the design of an architecture. But if the architecture is unfamiliar or expensive, the distance between layer 4 and layer 3 is quite large. The burden of proof will fall to the architect to demonstrate bridging the gap.

With some "proof-of-concept", the effort is made, but it must be accompanied by its own "concept-of-proof" that relieves it from the pressure of "measuring up to" the top two layers.

It takes gutsy decision makers, or ones with little to lose, to accept this -- rather than to impose the top-line measure as the justification for considering the architecture at all. Innovators and early adopters accept their proof points at level 4, while laggards are hard pressed to dig below level 1. Consequently, the architecture in question gets positioned on the spectrum somewhere between demonized and championed.

Posted by Malcolm Ryder at 10:37 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

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)

November 7, 2006

Be Careful What You Ask For, You Might Get It

Recruiting for "performance" relies of course on what is measurable, but even intuitively we know that an "unqualified" or "incompatible" or "misapplied" resource, if found, will be a key factor of an explanation for performance shortcomings.

The difference between potential, production, and performance is something often assumed to be self evident. Yet not only is the difference given final credibility only through "objective" measurement, but the gaps between the three points are actually seen as more important to manage than the three points themselves.

That is, resources are often seen to be *starting out* at one of the three points -- after all, we make a big point of "acquiring" them that way, whereas the real work (supposedly) is to get them to move up. Then, because we want an easier time of moving them up, we try to determine what characteristics at each level of acquisition are already the best predictors of a high rise.

From an analytic point of view, the question must therefore also come up as to why the predictors are reliable. In other words, if the predictors are singled out because of their association with desirable outcomes, is it because they are causes or are they just prerequisites?

"Development" is the generic term for engineering productivity from potential, while "management" typically stands for engineering performance from production. This brings up two more topics to consider. One: what type of resources are most compatible with development and management? And two: what kinds of development and management are best at moving resources up the value chain?

It's a fact that these perspectives essentially anticipate "processing" the resources -- but meanwhile the utilization of the resource becomes a third major dimension of the picture. That is, in the big picture, the Predisposition of the resource (its starting characteristics), the Processing of it (through engineering), and finally the Positioning of it (its utilization) will effectively decide how the resource relates to the outcome that we'll call performance.

In explaining performance, it thus becomes both notable and logical to discriminate -- not just suspect -- the point of failure or disabling constraint. In low performance, is the problem a resource? And if yes, then is it that the resource had a bad predisposition (low intrinsic quality)? Poor compatibility (hard to process)? A bad assignment (deficient position)?

In answering those questions, it will be necessary (for the sake of intellectual honesty) to identify whether the applied (or withheld) development and management was appropriate to the identifiable prospects for success. By prospects, we mean that we understand a rational relationship between what characteristics of resources should be opportunities for performance leverage -- and HOW they are opportunities.

Most often, sports provides a laboratory for observing how prospects fare. A resource becomes a part of a system, and may thrive or not. Superstar college quarterbacks disappear in the systems of losing teams that draft them and can't resolve a mismatch with the talent. Third-round draft picks costing orders-of-magnitude less money go to well-run teams that nurture a role or two in which the player becomes a league standout.

As architects of business processes know (and practice), the definition of a role is one of the two most decisive factors in process performance, with the selection of actors for the role being the other overwhelming determinant. It sounds like a simple idea, but the role definition and the actor selection turns out to be full of the nuance of interactivity, reliability, flexibility, strength and availability that finally accounts for whether the process runs well under the demand that is placed on it.

Given that demand is both variable and influential (some call it "pressure"), it cannot be ignored in the exercise of evaluating resources. The resource must help make an adequately sustainable process successful under demand. But the demand cannot be undefined. And the method by which the resource supports the process cannot be arbitrary. There's a way to make a sheet of paper hold up a brick, but you still wouldn't want to stand on the contraption if you had any choice. Yet both paper and bricks have their place in the makeup of a successful housing structure, as proven over hundreds of years of design.

Roles address the issue of whether a resource is a cause or a prerequisite. In a sense, a role says either "neither" or "both". In saying "both", the role means that the resource is integral to a system that produces the desired results, without saying that the system will necessarily always produce that way. Systems host processes, while the resources materially constitute the system. (Some might argue that systems "occupy" processes, which is an insightful description of the relationship between design/process and the construction/system that "realizes" the design. Increasingly, this is being called "orchestration".)

The punchline to this is that the secret of excellent resource selection lies in knowing the architecture that accounts for why outputs and outcomes can be predicted. In that architecture, the roles given to resources are part of a framework that helps point out when a resource is going to readily fit into the value chain of potential to production to performance.

Roles strongly help to define the prospects. In recognizing that the prospects may be quite idiosyncratic to the given organization, it becomes apparent that two very similar resources from different organizations may not amount to the same prospects at all -- and before these resources are acquired they should be evaluated as prospects of the future, not as products of their histories.

Posted by Malcolm Ryder at 11:45 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

February 1, 2006

The Enterprise Logic of IT Investment

Managing the enterprise features such a high degree of complexity because by its nature the enterprise tries to grow amidst enormous possibilities of internal and external change.

The internal health of the organization, and the external growth of the business, both rely on great systemic coordination.

The overall view of the related dynamics is often shifting or obscure, and in learning to cope with the variations the enterprise focuses on how to adjust to the moment in ways that aim to sense future conditions and engineer future events.

The combination of increased awareness and increased ability protects its prospects for continued health and growth.

Visibility and controls are strong proactive correspondents to the desired awareness and ability. The enterprise's proactive stance on protecting its future opportunity is reflected in its vocabulary and institutions. It propagates its stance mainly through communications and procedures, and it formalizes those means in the way it promotes and tolerates management. But then it defends that formalization, and implements it, by deploying IT.

The high-level description of that enterprise management is fundamentally the same for most enterprises. In the following picture, the essential storyline of enterprise action is shown as a matrix of management topics that describe how the enterprise systemically associates its action with its expected challenges and desired outcomes.

Notes:
All of the terms in the illustration can be prefaced with the word "business". This is because the purpose of the idea or concern that each term represents is to support the business. As an example of how this applies, however: if "requirements" in the IT arena are under consideration, this illustration is about what the business needs to get from those requirements being handled in IT.

1. The semantic separation of Performance, Execution and Operation is crucial to understanding how the organization and its stakeholders recognize opportunities to affect the future. The table shows that each perspective has its own type of goal. Understanding the differences between the types of goals is superficially easy, since they tend to come from different sources. Only for example: standards may come from experts; requirements may come from partners or customers; and targets may come from executives or investors. If a change occurs to one of these goals, the point is to realize where it will have impact. Change to Standards will affect production. Change to Requirements will affect execution. Etc.

2. The Benefits column shows what the activity is intended to be all about. Additionally, it shows the critical linkage provided by process management and portfolio management. These two disciplines create the channel that converts operational investments into managed impact on business performance. (Shown in the Benefits column, the two disciplines are placeholders for the artifacts that they also represent; the enterprise typically wants to achieve and improve processes and portfolios as negotiable products or holdings, not just use them as conceptual models or tools.)

3. The difference between Production, Progress and Achievement is as follows: production is the shape of the activity; progress is the output of the activity; and achievement is the significance of the output in the context of what the organization is trying to deliver to its stakeholders. All three of these are factors that may be individually found "positive" or "negative" compared to expectations or plans. But that status may or may not directly correlate with the actual effect that the factor has on the economic prospects and risk prospects. The "systemic" nature of the enterprise is that success on one level increases the likelihood of sustainable success on the level above it. Negative factors decrease the stability of the enterprise, making it less able to proactively maintain suitable levels of desirable influence on future conditions.

4. Economic Prospects can be understood both literally and figuratively. To make this point clear, first assume for the sake of argument that all activity is about dollars. In this case, economy is about dollar consumption; capacity is about how powerful the available supply of dollars is versus spending needs; and profitability is about how many more dollars of better-than-previous-power have joined the supply. But in a second case, assume that all activity is about a different asset, such as "knowledge". In this case, economy would refer to the percent of the retained knowledge that has frequently high practicality; capacity refers to how much of it has frequently high relevance; and profitability would refer to how much more of the knowledge is usable by how many more users, compared to a previous time or population.

5. Risk Prospects identify the primary source of challenge to what the activity is trying to control. There are two kinds of comparisons to see here. One kind compares the Risk to the Measures, illustrating that the momentum and probable success of the as-measured activity is very sensitive to the risk. The other kind compares the Risk to the Benefit. The variability of the risk factors can alter the level of benefit and/or alter the degree to which the level of benefit matters to the economic prospect.

Posted by Malcolm Ryder at 2:42 PM | Comments (0) | TrackBack

December 9, 2005

Complication versus Complexity: getting Business Value from ITIL

Architecture is what you bring to the party when: (a.) what you want to build requires moving parts but (b.) the diversity of parts resists effective interaction.

Some may say that this is what engineering is for. But engineering determines how the parts should work together, whereas architecture determines what kind of parts should work together.

In that light, we can see that engineering and processes spend a lot of time with each other, organizing functions; meanwhile, architecture and assets spend a lot of time together, organizing resources. Both must make strong contributions to the whole. But it's not just the intensity of their contribution that counts. A special characteristic of architecture and engineering is that they are not about reducing complexity; instead, they are about reducing complication in order to exploit complexity.

Complication features lots of parts whose relationships inhibit the coherence of the whole. Complexity features lots of parts whose relationships enable the coherence of the whole.

I.

Within "operations", co-operation of parts is necessary for the same reason that it is in buildings: a structure is asked to enable functionality that requires its parts to support each other under the varying pressure of "customer" usage and environmental conditions. In operations, it's typical to see processes and systems as component parts.

In business terms, the support-problem that architecture addresses is a balancing act: there are constraints (or restrictions) on what parts are available, yet the blend of available parts must offer a way to provide persistent support of the expected business requirements. From the business perspective, this support is the operation's functional integrity, which depends on whether the quality of its parts supports the functionality demanded from the structure. The basic idea is not hard to grasp: in general, the components of an "automobile" are well known, but you can't make a good jeep from the parts that are best for a family sedan... When you need a jeep, even a perfectly good sedan won't do.

Operations view their underlying individual processes as structural components. Bringing together the aspects of availability, persistence and effectiveness, architecture's selection criteria define and drive utilization of components that are suitable in business terms as resources for operations.

Thanks to architecture, operations assume that the underlying processes can successfully co-operate under presure. This success fosters opportunity for the business. But the mandate for cooperative processes lies not in the opportunity but rather in the needs of the business.

In IT operations, management must coordinate the provision of IT resources against business need, through measurably meeting requirements for availability, persistence and effectiveness. The provision is structured with management processes, so it is logical that an architecture would organize the processes to be used.

II.

IT's management has an architectural reference for this.

ITIL (the IT Infrastructure Library) is generally describable as:
- a framework of
- processes that are
- combined to operate
- the management of IT
- as a business.

The framework directs the identification of types of processes appropriate to the business performance of IT management.

The concept of "business performance" revolves around the complex goal of:
- maximizing benefits and minimizing risks, from...
- an optimized balance of services and costs used to...
- efficiently respond to business requirements and business demand.

The output of that effort is a virtual "product" (provision).

When business needs are prioritized, decisions to act on the priorities creates demand. Response to the demand is allowed within certain tolerances which are identified as requirements. To ensure that provision is appropriate, operations must understand and work in terms of both the requirements and the demand. But what it produces from that must furthermore align with the needs of the business.

The complexity of that performance reflects a three-dimensional view of value that the business wants to receive from the IT management effort.
- benefit/risk ratios (quality) pertain to the choices that the business has for its supporting enablement
- service/cost ratios (economy) pertain to the effective supply-level of support
- response efficiency (availability) pertains to the reliability offered to the business.

The key corresponding challenges are:
- Change (versus quality)
- Expense (versus economy)
- Speed (versus availability)

The business looks for competitive advantage in those same three challenges. Its ability to exploit them repeatedly is what sustains the business in advantageous positions. But most businesses have to consciously make all three factors work together, as experience shows that they will otherwise mutually interfere.

III.

The proactive outlook on this need is most often now described as a business pursuit of agility, productivity and regulation based on operational support. These "business success factors" become objectives for operations.

Agility balances change and speed.
Productivity balances change and expense.
Regulation balances expense and speed.

On the flip side of the coin, the protective or pre-emptive outlook can be described as the following business pursuits: resilience, capacity, and continuity. Likewise, these become objectives for operations.

Resilience is a balance of change and speed.
Capacity is a balance of change and expense.
Continuity is a balance of expense and speed.

Using these as objectives, and keeping in mind that these are descriptions of the business itself, operations drive towards "performance" that creates those significant differences to the on-demand conditions experienced by business. Those differences are the "business value."


For operations, the question is, which processes should be used to support the effort to meet those objectives?

IV.

In ITIL, a set of key management processes for the business use of IT functionality (a.k.a. "services") are identified and labelled in a very consistent way, using a standardized vocabulary that is applied across all descriptions. The vocabulary is extremely important for distinguishing the processes relative to each other, showing clearly where the various processes share and don't share specific responsibilities.

But the vocabulary is not the framework. At a higher level of distinction, ITIL separates operational provision into categories such as "delivery" of product and "support" of product. Those general responsibilities are then articulated with up to five pertinent management processes, each -- according to objectives that represent the business demand and business requirements for delivery and support.

What we want to understand is how the ITIL-identified processes address the six objectives we have outlined above:
- agility, productivity and regulation; and...
- resilience, capacity, and continuity.

The reason for this mapping is to describe the generation of business value from the ITIL-designated processes.

Our value mapping requires that we take the background concepts given for the six objectives as our main perspective. Those concepts pertained to the business challenges that indicate "success factors" to be managed in the business. Value is perceived in terms of those success factors. Management processes support the performance of operations that generate the business value.

Among those factors, agility, productivity and regulation together tell a story of the business capability to exploit circumstances.
Meanwhile, resilience, capacity, and continuity together tell a story of the business capability to bring resources to the occasion.

Both stories are about business effectiveness in the path the business chooses to execute and meet the requirements of its mission. The success factors do not pick the path, but they provide terms by which to plan and assess it. Management processes should be contributing, accordingly, to the planning and assessment.

Giving a general assessment by "stories", we have the following setup of ITIL-named processes.

Now we can reiterate a related earlier observation in more detail. The business support-problem that this architecture addresses is a balancing act: there are constraints (or restrictions) on what processes are available, yet the blend of available processes must offer a way to provide persistent support of the expected requirements.

Blended support suggests process integration, but the more essential move is to orientate the processes to the same objective. Integration is one approach, but negotiation and collaboration are also useful and might initially be more practical.

On the left side of our grid we have processes that address the aspect of agreements and permissions that effectively predefine the usual responses to demand. This impact is what is in common across agility, productivity and regulation; it answers the question, "what are my optimal response options?"

On the right side we have processes that, largely through policies and risks, define the effective characteristics and sources of the resource supply. Running in common across resilience, capacity, and continuity (as we defined them in the discussion), the key question is "what can I count on using?"

Those questions make it even more evident that the management processes must "account to the business" -- by addressing the questions in both planning and assessment.

V.

Business needs come with constraints.

Everyone always wants to satisfy needs with something that has the legendary features of being fast, cheap and pretty -- but the solution most likely obtainable by the business may fall short, while its acceptability -- its value -- is no less described in terms of demand. Managing IT for business enablement can be a "high-performance" activity only when it addresses that demand.

Returning to the discussion's initial description of value, performance reflects a three-dimensional view of value that the business wants to experience from the IT management effort.
- benefit/risk ratios (quality) pertain to the choices that the business has for its supporting enablement
- service/cost ratios (economy) pertain to the effective supply-level of support
- response efficiency (availability) pertains to the reliability offered to the business.

Every business can relate to choice, supply-level, and reliability as the dimensions for evaluating anything from assets to resources, opportunities, and partners. The business always essentially tries to determine whether it has the preferred relationship with these things, and makes changes according to its findings. Detecting and metering the dynamics of value-delivery can be exhausting and esoteric at worst, but managing things towards business value begins with understanding groupings of efforts whose interactions logically produce impacts on desired conditions.

Within the ITIL framework, management processes improve important attributes of IT services themselves, such as service availability, service configuration, or service continuity. But it is the difference made through the service utilization by the business that then counts as improved business attributes -- including business availability, business continuity, etc.

VI.

Aside from details on the internal design of management processes, ITIL provides a perspective that identifies the IT organization as a managed producer/provider with a known customer. This responsibility sets up the compelling logic of the process groupings that ITIL presents. Yet most organizations still find it difficult to prioritize and maintain their ITIL adoption strategically. The substantial difficulties of developing the individual processes to an effective state are superceded by an even bigger challenge -- lack of a model of direct systemic impact on the character of the business, which is what drives the top line instead of the bottom line.

Top-line benefit is the strongest rationale for taking on the profound risks of organizational change associated with management process reorganizations, such as ITIL. Accordingly, the most important framework for the effort is a business value framework, which should then be the basis of managing the adoption initiative as well.

Posted by Malcolm Ryder at 10:37 PM | Comments (0) | TrackBack

November 11, 2005

The Architecture of a System

The State of New Mexico Office of the CIO looks at why a CMDB connects architecture to operations in an excellent graphic that is led off with the following statement:

"The architecture of an information technology (IT) system is the structures of the system, which comprise software and hardware, the externally visible properties of those components, and the relationships among them."

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

October 18, 2005

Generating Network Value through Services

When Network Computing magazine recently changed its name to "IT Architect", it triggered recollection of this observation: a network is a coveted environment, so we emphasize the quality of that environment; but the value of it is in the design of its usage. Why is this instance of stating the obvious any more interesting now than during the last few years?

I.

In answer, one general thought is this: now, a huge proportion of our assumptions as productive people, about achieving needed performance, rest on embracing at least an abstract notion of "networking" -- sometimes on multiple levels of operation. Whether our management agenda is about job-hunting, workgroup teaming, espionage, market collaboration, or distributed industry of any kind, the presumption is that prevailing performance level standards for "success" will require interconnectivity that generates synergies (more bang per buck) and that overcomes (i.e., navigates) environmental complexity.

But why consider networks in any expanded sense? Because, a failure to acknowledge organizational principles behind a network leads to lost opportunity and an inability to resolve problems inherent to "networked" environments -- which, because of the above noted reasons, are becoming the rule (not the exception), if not ubiquitous.

Practically, we approach a network as a production environment for some work to be done. And typically, the reality is that as individuals we encounter networks that are already in place. So we have to learn to use the network, i.e., to train ourselves. This accounts for the regularity and range of what we do.

But the mere fact of interconnectivity does not "make a network work." Instead, we think that the network is working when it turns out that it enables what we want to do. Admitting this tells us that we don't think a network is valuable unless we expect it to satisfy our requirements. How do we get the network -- whether it is an information system, an organization, a knowledgebase, or whatever -- to meet those expectations?

We train it. That accounts for the regularity and range of what the network does.

II.

At face value, labels that switch from "computing" to "architects" seem to shift attention from usersto providers. But more importantly what happens is that thinking shifts from the increasing momentum of experiencing the network as a "place" back towards seeing the network as a virtual construction.

Now we investigate the implications of training as the model for a type of value-adding dynamic construction or reengineering. Training designs behavior to correspond with requirements, and architects make the plans that render the design actionable. To "train" a network, an architect develops the network's enablement of services.

This is a shift that managers can appreciate. Before the shift, computing managers are struggling with trying to derive or rescue value through dwelling on network users' "negotiated experience" and its expensive preoccupation with remedial support. After the shift, they are focusing on "negotiated design" -- and its far less expensive preoccupation with planned services.

Because services optimally align the network user to the network capacity, we can take it as a general principle that services are what generates value from a network. Correspondingly, architects who enable services are on the critical path to the network's value.

Since we're considering an expanded definition of "network", two other thoughts related to that pair of findings also expand to capture familiar ideas in a fresh way. .

III.
First, we can readily see "architects" involved in all kinds of networks. The networks can be systems, teams, communities, and other entities that are formed from designing environmental interconnectivity to support distributed industry. The architects are engineers, coaches, policy-makers, and many others who we often call architects only after-the-fact; but we ultimately credited them with being the architects because they designed the interconnections we recognized that assure our prescribed requirements can be functionally met.

For example, the writers of Sports Illustrated consider the Hall of Fame candidacy of (as they state it) Lakers assistant Tex Winter, 81, the architect of the triangle offense and Phil Jackson's right hand man during all his championship years in Chicago and L.A.

Second, if a network's value originates in its services, how does the idea of a "service" pertain to small "networks" like teams? By analogy, this calls for understanding the "use of the team" -- as in what requirements the team must support. Here, the idea of services will correspond mainly to the "responsibilities" defined around the capabilities of the team, which organize the team to execute things relevant to the requirement.

Does this make sense? Well, as a demonstration, by stitching the two thoughts together we can ask, "what is my network responsible for?" -- and this leads pretty directly to defining services. On the other hand, if we don't know the answer to the question, then it is nearly impossible to decide what value the network has. Naturally, a trained resource is more valuable than an untrained one. A network is a resource.

Finally, it should be taken as words to the wise, that pursuing collaboration, social networks and other interconnected environments as an organizational strategy will likely yield meager results or even counterproductive ones if the services are not first defined for those environments.

(Note: the above comments are not intended to mean that IT Architect magazine has actually changed in any way other than in its title.)

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

Project Fault Lines in Implementation Designs

It's often remarked that "because humans are involved, there will be error." IT Architect magazine, formerly known as "Network Computing", offered up a practitioner's cautionary alert through Michel Labelle's report of two implementations that failed due to their project managers. What was the gist? One case featured unresolved disputes about specifications, and the other case revolved around confusion about how progress would be evaluated. In both cases, the PM's operational agenda simply didn't match the client's.

Labelle's lament on lousy project managers certainly zeroes in on the notion of human error. But without defending the project managers' obstinacy central to both of Labelle's failed implementations, it seems clear, too, that the PMs were making judgement calls about what constituted unacceptable risk -- not to the project or to the client but to the vendor, who after all is the PM's *employer*... Given that, the requirements of the implementation plan turn out to be quite different from the "service level agreement" assumed to be in effect by virtue of the contract. Labelle was really a victim of poor customer service, and the proper point of resolution should have been a business relationship manager, not the project manager.

This doesn't argue that there must be two separate people to handle the relationship and the project. Instead, it separates the roles in terms of responsibilities. One person may indeed play both roles, but in at least one role -- the business relationship manager role -- needs must take priority over requirements. Indeed, Labelle, a twenty-year veteran of implementations, points out this difference. But the ongoing issue is to design the conduct of the project so that at the outset there is alignment between the project's contract (the business agreement), its SLA (the service level agreement), and its requirements (the production agreement).

For a deeper consideration of this issue, see the related Archestra articles:
Why Projects Fail and Four Breakthroughs

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

September 4, 2005

Culture as Infrastructure for Strategy

Companies often refer to having and using a value system as the regular guiding influence of their culture on their operations.

We know that value systems are backgrounds for approvals, and it's easy to imagine a collection of associated approval processes representing the "system" of the values. In that case, regardless of the particular values targeted, the first purpose of the processes must be to manage the dynamics of approvals, dynamics that exist whether processes do or not. But how do processes get to know about those dynamics and thus recognize the inputs to use?

To identify and communicate about the dynamics, thus initially making them manageable, a value framework should already be in hand. But what does this framework look like?

I.

Creating the framework means taking a broad view of "approvals" -- we need to think in terms of what is accepted regarding the organization's actions and conditions. Naturally, this might involve a range of things like targets, standards and other definitions of desired states. In fact, determining those definitions is more important than the aspect of processes, because definitions must precede processes.

Nonetheless, the current surge of interest in performance management scorecards has everyone looking at a type of operational framework.

The good news is that performance is being talked about in terms of strategy being the value-definer for actions (operations). Seen by organizations as a driver of performance, strategy is wanted for its ability to define the difference that creates advantage -- the most high-level desired state.

But the bad news is that the actual results of actions -- which trigger followup decisions -- are often still not taken in a primarily strategic context but instead in a different (and strategically indifferent) way of defining value, such as cost control, timing, or compliance. The followup decisions -- especially about optimizing processes -- thus may not be aligned with the strategy although they are still reinforcing accepted notions of value.

Typically it's said that when strategy fails it is because of its execution, not because of its design. Organizations have plenty of hustle and flow, but evidently it's not enough. This makes us more deeply consider how it is that the execution would "make the difference" that strategy prescribes. What is it about the strategy and about the execution that makes their connection successful?

II.

This thought inspires us to consider the "quality" of the strategy in a certain way -- in terms of its effectiveness, its fit to its purpose, or in other words, its usability.

Since strategies don't just execute themselves, we have to examine the capabilities of the organization that is responsible for the execution -- both when we're planning before-the-fact and evaluating after-the-fact.

We can't take this notion of "capabilities" for granted: the most distinctive aspect of the word's meaning is "potential". What if the organization is not yet ready, or willing, or able?

Capability - A talent or ability that has potential for development or use... The capacity to be used, treated, or developed for a specific purpose. -- American Heritage Dictionary

Embracing this definition highlights an issue of compatibility between:
- the mechanism used to develop the ability -- namely, management;
and,
- the "raw material" to be shaped -- namely, the organization.

As a matter of strategy, managers direct the decisions and activity of their organizations according to objectives and policies. But even without a strategy, they manage that way as a matter of "best practices" in accountability. As a result, they not only exert a style but also formalize the operating environment in a way that we usually refer to as its "culture". The question is whether this culture results in appropriate organizational capability.

III.

Actual practice can easily fall short. Management style is usually expected to bringing energy, integrity and focus to execution. The natural focus is on maintaining a real-time match of requirements and abilities. And accountability for "performance" keeps the heat on management constantly. Unfortunately, accountability's concerns with "management style" can be counter-productive. Consider virtually any "Top Ten Management Issues" list from the last few years: too often it places heavy emphasis on the individual manager's activity inputs (awareness, decisions and intents) and hammers away on improvement there -- while comparatively neglecting the overall environmental outcomes also created (such as degrees of coordination, capacity, and complexity).

The complicated outcomes collectively called culture are so hard to grasp as a "whole" that we usually have to think of them the way we do a "climate". Climates require adaptation efforts, not control efforts. Through adaptation, some things are more likely to succeed in certain climates (or cultures) than in others. Here, the issue is the great extent to which management style (not the strategy) creates the climate -- through the way it handles objectives and policies.

IV.

Management intends to construct "effective" organizations. To count as a success, management style needs to make an organization that is compatible with the strategy but is also compatible with the climate that the management style itself creates.

We need to be able to discuss management's responsibility for adaptations -- for alignment -- as a counterpart to accountability for performance. Strategic compatibility -- a.k.a., alignment -- means that the culture must not inhibit the organization's approach to meeting objectives.

Pragmatically speaking, the "culture" is a description of how the management style has typically reconciled the opportunities to act and the approval of the actions.

Describing this reconciliation makes us consider both the nature of the organization's opportunities (in particular their sponsors, types, and locations) and the reasons for approving them (impact, importance, urgency). Here, the problem we encounter is that organizations have predispositions that are institutionalized largely through their managers, -- which creates potentialy high resistance to change. To illustrate that, the table below is a device for "mapping" the incumbent pragmatic culture, as typically under the control of managers.


Three aspects of approval make up the formula for describing, respectively, the sponsor, type and location of an opportunity. Each aspect represents a point of consideration and measurement, which may involve a precedent, a rule, a belief, a status, or some other quality that might function as a decisive criterion. Against the items in this mapping, both objectives and policies consider any potential change by asking the question "Why?" The terms shown within the table make it easy to see the many points at which existing objectives and policy could either frustrate or compete with new, different ones being introduced. Getting and sustaining "consensus" support across enough (much less all) of these points of precedent is never guaranteed. Where differences remain unresolved between the current and proposed circumstances, going ahead with the proposition carries risk. Therefore, to begin realizing the opportunity, someone must authorize and support the risk.

But this still leaves a gap to execution unless the organization is effectively mobilized.

V.

And to mobilize further across the gap to organizational effectiveness, management wants to deliberately rely on the culture as an "infrastructure".

Again, strategic compatibility -- a.k.a., alignment -- means that the culture must not inhibit the organization's approach to meeting objectives. That is, alignment needs management's combination of (reconciled) objectives and policies to provide a stable interface that the organization's members can use to consistently identify, anticipate and leverage opportunities and approvals for strategic action.

Strategy management -- through which execution is directed and linked to the difference that creates advantage -- faces the big question: Where does the consistency and stability come from?

"Architecture" is where we normally look to find a disciplined approach to building that compatibility. An architecture provides an integrated set of design and construction principles for developing a structure. Its principles guide the discovery and qualification of components needed to build a structure, and furthermore they guide support for the actual building effort. Those activities are commonly formulated into a production method.

When applied to making an environment conducive for (strategic) performance, the architecture's goal is to "produce" an infrastructure from that environment, which the organization will use as its interface for execution.

That's the hypothesis. Can the culture really be leveraged as a practical infrastructure, describing and guiding processes and agreements needed for desirable performance outcomes from the organization? If this is to happen, first the development of the interface must be managed.

VI.

An architecture in practical use is very often noted for, or even characterized by, both a style and method of construction that it generates. A challenge for managers is to use the architecture to find effective construction styles and methods, instead of imposing styles and methods exotically or incongruously on the organization.

One of the simplest forms of architecture is a framework, something that provides a neutral reference and gets its value from being that way. Arguably, a framework is most often used to guide a construction methodology, by providing all production participants with a common way to coordinate their different perspectives.

To provide guidance, a framework offers dimensions. A dimension is a perspective on the various different properties of something -- in this case on the various properties of that environment envisioned for executing the strategy. The purpose of the framework is to describe key dimensions in relation to each other -- which effectively evokes, classifies and arranges success factors for the properties, giving them higher recognition and attention.

That said, a dimension might be hypothetical (a "what-if"), or it might be discovered by trial and error. Accordingly, some of the framework might consist of theoretical factors; and some of it might feature empirically validated ones.

In the case of an organization's strategic alignment, the framework's job is to bring explicit consistency first to reconciling objectives withpolicies, and thereafter the various reconciliations with each other. In practice, a methodology exercizes this consistency, producing regularity (dynamic structure) in operations.

Managers work from that situation to develop the execution potential of the organization in that environment. Successful outcomes encourage repetition and reinforcement of their related management events; and the overall "learning" informs further progressive development.

VII.

The interpretation of the culture into an infrastructure provides the logical foundation needed for building execution that can focus on the differences that create advantage. Focused on making the difference, opportunities must be important, and approvals must be rational -- but they both must leverage the culture for sustained support.

That scenario depends on management's ability to associate opportunities and approvals with perspectives that coordinate the organization with the operational environment.

Guiding the construction of those associations, a framework offers dimensions for describing the terms of reconciliation that combine objectives and policies with each other. But the framework dimensions must account for the dynamics of the construction.

The diagram above highights the basic problem that management encounters in moving from opportunity to approval to action: - goals are the desired future conditions. They can represent the "why" of an idea, but they are constrained by the mandated support of the current state. - opportunities are the proposed "realization" of goals. They can represent the "how" of an idea, but the reality of opportunities is constrained by how the organization is allowed to function.

These realities of mandates and tolerances -- which come from various pressures including financial, political and intellectual ones -- complicate the (procedural) determination of just how "important" or "rational" things are.

The diagram above illustrates reconciliation -- showing the true direction of influences when the incumbent organization will be the resource for the execution of a strategy.

For strategic alignment, the picture raises the question of whether the objectives and policies initially in hand must be compromised or not on the way to execution. Although we intend to derive requirements from objectives and then execute on requirements, we can't get that done until incumbent policies and abilities have had their say.

VIII.

This multi-variable equation may go through many iterations of "if...then" before being resolved -- whereupon finally the resolution can be executed; but the question is whether the resolution is adequate to the task of realizing the strategy. Is the execution, as based on the resolution, capable of solving the right problem?

In that light, it's clear that the organizational ability finally offered to the strategy must be developed for the strategy in the intermediary stage.


In handling risks and priorities, a progressive development effort in "strategic capability" should incorporate four coordination practices:
- business analysis,
- change management,
- resource optimization, and
- assessment.

These each provide a perspective that is part of "framing the culture". Each of these steps brings the incumbent organization closer to alignment with the needs of the strategy, but all four of them must be directed at the particular strategy instead of merely at the desire to come up with something approved to do.

Meanwhile, each step also tries to coordinate the organization with the operational properties of the environment:
- rules,
- knowledge,
- events, and
- communication.

As part of the framework, the properties will complete the stable reference picture of the "cultural" dynamics.


Management can use the framework to research and specify expectations, preferences, responsibilities and roles that directly address the elements of the strategy. This provides an opportunity to formally communicate the value system that the strategy needs for getting organizational alignment.

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

August 25, 2005

Alignment, Configuration, and Enterprise Architecture

According to Telelogic/Popkin, the brand leader in enterprise architecture management solutions, "BUSINESS MODELING enables you to realize an advantage over your competitors. By accurately knowing how your business runs, you can enforce efficient processes, and change not-so-efficient processes to make your company more cost-effective and adaptable to change than your competitors."

What that modeling includes and offers is very well explained in numerous publications and studies, such as Yogesh Malhotra's specific but introductory 1996 paper, Enterprise Architecture: An Overview. And after a few of those descriptions have rolled by, the thought that jumps to mind is not "what is business-IT alignment" but instead "why didn't architecture already do that trick?"

One answer to this question is that the business management team responds primarily to what it knows how to measure. In this case, that was a barrier. The speed and cost of business impacts from architectural practice are more evident in a contrast to architectural alternatives than they are from comparison of current period activity to previous time periods of equal length. Because financial accounting has dominated management culture for so long, that accounting mode of period-over-period measurement and response was naturally but mistakenly applied to architecture, giving unusable results.

Different architectures are like different game plans; we know that both can play on the same field, and for long stretches of time neither one may establish superiority in terms of the score. But game in, game out, the always immediate prospect is that one plan is more likely to offer up the game-breaker than the other; and the longterm prospect is that one plan is more likely to win more games than is the other.

Another answer to the question of architecture's delayed impact comes from the now familiar Tim Russert quote, "The older I get, the smarter my father seems to get." How is this an answer? Well, the quote attests to the fact that youngsters don't have the wisdom of their parents, and not having it, the youngster's naivete makes the father's wisdom invisible. Only experience allows the youngster to begin to recognize what the father already knew. Businesses have lost a lot of their naivete in the last four years, as global and scientific forces have brought many different game plans onto their field more frequently and persistently, exposing the weaknesses in the business model. Suddenly, the design-level flaws that architects had always wisely strived to prevent and repair are surface wounds that the business responds to with a proper urgency and respect.

So why is this response -- in particular the flavor called business-IT alignment -- most often invoked by names other than "architecture"?

Here, the answer is an apparent phenomenon that is just not obvious. The answer is that the business experience has to go through stages of maturation, and at different stages, the architectural issue tends to have a different driver or focus, and thus a different name.

We can track this maturation in a maturity matrix. Not to be confused with hierarchical "maturity models", the maturity matrix for the business finds it positioned within classic x,y coordinates of architecture -- functionality and reliability, or here, competency and responsibility.

In the maturity matrix, a business could at any point in time be:
- in the upper left quadrant (multi-competent, less responsible)
- the upper right quadrant (multi-competent, more responsible)
- the lower left quadrant (uni-competent, less responsible)
- or the lower right quadrant (uni-competent,more responsible).

The reason for that point of view is that companies often add functions to their existing arsenal, only to find themselves overwhelmed by the resulting complexity or by being stretched too thin in support obligations.

More typical, though, is a linear or trend-type view. In the historical pattern of 1999 to now, issues such as supply-side economics, hypercompetition and regulation have followed each other on a trajectory that tracks enterprise adaptation to the changing business landscape. In the maturing adaptation on that trajectory, the business goes respectively from getting to be really good at what it does, to being really good at more than one thing, to being able to manage the intricacy of its means for being good at more than one thing.

Correspondingly, one step in this maturation concerned itself mainly with process efficiency, which drove a focus on the supporting assets and therefore BPR and asset management.

A following step concerned itself mainly with innovation, which drove a focus on the supporting infrastructure and therefore e-business transformation and change management.

Now currently the concern is with control of the functional complexity, which drives a focus on accountability and governance, or performance risk management.

A logical next step will be portfolio strategy management, as the business learns to be more than one kind of business simultaneously.

By calling these episodes "steps", we suggest that in some strong sense there is progress being made. The notion here is that the mastery of enterprise architecture is incrementally achieved as the operating environment increasingly demands it. The fittest survive -- not because they "picked the right architecture", but because they have the ability to manage an architecture comprehensively, so that an advantageous architecture could be effective for them.


With related I.T. issues, progress comes along in like manner. Attention to the mounting volume and diversity of assets and resources has been progressing from inventory to investments to configuration and deployment -- while attention to proliferating functions has been progressing from selection to integration to policies and orchestration.

As a result, business intelligence is necessary for analyzing the underlying elements appearing in newer perspectives on business processing models. The need for this intelligence is stimulating new automation dedicated to logical information services such as CMDBs (configuration management databases) and simulation -- emphasizing the management arts of What Could Be over those of What Should Have Been.

For a closer look at this business intelligence see the article "The Conceptual Basis of Configuration Management Data", here at Archestra.

Posted by Malcolm Ryder at 12:00 AM | Comments (0) | TrackBack

July 20, 2005

Managing versus Measuring: IT's Value to Business Performance

At CIO Decisions Magazine, Thorton May serves up results of an excellent survey of approaches being used to understand the value of IT to the business.

In general, the results indicate that the practicing managers of corporate IT range hugely in their established opportunity and intent for representing the way IT impacts business performance.

The survey does not investigate what lies behind the opportunities, so we don't get into the availability of time and tools that create the "business-perspective" visibility on IT. However, it is axiomatic that the way you look for something determines most of what you can see. In that regard, "formulas" that represent IT influence are more important than the tools and time used to apply them.

The four most important "takeaways" of Thornton's discussion are:
- IT is pervasive in the business the same way that management is pervasive, so it may be illogical to try to isolate "IT value" as a single global variable except in the various specific contexts (occasions) of IT usage.
- There is a difference between "value" and "performance"
- Measurements representing IT influence are not always numeric.
- Too much measurement is more bad than good.

One possible cause of the persistent confusion about value in IT is that the effort to connect IT Value to Business Performance doesn't make sense until after the connection of IT Performance to Business Value has been established.

If IT outputs are first associated with conditions that the business defines as important to the business, then a logical representation of "IT performance" exists. IT execution can be measured in those terms of performance, thus a picture emerges of when, how and why IT contributes to the enablement threshholds that the business agreed are needed for business functions to have their shot at meeting business goals.

Thus having the "business value" of IT performance defined, managing IT execution is a straightforward effort to have IT performance meet business needs. As a start, this is exactly what should be represented by a service level agreement (SLA).

Then, the performance of the business is nothing less than the results obtained from the business's execution of functions enabled by IT's performance. Presumably, the business has some functional targets to hit, which will be how business execution will be rated for its value to the business.


The biggest issue emerging from this is the need to separate the business's achieved capacity of enablement from the business's achieved competency of capacity utilization. IT can provide the capacity of enablement, but (contrary to the mythology of automation) IT simply cannot make the business use the enablement wisely.

If the business does not have working definitions of those two things, that furthermore unfailingly distinguish them from each other, there is no reason to believe that IT's influence on the business performance can be logically designed, tracked or analyzed. Naturally, this also means that no attempts to determine ROI are actually meaningful; instead, they are simply sophisticated statistical fictions prone to being evangelized or rejected by company politics.

The only exception to that assertion is the case of IT actually preventing a business function from being executed -- a huge issue driven by the way that the business relies on IT. In this case, we think in terms of a "negative contribution" -- one that is usually either unexpected or not officially tolerated. But in this case, what is important is to not suddenly have a double-standard of measurement methodology. If the contribution measurement philosophy is based on describing how IT relates to intended consequences, then the description must also neutrally cover how IT relates to unintended consequences. As we do this, it is important to neutrally separate IT's relation to desirable consequences and undesirable consequences.


This neutral and comprehensive perspective, which prevents arbitrariness in political tolerances, forms the basis of understanding otherwise neglected issues such as opportunity costs incurred by the influence of one IT implementation versus another. Since the business is responsible for deciding on those tradeoffs, it is clearly a matter of management and strategy more than of IT per se. When "negative contributions" occur, they must be defined and recognized -- as the results of:
- either bad decisions or bad enforcement that should not be politically written off;
- or bad luck (such as natural disasters or external attacks) that probably should be politically written off.

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

June 25, 2005

Architecture and Strategy

Architecture designs spaces for functions.
Strategy designs functions for spaces.
OK, on with the show.

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

May 26, 2005

Business Process Management and Organizational Architecture: a performance ecology

This month, Gartner Group research chief Peter Sondergaard outlined the top emerging issues in Business-IT management, by identifying the already driving needs to:
"...foster greater business agility, to promote quick build-up and tear-down of business partnerships, to facilitate adjustment and deployment of resources where needed and to render harmless approaching danger well in advance of that danger's arrival," Sondergaard said.

We're accustomed already to the idea that processes must be readily modifiable to keep up with changes and risks. But a closer study of Sondergaard's statements yields two other survival requirements:

(1) repositioning and security capabilities: this will require a mature "sense-and-response" ability that exploits forecasting.

(2) re-organization capabilities: this will require a mature ability to "re-compose" the organization by exploiting a model of it components.

In a nutshell, a form of organizational architecture must drive suitable types of readiness.

Meanwhile, business processes will remain the delivery vehicle for the operational impact that creates business value. To users of a process, the process is virtually the organization... But forecasting and organizational modeling determine whether the business process executes effectively -- that is, in the right direction and at the right strength.

Said differently, processes execute with critical "ecological" dependencies on their environment.

This dependency can be described from two viewpoints. In one, any process is essentially a "behavior" of the organization that enacts it. In the other, the process is a "user" of the organization that hosts it. Either way, to modify a process and obtain effectiveness, the organization that enables the process must successfully adapt as well. The issue is to determine the nature of the necessary adaptation. Is it repositioning, reorganization, training/maturation, or a blend?

The more frequently or continuously processes must be changed to meet requirements, the more explicit it is that the logical purpose of a process is to "map" the current requirements to the current functional capacity of the organization. In this view, "successfully" adapting a process to changing requirements means that changes of the underlying organizational structure must keep up with or even precede changes of the process. (The lessons we have already learned about mapping requirements to organizations come from project management and product management, where the organizations are often shaped and managed specifically to conform to fulfillment of the new requirements.)

Here, it is important to see organizational "structure" as a configuration of functional capacity. The purpose of the organizational structure is to deliver the capacity, and the purpose of the process is to leverage the capacity.

Usually, the chosen configuration will be selected according to criteria of cost, risk, availability, scale, stability and durability. But those attributes really describe outcomes of the organization-in-use, as enabled by the interactions of its elements. To recombine the elements and predictably obtain the same (or acceptable) attributes, the elements must be identified in terms of the properties they are known to exhibit in interactions.

In powering business agility, forecasting and modeling are both going to be based on those interactive properties of the elements, which comprise the business' operating environment.

Organizational building blocks

The type of understanding that will exploit elements defined this way is akin to both chemistry and meteorology.

Chemistry is an especially compelling metaphor: we already recognize that preparing a chemical "reaction" is precisely how we proactively develop the solution impact that we seek. It emphasizes that the structure (i.e., the chemical composition, the "organization") hosting the reaction is the driver of the reaction, containing within itself the potential and also sometimes the catalyst. Accordingly, the prescriptions that are developed by a chemist reference what is known about the interactions of the chemical elements, to compose the offering. Similarly, we are entering an era that calls for organizational composers, working with or without automated help...

Meteorology is also a compelling metaphor because of its constant analysis of the environmental dynamics. Meteorological analysis accomplishes tasks by means such as distinguishing weather "elements" from weather "factors", by determining what underlying elements are interacting, and tracking how they are interacting when certain dynamics occur. The interactions of elements are factors; factors combine to produce dynamics; and systems of dynamics produce the common high-level weather structures.

Abstracting the components of an environment or state such as the weather, we might identify:
- Structure: a seasonal climate
- Dynamics: a rainstorm, tornado, wind current, etc.
- Factors: a high-pressure system, cold front, etc.
- Elements: air, water, heat, etc.
Although we still can't control the weather based on what we know about it, we understand much about the near future weather because this analytic discipline helps us to model it and forecast it in advance.

Decomposing a business's internal organization this way, the business can then plan for the organization's states or behavior just as we might plan for the weather's, and exploit reorganization. Likewise, decomposing the external environment of the business helps with making decisions about where and when we can best "locate" ourselves to accomplish what we need or want, repositioning as needed.

Process architecture

Linking elements to factors to dynamics to structures is an abstract design technique. It can produce architectural models that are:
- the prescriptive composition of the business organization; this addresses the need for a re-organization capability
- the projected state of a business environment; this supports a repositioning capability.

Here is a diagram about composing an organization:


The picture gives an example of the many-to-many relationships that build up an organization, from assets to resources and so on.

In effect, a running business process issues requests that must intelligently "invoke" a certain configuration of these relationships during run-time.

The "intelligence" includes rules, permissions, and qualifications of various kinds. At run-time, if new items have entered the picture or earlier ones have changed or left, some of these rules, permissions and qualifications might need to be discovered on the fly, to assess and accomodate the differences from expectations.

The same approach can describe external environments as well as internal organizations; for example, a market space might be decomposed into:
- (structure) channels and partnerships
- (dynamics) campaigns and contracts
- (factors) products and services
- (elements) features and property

This market decomposition would exhibit the same many-to-many relationships of one tier's items to the next tier, whether going up the hierarchy or down.

Process-driven architecture

Leveraging that architecture, a business process requests a real-time configuration of an organization. The process always anticipates the potential for effectively exploiting the organization to meet the expected current or future state. But that anticipation is not always satisfied.

As business process management(BPM) increasingly centers itself around a business analyst role (performed by a manager or other employee) and expands that role across functions, it also extends itself into a request-management function that wants to ensure the satisfaction of the request with available and approved resources.

The key challenge in the request management effort is to determine whether the request can be satisfied through an existing organization or must be through a "reorganization" that makes acceptable resources available. The challenge for the analyst is to get the process to make the optimal number and type of requests in the available environments.

If a reorganization is suggested, it is likely not permitted until the request has been assigned a priority that effectively authorizes the reorganization for the request. (This prioritization typically comes from strategy and performance management.)

In this scenario, "orchestrating" resources brings selected factors into play, enabling the dynamics that a process attempts to manage. The orchestration is the virtual real-time organization. In effect, the organization becomes a resource agent for the process. And that orchestration comes with scale and scope issues that must be assessed for their implications in cost, risk, stability, duration, etc.

Which came first: the chicken or the egg?

BPM is evolving (expanding)into a complex of practices within which the design of the process prescribes a solution for the delivery of business outputs, and that prescription requests a fulfillment through organizational functions.

In that way we can say that the targeted process catalyzes the organization. But at the same time, those prescriptions are speculative without knowledge of the organizational potentials, and speculation is a risk to business efficiency and effectiveness.

Necessarily, the attending organization may be a "just-in-time" organization derived through bidding, collaboration, or the standing availability of a qualified outfit (whether internal or external).

What's especially important to note is that the criteria for selecting or composing the organization should effectively function as architectural standards looking for compliance by the actual organization that winds up engaged with the process.

These ersatz standards must be validated against evidence of the business' tolerance for them. We can't always get what we ask for, and we have to be careful because we might get it!

Why "architectural"... ?

By demanding certain combinations of cost, scale, scope and duration, the criteria effectively specify what capacity can be expected from given organizational (structural)configurations. The business must agree to those expectations, or seek sufficient capacity through whatever means available. The issue is whether the specification is too constraining or not.

In that way we see that architecture is actually what is being exercized. Far better that this is understood from the start than to encounter it as a barrier. The challenge is to apply architectural discipline proactively, yet in a manner that is calculated to maximize the ability of processes to obtain the organization that they need on demand.

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

May 4, 2005

Revisiting the Operations Trinity - People, Process and Technology

The "holy trinity" of operational effectiveness has, and will go on having, a long tenure. Getting people, process and technology working together is the goal and advice of nearly every expert on business systems; and it's one of the most familiar mantras of management.

The conventional advice about coordinating this triplet is the kind of expertise that is more recounted experience than it is privileged knowledge. What it describes is predictable "common sense" from the point of view that effective business action results from careful process designs being operationalized by the right people using technology appropriately. This is a familiar line of sight.

But in an alternative and somewhat more formalized view, people, processes and technology are each considered "business assets" that need to be managed. Company departments want to "own" stuff. Their logic for dividing responsibilities and authorities into sub-units of the organization presses forward a requirement to control the internal distribution of enabling assets -- even moreso than effective business action calls for the integration of the assets. Ironically, this "control" creates inconsistencies and silos that frustrate enterprise visibility of resources. Additionally, it leads to duplication of efforts to integrate them as described above.

Although those "component" integrations and "asset" allocations each have a loose end of their own, they are often believed to be resolved with each other in settling the question: "how do we get 'finance' to support 'engineering' ?" This kind of reconciliation produces some number of agreements indicating what to worry about no further or what need not be fought over. A balance of political and economical concerns might be struck. But that doesn't instruct on how to align our famous triplets for successfully driving business value...

Mixing Apples and Oranges

Thus, despite the easy rhythm of the mantra, its suggested coordination can't be taken for granted.

Here's a third problem: processes are complex constructions created by the business, that institutionalize certain behavioral characteristics of the business.Unlike people and technology, processes do not simply arrive autonomously intact into the business action scenario. So, to "align" them with people and technology, how do we proceed? What transformations are necessary in order to blend them together?

These days, thanks to ASPs and "built-in best practices", we're tempted to think and even say that most processes actually are selected off the rack and then tailored to the business. In that way, it appears that processes are in an asset class that also includes already-skilled people and pre-formulated technology. The idea is that the business doesn't design people or technology, and increasingly it really doesn't design the process either -- rather, it chooses, customizes and "implements" all three of them.

But to hold that position, it's necessary to be fairly explicit about what is covered by each term. For example, is "technology" supposed to include homegrown applications, printers from HP and hammers from Sears? With that breadth, talking about coordinating technology with processes and people doesn't advance any particular idea very much in the direction of better management. Instead, it just reiterates the common-sense awareness of a need -- namely, to somehow organize their interaction in an accountable way.

Ordinarily, the advice regarding blending these items does specify what form of each one is in question, and go on from there to promote a coordination methodology. The point is that we have to decide what each term of the holy trinity really is or really means, before we can know what to do about it.

We know that each term attempts to identify an essential building block of a capacity to operate (on business requirements). Each term of the triplet is at least a placeholder for some fundamental item.

What if we logically "normalize" the people/process/technology triplets, so that the scope of each placeholder is inherently comparable to that of each other's? Wouldn't that generally help clarify what kinds of management will be called on to guide and sustain their coordination? Let's try.

Processes are actually complex constructions of choreographed events. In effect, processes are a description of how to use events based mainly on where and when they should occur.

Likewise, the choreography of people describes how their positions relative to each other are "prefigured" to support certain interactions. Assignments create this arrangement.

Choreographing technology means deploying it in a way that its on-demand availability gives real-time support for functions. Configuration prescribes this situation.

Coordinating levels of management

Those observations give a new version of the triplet to use: People/Events/Technology is the new component-level triplet. Once we start this, we can follow suit as in the chart below, which summarizes the overall business view of the architecture for operational business value:


Copyright 2004 M. Ryder

Assignments/Processes/Configurations become infrastructure-level identifiers related to the more "atomic" elements of people/events/technology.

A key outcome of that "normalization" is that it clarifies the management coordination steps up to the necessary levels of value, such as a third level -- a production level -- where Relationships, Operations and Resources live. This is the level on which the business starts defining the conditions that strategically support the type of opportunities it deems "valuable" (or literally, value enabling). But stepping up to this level is not just a simple matter of promoting "assignments" as relationships, "processes" as operations, or "configurations" as resources.

Instead, relationships, operations and resources are each perspectives, with each given perspective addressing all three of the elements on the level below. Relationships present requirements to the coordination of assignments, processes and configurations. Likewise, Operations present requirements, and Resources yet another set of requirements.

The requirements are generated from objectives that have been established for each of the perspectives. The objectives represent the business's idea of how it can develop and sustain advantaged positions for growing and changing -- or in other words to benefit from competing, from producing, and from consuming or exchanging assets. This points to one even higher level of consideration.

At the fourth and higher level of concern, we find the business defining itself as an entity, through identifying Accounts, Services and Portfolios -- managing them separately and in relation to each other, for bridging market-level demand and supply.

Here again, each higher level item is a perspective on all of the items in the level below. Accounts establishes an agenda for relationships, for operations, and for resources. Likewise, the Services and Portfolios perspectives establish their respective agendas for each item in the level below.

Posted by Malcolm Ryder at 10:35 PM | Comments (0) | TrackBack

March 16, 2005

The Nature of Management

Management likes control. In most business organizations, operational control is a packaged deal - a bundle consisting of a core uncertainty, wrapped in tolerances, wrapped in procedure. Because control is established that way, whether the wrappings are looser or tighter, it is often only the procedure that is detectable evidence of control.

What's more, procedure is often the only evidence of operational consistency -- that is, something that managers want to be accused of when things do work, and want to not be hostage to when things don't. But managers should not -- must not -- mistake procedure (nor superficial consistency) for management.

A business likes to take it for granted that certain things are possible because managers have other things under control. This is similar to assuming that you can get to work in the car even on a pretty stormy day. To dramatize this assumption, imagine an angry person driving a powerful car on a bumpy road in the rain -- altogether an operating environment of at least four pretty major forces interacting: temper, motor, surface variation, and weather. We might even think of each force as a "system".

But first facing facts, the commute is all predicated on the notion that these four forces will interact within a usable range of uncertainty, otherwise the deal is off. The combination of forces may at any time become fundamentally unsound for the purpose of completing the travel. Each system is capable of independently excelling at what it does but likewise interactively throwing the overall driving "environment" out of whack for the intended purpose.

All environments have a deep structure that is simply:
- whatever forces are in the environment;
- whatever types of dynamics are generated by those forces;
- whatever types of regularity there are to the dynamics; and
- whatever interactions between those dynamics is likely to be generated by their regularities.

And then there's management. Basically, management brings interventions to the "natural" scenario that develops from the existing forces. The most useful way to account for these interventions is to simply call them tasks.

Broadly speaking, tasks either help to navigate the environment or help to reengineer it, usually by acting on the dynamics. Introducing counterforces that redirect extant dynamics is always popular; changing the systems that generate the forces that create the dynamics is also a well-worn path. On the other hand, anticipating their patterns and threading through them or leveraging them is the minimum requirement.

To more fully imagine those options, think of any operating environment as a pool of magnetic syrup, in which the manager can introduce fences and gates; steps, pits or inclines; heat or cold; and of course, more magnets. Performing tasks that distribute these interventions in one way or another, managers get the environment to more or less take a desired shape with a desired level (or degree)of stability. The logic of the tasks and distributions is the design. The purpose and duration of the shape is what lets the business do what it is trying to do -- or stops it. The manager's responsibility is to keep conforming the shape and duration to the real-time needs of the business, in effect, to exercise continuous deployment of productive interventions. Because of the frequency of business change, uncertainty is always a given whereas procedure is not. And this is why, in management, design is both more powerful and more essential than procedure.

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