March 3, 2011
Remodeling the IT organization as a Services Provider
The strategic challenge of an IT organization's remodeling for the future is that it wants to become an organization whose agility is actually the key to its ability to deliver relevant, quality-assured services.
In a simplified view, the difference between a departmental structure and a business unit structure is, essentially, the lines of operational reporting required to account for the objectives that distinguish the department from any other department, or likewise the unit from any other unit.
Departments have responsibility mainly for managing operational resources that support business functions.
Business units have responsibiliy for accountable functions that map directly to business policy and business performance targets.
When an IT organization arranges itself to operate like a business, it will become policy and performance oriented in terms of the targets for business compliance and business impacts in the relationship that the business has with its customers and partners.
Talent within the IT organization will need to be assessed in terms of the roles that staff need to keep operations flowing towards business compliance and business performance.
As a result, the concept of operational performance metrics comes to the fore. These metrics attend to how selected methods of activity succeed in operational events and time periods for which outcomes such as compliance, customer satisfaction, efficiency, and customer retention are known to be good.
When it comes to talent in the IT organization, four key flavors of interest will map to those same outcomes:
- Compliance comes under risk management
- Customer satisfaction comes under requirements management
- Efficiency comes under resource management
- Retention comes under relationship management
Expertise in risk, requirements, resources and relationships is therefore fundamental to any notion of talent in the organization; and execution of course will rely on practical skills applied under the guidance of the expertise.
The combination of expertise and practical skills will be what most people think of as "competencies", so it is fair to construct a framework or at least an outline of the valuable competencies that must be available to the organization.
Conventionally, we have thought of "skills and experience" as the way to characterise the relative value of a staff member. But a more truthful reckoning of what was usually being acknowledged is a baseline and history of "tools and assignments". Depending on whether the history was predominantly one of breadth or of specialization, talent could be cast as success rates in situations involving "overviews" or involving "focus". This works fine when the essential matter is to determine "resourcefulness" in current conditions. Wise generalists and genius specialists both tend to get promoted, not just recruited. But it is complicated to think about resourcefulness when the challenge is an unknown or volatile future. Agility may quickly outweigh optimization.
A shift in perspective -- from that of staff positions to operational roles -- is part of moving towards competency. By analogy, operations are like a dramatic performance, and roles are the cast of the performance. The structure of the drama relies on the interaction of the roles. The director is preoccupied with the logic of the interactions. The director will work on that logic, attempting to streamline and optimize its force as the "cause" of the production "effects". The audience (or customer) gets the impact of the "production", and the players who are the best "inter-actors" are the ones with the most "talent" -- that is, for the demands of the situation, they are the ones with the most competency.
Interactions between managers of relationships, requirements, risks and resources are not fundamentally altered by the size of the organization. Small or large, the same bases have to get covered, so current IT staff will need to look at the scope of their current tools and assignments and understand what they have now that should be used for the purpose of the interactions of the four "Rs". Within the existing staff, the more readiness exists to support the Rs, the more talent is said to be present.
We can look at the Rs in light of the idea that the IT organization will take what is has and deliver capabilities in the form of services, just as if the services were products. The goal is to determine what products are both (a.) the most successful ones amongst customers and are (b.) the most likely ones to enjoy high sustained quality from the IT organization's production.
Aside from the analogy of a stage drama, there are several well known reference models appropriate for IT re-organization. The most important one currently is ITIL, the IT Infrastructure Library. ITIL adoption is now pervasive and, consequently, is written about extensively by already successful practitioners. In ITIL, the interactive logic of operations is expressed as management processes, and processes are conducted co-operatively by roles. The effect of the co-operating processes is to create and deliver warrantied high-value services.
In the sense of providing services as if they were products: the outfit called Pragmatic Marketing has long offered a framework of interrelated competencies that account for how products are strategized and produced for targeted customers. In effect, it is a product management model that can guide thinking about a product called "a service", and it indicates where competencies need to be filled by roles.
Another familiar model, whether deemed successful or not, is matrix management, also extensively documented but often not presented with rigor that transcends a company's persistent idiosyncracies or tendency to change for other reasons.
Thanks to web search engines, looking into any of the above will likely lead to the discovery of many other specific models, so these others will not be itemized here. However, as a way of forecasting what a re-organization might provoke, it is useful to consider how the four Rs might generally affect each other.
Logically, if you're a provider, customers are more or less represented by what kind of requests they have, so their Requirements provide the rationale for having a Relationship with them. The scope of requirements, which can be tracked and analyzed, is compared to the practical chance of fulfilling them in production, so this chance (which includes both means and opportunity) is a representation of Risk. Acceptable levels of Risk set the boundaries of operations, and Resources are applied to production within those boundaries.
This arrangement of dependencies is not one saying, in reverse order, that resources "cause" risk, or that risk "causes" requirements, etc. But if not having satisfied customers is the current state, then the causes of that problem may be found in poor understanding and control of requirements, and/or risks, and/or resources.
We may also consider that where the current state is not a problem but instead is an option or opportunity, managers of the four Rs may each have a perspective on what can be moved, added or changed to create a viable production path to the option. In this case, they will need to assure that they wind up in alignment with each other rather than creating a scenario that cannot be realized on time or sustained long enough.
IT Providers who produce services focus long and hard on determining how to be sure that, in operations, requirements are not too risky to themselves or to the customer. This is done mainly through what is generally called a Service Level Agreement (SLA), and when the customer buys the service they buy this form of product quality guarantee. SLAs are terms and conditions that pre-set expectations about the service as a product, so that the provider is not compelled to do something it is not really prepared to do.
Meanwhile, a catalog of services not only shows a potential customer what products and quality is offered; it also shows them how to ask the provider for things in a way that is easy for the provider to understand. Without the threat of underachieving, the provider can actually spend more time looking into additional options. To show that the provider has a range of services and competencies, the provider can make a different catalog available for each different major type of customer.
Back to roles:
Customers will want a representative from the provider who is a good-to-great navigator through the catalog.
Meanwhile, new services might also be crafted from managed realignments of existing resources. (Resources include equipment, money, time, knowledge and labor).
Technology engineering will never stop, but the need for that expertise to be in-house will continue to change with industrial scale innovations that make it possibly unreasonable for companies to "roll their own" when the requirements for satisfying customers and partners do not disqualify solutions already available from elsewhere. This makes business and technology analysts critical to spearheading the transformation of an IT organization into a services provider, and engineering staff must be aligned to production as creators of exceptional resources working under sophisticated supply chain managers.
While much of the above is more the implications about remodeling instead of instructions, what is definite is that IT remodeling is a strategic project, or else it will probably fail to be better instead of just different.
Posted by Malcolm Ryder at 12:05 PM | Comments (0) | TrackBack
September 3, 2010
Performance Measurement for Services
It goes without saying that a poor-quality service will risk a short life-span and throw its provider into the dark side of relationship management with customers.
Understandably, quality management is not outranked by any other type of service management attention. But where managers depend on measurements, the most common problem is a confusion about what measurements are "quality" measures and which might be unnecessary or better suited to a different management concern. The most frequent point of confusion is with performance management.
To distinguish the two, first it is worth noting that many measurements are important to both. But as facts within a point of view, these "shared" measurements fit differently into the two perspectives.
Quality is a percentage of a level of performance achieved both without defects and within the intended structural design of the acting entity. In comparison, performance itself is a level of operation achieved versus a target level of operation. As an example highlighting the difference and the relationship, high performance may be obtained from an acting entity, but because the quality of the entity is poor, the entity may break down or be distorted by the effort to reach and sustain the high performance. Logical management approaches aim to synchronize performance expectations with identifiable levvels of quality.
In overall operations, services underpin the performance of both products and processes, while the services themselves are also managed for their own performance. Different contexts then contribute the conditions that point those performances at quality considerations.
A business process that needs support is a "problem" for which applying a service is a "solution". In general, a service is a subscribed behavior of an operation. In this way we can see how standardized observations of the performance characteristics of the operation help to account for the success or failure of the business process.
Posted by Malcolm Ryder at 3:34 PM | Comments (0) | TrackBack
June 27, 2010
The Tao of "New"
Back in April of 2007, Optimize Magazine ran an article by M.S. Krishnan titled Moving Beyond Alignment. Its summary: strategic business innovation requires a flexible infrastructure so that the company can utilize the business models needed to achieve goals. Thus IT governance and architecture must enable the enterprise to "synchronize with changes in the business environment".
Meanwhile, scheduled for late 2010, the book from strategic technology architects Greg Suddreth and Whynde Melaragno called The Path to Real Business Transformation discusses "dynamic synchronization... a rigorous, business-case-driven collaboration between the business-process owners and their IT counterparts." For this, the framework of problem-solving is what they call business architecture.
"Innovation" always has an aura that suggests the big moment of arrival of the new. But getting to utilize the new is the only way that value is derived from innovation, and utilization requires integration into, and synchronization of, the operational scheme of things. This emphasis on synchronization firmly declares that the problem of follow-through on business strategy is fundamentally about coordinating the moving parts.
Anyone who has tried to manually shift gears in a moving vehicle knows that synchronization has two operator-controlled aspects: time spent in the gear, and timing of gear changes. In a competitive context, where time and timing are pre-planned and managed for variances and circumstantial adjustments, this plan is even seen as a strategy itself. The performance level of the plan's execution, especially in complex or volatile environments, is then most often seen as "agility". Achieving agility is, for that reason, a common business objective related to scoring business goals.
Suddreth and Melaragno further state that "business architecture" is developed through a process that defines and institutes long-term change within a framework of strategy (for example of goals, related positions and directions), planning (for example, of resources), and execution (for example, of services). They go on to point out that multiple business areas must be complementary in the context of solving a defined business problem.
To assure proper pursuit of that agreement, it becomes necessary to appreciate the difference between innovative business uses of IT versus business use of innovative IT.
- In the former case, the emphasis is on the business-level understanding of how moving parts might be aligned in a new way.
- In the latter, the point is to introduce moving parts that have a different set of characteristics and interactions than those typically tried before.
From the point of view of these authors, the former issue is a concern of business architecture; and the latter issue is a concern of IT architecture, in which (among other things) the business architecture is "physicalized" according to Suddreth and Melaragno.
Given those points above, it would seem that the challenge is to prioritize business innovation, then leverage business architecture to identify and incorporate IT innovation that can be scheduled within IT architecture for a reasonable chance of sustained synchronization.
Posted by Malcolm Ryder at 9:36 PM
June 21, 2010
The Vertical Web
The periodic media campaigning for Web 2.0, 3G, Web 3.0, 4G and the rest are testimonials to the waves of functional innovation that break across the public-use digital information networks. These successive "versionings" represent a willingness on the part of network operators to try to provide relatively unprecedented capabilities with continuous -- if yet tenuous -- availability.
Although corporations are in a better position to maximally exploit new web environments, the common verification of web evolution is most strongly felt at the individual user's level, where over time the following distinctive progressions have occurred as "status quo" of reasonable expectations and the baseline expectation of using the web. In the original stage, digitization supported broadcasting; then in the next stage browsing supported the read/write web; and bandwidth pulled up the third stage. In that representation, key bundles of capability reached a critical minimal maturity at each stage and together set operational expectations.
Tracking such progressions always raises the question of "what next?" -- and in this case the most important next stage will find enough overall functionalities and interoperabilities such that an entire system -- and ecosystem -- for a given subject domain can be affordably traversed on the web by the individual user. This "vertical integration" means that the web will cease to be an undifferentiated "superhighway" and a series of outlets or malls, and instead become the virtual world of rich, semantically inter-activated media in which lifelike simulation will become comprehensive daily personal production: not just an internetwork of information but an internetwork of targeted special interest.
Typically, marketers have been working in the space to create systemic connections of interest to parties in the role of "producers" (meaning, those whose primary function is to make something from being informed, or being supplied with content); and this has been layered atop the older presence of operations by "reporters" (meaning, those whose primary function is to present information). In the next "default" iteration of the web, personal production will be attended by agents and partners, to the same degree that marketers currently scrutinize and manipulate experiences. This additional attendance will "close the loop" between an individual's internally directed (presumed) and externally directed (assumed) personae in the web environment. At that point, specialization of interest domains -- that is, channels -- will become routine and convenient as the typical organization of the web.
Text and images copyright 2010 Malcolm Ryder / Archestra
Posted by Malcolm Ryder at 11:52 PM
June 19, 2010
Forecast: Partly Cloudy
This makes it obvious why tools like I.T. (information technology) are not just helping business, but instead are an integral part of the "body" of business, as much as are people. Said differently, I.T. management has reasonably been a critical concern of the management of the internal "corporation" of the business.
While "internal IT" has evolved dramatically through several generations of computing, the essential organization of people and "IT" has not really changed: IT is part of the environment in which work is done.
However, generating the environment has not always been done exclusively from internal resources. Outsourcing is old news. And increasing technological advances based on use of the internet make it even more likely that the business will find opportunities to have production environments generated and/or hosted externally. Currently, the trend is mostly for external organizations to research and develop new web-based production environments first. While those external environments may then be shared by other businesses, the know-how for building such environments is also growing in, or migrating to, internal IT operations. As such, these new types of environments, called "clouds" are appearing in both external (usually shared or "tenanted") and internal (usually private) variants, with privacy having a big lead in preference over sharing.
Companies that do not already have a "cloud" environment do already have an environment subject to a vast array of managerial concerns that address costs, engineering, and other factors that are decisive of the range, reach and utility of the environment's functionality in actual use. The different types of concerns also cut across the "levels" of structuring that compose the environment, which means that the overall management complex can be difficult to balance; when balance more or less exists, no one is especially excited to upset it -- and moving from that status quo to something different easily runs into a lot of resistance.
Yet in general, the reasons to make the move from a non-cloud environment to a cloud environment are business reasons: the two primary issues ultimately addressed by IT management of the work environment are economy of scope and economy of scale. If either one cannot be solved and sustained to the business's satisfaction, then there will be changes made of some kind. Economy of scope must be considered first, because it more closely relates to the reality of variety in the business's requirements. Normally, an internal non-cloud environment is tamed by managing the three key factors of its dynamics: demand, operation, and capacity. Management approaches focus strongly on the interrelationship of the three. Even the most general schema involves the following approach (as diagrammed)for packaging the Users' environmental leveraging as services:
Put simply, without capacity, demand cannot be met, and without operations, there is no way to meet demand with capacity. Assuming this challenge is adequately addressed, there is always the matter of whether any of those key factors will change, so everyone is concerned about changes getting the upper hand. That set of conditions precedes the actual achievement level of economies of scale. Without economy of scale, the structural components of the environment do not "add up" well in the business perspective.
Good design helps to bring resources that are capable of supporting adequate economy of scale, but the actual deployment and utilization of the resources is what finally drives, and surfaces as, "economy". If not attended in a mature way, the dynamics of economy are more difficult to manage than the attributes of systems that can run at large scale:
Posted by Malcolm Ryder at 1:05 PM
May 30, 2010
How IT Strategy and Business Strategy Co-Operate
What is the relationship between business strategy and IT strategy?
IT strategy must be seen not as a monolithic pronouncement but instead as a continual practice with which use of information technology is tailored to the business use of information.
Business use of information falls into many separate but inter-operable domains including (but not limited to) communications, learning, analytics, research, and history -- along with production, and then of course, process management.
When we say "business strategy", the assumption is that there is a type of influence that the business seeks to have on its community of stakeholders and in its operating environment. This is an influence that depends on a position that the business can establish for itself, relative to other functional or operational entities that are either contiguous or party to the community and environment. The strategy is made up of the intent and plan to take the position for the purpose.
The use of information corresponds to the strategy, but -- not all information usage is about the strategy, except in the sense that it needs to either allow or cause the strategy to succeed. This means that the usage itself needs to succeed given the particular method of usage and the actual information itself.
IT strategy must concern itself with what methods can be combined with what kind of information, to provide the opportunity that the business strategy needs, by creating effects that are either preconditions or causes of the opportunity.
Accordingly, for IT strategy to make sense, first the opportunity needed by the business strategy must be identified, and then the type of information usage needed for the opportunity must be enabled by IT.
This requires understanding how the different information usages will co-operate to create conditions that will add up to the opportunity.
Some of those combinations are intuitively appealing because they are part of proven past efforts.
- Communications, Production - selectively informing participants and stakeholders to establish efficiencies and quality in work
- Research, Analytics -- diligent search/discovery/arrangement of data, patterns and models that are useful for making and explaining things
- History, Learning -- compiling descriptions and interpretations of experience that clarify contexts and relationships
Bottom to top, those pairings usually allow the business to identify functions, design ways to conduct them, and generate specific operational capabilities from the designs. Obviously, relevant capabilities are an essential type of "opportunity". Drawing learning from history, or drawing analytics from research, and so forth, are typical interactions, and the effects of one pair are commonly leveraged by the pair above it.
At the same time, there is no guarantee that accomplishments in one area will flow up into others. Even where certain lineups are compelling, it is necessary to look into how a network of influences can arise in non-linear fashion amongst the full set of usages. These influences can be inhibitors as well as promoters.
For example: history can predispose analytics, by culturally reinforcing attention to some issues and neglect of others. Meanwhile, learning can predispose communications, by preselecting audiences. And production may impact research, whenever they compete for resources or persuasiveness.
Along with new capabilities, most business strategies can think in terms of ideas (knowledge), relationships and assets when exploring the types of opportunities that may be needed. Usually, in a mature business organization, these are all enjoying focused management The question is, for each type of opportunity, what should IT do to enable and orchestrate the six or more basic information usages required for creating and maintaining it?
The touchpoint between business strategy and IT strategy is those usages. In practice, the business strategist must determine which certain opportunities should be pursued. The IT strategist must identify, engage and evolve the related touchpoints so that their interactions are balanced towards providing the opportunities that the business strategy needs.
Posted by Malcolm Ryder at 1:00 PM
May 26, 2010
Why the Business is the primary customer of Service
- an ongoing running operation,
- that is presented to a consumer of the operation's output,
- with an offer and a mechanism (interface),
- for invoking the delivery of the output upon the consumer's occasion of demand.
The reason why this arrangement can actually work without imploding is three-fold:
- the provider of the service can share terms of agreement with the consumer about the allowable occasions of demand;
- the full range of operation outputs need not be offered as a service; and,
- the consumer need not know how the operation is constructed or maintained, so the provider can modify the operation behind the service.
In effect, it is do-able because the scope of the service can be managed.
Typically, it is the issue of operational modifications that generates the most excitement -- and the excitement typically comes to a head in the IT (and facilities) departments of the business. Levels of service, and qualities of service, are bound to managed risk and performance factors that must be aligned to each other within the architecture of the operation that will be exposed as a service.
To add further perspective: it really does go without saying that different tools may be employed to do the same job; and this points out that deployment decisions are more critical to risk and performance than are the attributes of the tools themselves. With that perspective, a "business view" of an operation concerns itself primarily with the possibility that operation structures are both rational and sustainable. This means, in turn, that the business view of how to reasonably warrant a level or quality of service relies mainly on two things:
- it looks at those same operational decisions
- it acquires a validation through test-and-proof that the outputs for offer are acceptable, within the risk and performance allowed by the decisions.
This structural coherency sought for operations is essentially what is pursued by the prescriptive practice called Configuration Management. Configuration Management is historically maturing within the domain of IT software and hardware management for integrated production systems. Today it is most heavily influenced by best practices described in the knowledge domain called IT Service Management, or ITSM.
From the above notes, however, the emphasis would appear to be not primarily technological but instead concerned with the decisions (left side of the illustration), underpinning the business information model and business process model (right side) that together shape those outputs of the operation that are eventually made selectively consumable.
Where technology takes root, through IT architecture, is in operationally instantiating the service -- to meet a quality and level that works for the business. Primarily, the service must, on demand by the business, be available within the rationality and sustainability that the business can accomodate. In that sense, the first customer of the service is the business itself.
The net of this is that the IT practice within the business will need to understand and mature configuration management on business terms, especially in a time when systems management of IT-based operations is relocating outside of the business campus to what is called the Cloud -- managers of provision of web-based delivery of IT-systems-as-services. Although the Cloud is most often referred to as an "environment", its business role is that of a contracted service partner or supplier, conducting critical chunks of operations that must not disconnect from information and process management.
The takeaway: alignment of operations to information and process models will call on the ability to articulate how much configuration specification by the business is necessary for the business to achieve confidence in risks and performance levels, and thereby agree to the terms of service delivery.
Posted by Malcolm Ryder at 2:52 PM
April 14, 2010
Retooling the IT Organization
Thanks to marketing and competition gurus, disruptive innovation, both famous and infamous in I.T. circles, is usually noticed first more on the front face of organizations than in the back office.
But that's not a bad thing: it is a natural outcome of the track of activity that stretches from invention to implementation. The front face of an organization is where growth is decided, dealing with opportunities and threats by creatively linking strategy and ROI. To nurture the link and its importance, policies (a very fancy way of saying priorities) go into effect.
Meanwhile, a competing track runs differently -- from experimentation to adoption -- and has a different outcome. The back office makes decisions about how ideas will in fact be sustainable enough to give ROI a chance. In this track, what is affected is actual practices. To keep up with the pressure of policies and ROI, organizations operationalize themselves by incorporating tools into procedures for managing operations more predictably. Predictability sets a stage for detecting the difference between what often works under pressure, and what often doesn't. Technology adoption signals either a belief that things can be made to work better, or a conclusion that they cannot be allowed to work worse. But these days, as always, there is a lot of experimentation going on first.
One of the most dramatic side effects of the innovation called Virtualization is that organizations built to exploit certain kinds of resource capacity are being disrupted. Literally, the structure of responsibilities, accountabilities, consultations/cooperations and information -- sometimes called RACI -- has been designed for predictability about certain things, and virtualization is removing many of those same things from the actual practice of daily operations.
I.T. organizations generate their own business value largely through being able to achieve a level of Performance, a level of Control, and a sustained level of attention to both (Compliance), all within the budget -- or in other words, at a target operational Cost.
But a major emerging issue in IT organizations is the struggle to regain predictability when virtualization -- mainly a software and configuration phenomenon -- has removed many practice constraints from overall (systems) technology performance and technology control, leaping beyond established norms of compliance, and obsoleting the already-implemented models of cost that have survived business approval processes.
IT organizations are inspired, by apparent cost "advantages", to experiment with the invention of virtualization. But this can very rapidly create operational effects beyond existing methods of control. By analogy, in sports, a coach fantasizes about having a superstar athlete, but agonizes if and when the star unilaterally renders much of the game planning and much of the roster unusable. Under these conditions, keeping the star can mean redesigning plays, rebuilding rosters, or even challenging the existing rules and conditions of play. On the other hand, the best coaches make the player fit a role and get rid of him if he can't fill it.
For the IT organization that wants to implement virtualization, the approach to draw from the above is twofold.
One part is to give virtualization a role specifically in context with the rest of operations. This will mean using virtualization to power a defined service, not just to reduce resource costs. Services should be the reason why the business is interested in virtualization, and the business should be telling IT to use virtualization, not vice-versa.
The other part is for the IT organization to not treat virtualization as one of its enabling technologies, but instead to treat compliance management of --and performance management of -- virtualization as the IT organization's needed enabling technologies. These are going to have the effect of changing the RACI of the IT organization.
Punchlines:
Organizations must adapt to what they adopt. Virtualization means that the legacy roles and systems supervised by the IT organization must be reconfigured. The back office needs organizational change management.
To assure that IT operations are integrated with business operations, Virtualization means that the business will assign value to resource capacity -- i.e. assets -- primarily in terms of the impacts on services, making services the key element in the framework for determining ROI.
The good news is that both application development and software compliance management offer abundant lessons already learned, to be transferred over to the systems management arenas as a starting point. The bad news is that so much of what is now known as IT asset management and IT configuration management is based on things that virtualization can easily obsolete, so those essential components of IT management practice will have to be re-engineered, along with the roles that want to carry their names.
Posted by Malcolm Ryder at 3:48 PM
February 23, 2009
Federation, Synchronization and Consolidation in I.T. -- a lot, but not enough.
Anyone who has done systems research or done the care and feeding of systems is familiar with the idea that a system is often made up of sub-systems -- for example the way that the human body is composed, or a good old-fashioned hi-fi stereo component hookup, or compounds made of molecules made of atoms. One of the key things to consider in managing the higher-level systems is that their sub-systems are indeed complete systems themselves and have their own internal complexities of components.
"CIs" are things that are similar to the above, in that a higher-level CI such as a "service" may be composed of other "sub"-services having, in turn, their own constituent services -- but this is why in the conversations about "CIs" in many companies, confusion develops amongst the terms "service", "system", and "component". Questions and even arguments follow this confusion, such as "when is a system a CI? Are all services CIs? Do components combine to make CIs? Do CIs combine to make other CIs?" This puts an end to the usefulness of speaking roughly.
So instead, if we take the term "Configuration Item" and break it down without regard to its actual linguistic history, we should think freshly: the term "configuration" means something on its own -- i.e., a certain arrangement of selected parts -- and the term "item" represents something involved in a configuration -- namely, a part. Any construction has a configuration, and the parts in the configuration are items. This conceptual abstraction is still easy language, and it completely covers the aspect of drilling down into one thing to find, among its parts, other things that each can likewise be decomposed. What follows below intends to apply such consistency across old terminologies as well.
For our purposes of discussion, the key construction is going to be some service that we want to have. As we'll see in the illustration here, there is an important and consistent way to discuss what is found in the drill-down on a service. Generally, we drill down onto two different kinds of resources for the service. On the one hand, sub-sections of a construction are what should be known as "components". On the other hand, the materials that are used to make up the subsection are what should be known as "elements". Like fire, earth, air and water, there are different kinds of elements; they combine to make up components that can be sub-sections of constructions, including of course constructions that have only one logical subsection: the unit whole. Logically, this is always true regardless of what particular construction is developed. But now, to address an earlier question, when is a construction a "CI"? And the answer is, a CI is not a thing; it is a management perspective on a thing. This thing might be an item or a configuration. What makes the thing a CI is management's attention to its role as an "element" of a service.
Now, when the main construction will be provided for use as a "service", and we are talking about the "components" of the service, we are referring to the configurations within the service. Remember that the essence of a "service" is in that it is something being provided for use in a given way; the type and complexity of a thing does not define it as being a service. However, logically, the components in the management view are the actual "instances" of whatever type of CI, since the instances are what the service user is actually reliant on.
Remember also that the configurations within the service are constructions themselves. What we must recognize is that for a construction seen at a "top" or "parent" level, the involved configurations have elements; but at a lower "child" level, those elements of the parent may be constructions for the child. In this way we see the drill-down through a structural hierarchy based on a recurring logic. For pragmatic reasons, organizations increasingly adopt names for the different levels, such as "Business" (parent), "IT" (child), and "Systems" (grandchild). By this logic, systems configurations become items for (i.e., elements of) IT configurations, and IT configurations become items for business configurations. Meanwhile, "services" may occur at any level, because what defines a service is how something is provided, not what something is.
What is more interesting, then, in this whole thing is not so much the parts (items) themselves but the relationships that become the structural arrangement (or actual configuration) within the construction provided as a service.
In a management scenario, relationships become important mainly because, not surprisingly, they make the configuration manageable. This intent immediately makes some relationships more important than others depending on the perspective of the particular manager. And most interestingly, it throws attention on items (parts)that are not "equipment" such as hardware and software, but instead are "instruments" such as supervisory people, or regulatory documents -- indeed, any influential entity that can be logically assigned (i.e., related) as an enabling part in the ongoing functionality of the construction.
Now, since one of management's primary concerns is to establish and maintain the appropriateness to task of whatever is being managed, then another large focus of management is configurability. To throw quality control into configurability, there is initially the aspect of design, and quickly thereafter the matter of change-control.
The design side of things calls for specifications, which basically are descriptions of the particular configuration and/or item that is intended to be realized. With design and specifications, many instances of the same type of thing should be possible to produce with sufficient similarity to make the instances interchangeable if necessary, but all of the instances would be examples of a specific and unique version of a specific and unique model.
The value of specification is in its precision, which allows managers and users to have confidence that they have their hands on exactly what they need. The specification may point out that there are characteristics of a configuration that are produced or contributed by supplier X while other characteristics are given by supplier Y.
Keeping a central library of trusted configuration descriptions is the idea that gave birth to the Configuration Management DataBase or CMDB. In a CMDB, it is usually the case that configuration characteristics are identified as parts meeting specifications called "attributes". It stands to reason that a CMDB needs to gather reliable data from multiple suppliers responsible for the attributes of any of the configurations on record. The problem of managing the CMDB itself, then, is no different from keeping any complex database in good shape. If anything, the degree of confidence that the CMDB users want in its data makes the complexity that much harder to cope with.
Centralization of the data is the easy way to describe the strategy for meeting the goal of a highly-reliable CMDB. To really appreciate what this means, it is necessary to understand "centralization" in three tactical ways that reflect and resolve the CMDB's complexity:
- federation,
- synchronization, and...
- consolidation.
Federation refers to the multiple donors of trusted information working in a co-operative manner so that they do not fail to contribute the right thing by the right time. As teammates, they need to all be on the playing field together when the play is about to be run.
Synchronization refers to the possibility that more than one party knows about the same thing, but they know it and talk about it in dissimilar ways. In this case, if one of them is more up to date in its knowledge than is the the other one, the other needs to get up to date in the terms that it uses to refer to the same thing. This paralleling, in which if A=B and B=C then A=C, calls for some mechanism that can assure the parties' two different terms (A and C) can again represent each other correctly in the same moment.
Consolidation refers to the case where multiple terms that refer to the same thing are reduced to one term which becomes the singular preferred referent, making the redundant others unnecessary.
Ideally, any configuration in a CMDB is an instance of some single type that is a successful consolidation of descriptions. Each unique type can have, theoretically, an unlimited number of instances.
In typical implementations, a CMDB may or may not be federated, since the CMDB might be held responsible for only certain types of configurations that could be confidently composed and described without multiple suppliers. Federation, always a possibility, is usually more the exception than the rule.
Synchronization is initially an issue when the first decisions are being made about which data sources are the ones that should be considered authoritative. If there are already multiple systems recording descriptions of the same thing, they probably need to be checked against each other to see how well they match, before either one is chosen over the other. This will be most useful when CIs are being initially defined for inclusion in the CMDB, since there is no point in recording a CI unless there is a trusted mechanism for keeping the record up to date.
As the above issues go, things tend to resolve in a way that there is not much discussion about federation, synchronization or consolidation (!) -- however, a different term is constantly used and rules the roost: reconciliation.
Reconciliation refers to the need to take recent validated discoveries about the characteristics of actual instances of configurations, and compare the findings to the record about those configurations as found in the CMDB. Updating the CMDB records means that the recorded versus discovered information must be checked, with mismatches resolved through a manager's decision about whether to change the CMDB record or change the actual configuration instance. Because a CMDB is not trusted unless it is known to be up-to-date in its authority, reconciliation is a critical success factor for the CMDB utilization. However, in a little recognized nuance, "reconciliation" is often mis-applied to the effort to remain up-to-date.
To appreciate this nuance, consider that two parties start out disagreeing, but they wind up agreeing with each other in the end. This would be reconciliation. However, if the two parties cannot agree with each other, and a third party is required to make the decision for both of them, then the original two parties (still disagreeing) did not have a reconciliation but instead an arbitration. An important thing to note here is that an arbitration effort can always come up with the same results that a reconciliation can, but a reconciliation effort cannot always come up with the results that an arbitration can.
It is often the case that I.T. managers rely on a mix of tools providing highly reliable feedback each in its own terms. This sets up the important necessity for arbitration to the degree that the tools do not share a common descriptive dictionary. Arbitration rules enforce "tiebreakers" and properly dispose of exceptions; this clears the way for consolidation of information within the CI record.and brings the CMDB closer to the capability that management really wants the CMDB to support -- risk avoidance in decisions, under the pressure of Quality of Service expectations.
Posted by Malcolm Ryder at 4:17 PM
September 17, 2008
Business Process vs. Business IT: again?
These frustrate the chances of recognizing "a business process called IT".
On the one hand, this is hard to overcome if people don't say what aspect of IT they mean to identify when they say "IT". An interesting point to put on the matter is that the primary expectation of IT users is actually "process management automation" -- not the same problem to solve as "information management" nor the level-setting about which sanctioned company processes are strategic/tactical/operational.
On the other hand, the word "alignment" itself continues to provoke and refresh the difficulty of reaching "I get it". The more important term to emphasize is not "alignment" but "integration". Imagine that some decision-making sector called "Business" was not integrated with the decision-making sector called "Finance". Since managing IT, like managing Finance, creates and governs a critical dimension of the business operational environment, some businesses cannot be dis-integrated with it and still rationally expect to succeed.
What might be really interesting short-term is to see and compare what stances about "alignment" come from CEOs who are Lawyers or are Technologists as opposed to Finance alumni.
Furthermore, however, as long as the "alignment" banner keeps getting hoisted by analysts and pundits in the trade, they'll keep educating CxOs to think about things in the wrong way. When it comes to IT, CxOs should be working on the management process competency at all levels -- an approach that would make it more obviously the responsibility of CEOs and CFOs to cultivate, not just for CIOs to offer.
Posted by Malcolm Ryder at 10:04 AM
June 24, 2008
Business-IT Alignment: Who Do that VooDoo?
At Tech Republic, the online resource for IT management information, executive editor Jason Hiner's article "Sanity check: What’s the difference between CIO and CTO?" relays the following quick guide.
Chief Information Officer
- Serves as the company’s top technology infrastructure manager
- Runs the organization’s internal IT operations
- Works to streamline business processes with technology
- Focuses on internal customers (users and business units)
- Collaborates and manages vendors that supply infrastructure solutions
- Aligns the company’s IT infrastructure with business priorities
- Developers strategies to increase the company’s bottom line (profitability)
- Has to be a skilled and organized manager to be successful
Chief Technology Officer
- Serves as the company’s top technology architect
- Runs the organization’s engineering group
- Uses technology to enhance the company’s product offerings
- Focuses on external customers (buyers)
- Collaborates and manages vendors that supply solutions to enhance the company’s product(s)
- Aligns the company’s product architecture with business priorities
- Develops strategies to increase the company’s top line (revenue)
- Has to be a creative and innovative technologist to be successful
Given that picture, the two top observations are these:
1. Infrastructure affects the bottom line (what you get to keep), while systems affect the top line (what you get to get). Of course, this goes a long way towards explaining why a CIO would report to a CFO, while a CTO would report to a CEO. More importantly, it indicates that strategic resourcing can be a CIO's calling card, but that strategic positioning can be a CTO's calling card.
2. Much less explicit but still clearly in evidence is the difference between being a chief operations technologist (a.k.a. CIO) and a chief business technologist (a.k.a. CTO). Naturally, the easy way of understanding how to assess their respective progress and performance would rely on understanding the consequences -- of not having good infrastructure (provision of operations technology) and not having good systems (provision of market interaction technology). But getting it figured out in positive terms has stumped the panel often enough and long enough that these job descriptions still have to get spelled out long after the hiring has been done . What's still needed furthermore to get the dust to settle is a plan of co-production between them. Whereas neither effort alone could get the whole job done, the combined efforts of the two groups would offer a company an office of Business-IT Alignment...
Posted by Malcolm Ryder at 8:48 AM | Comments (0) | TrackBack
April 3, 2008
The Circumstantial Strategist
According to Edward Cone, in his CIO insight article CIO: The Accidental Strategist, most companies claim that information technology is strategic to their business.
This seems like a no brainer; competitive business is primarily a matter of matching a determined need with a defined opportunity to serve the need, and neither side of the equation can be handled at the necessary combined volume, speed and cost of sustained competition without IT.
But, says Cone, according to research by Diamond Management & Technology Consultants, IT executives say:
- just one-third of the execs play a significant role in the strategic planning process at their companies
- only about one-quarter of participating CIOs spend up to 50 percent of their time on strategic issues
- barely one in 10 spend more than half their time on strategy.
In other words, the average actual occasions of direct CIO influence on strategy amount to only about 1 out of every 16 CIO person/hours -- approximately one short morning a week.
Averages are good at promoting distorted mythologies, so having put that one out, let's immediately begin to ignore it rather than repeat it. But from the observations in Ed Cone's article -- in which several variants of "The CIO" are posed for inspection by actual CIOs and by industry management gurus -- a few other points jump to my mind:
- First: the article's title may have been more apt if it said, "The Circumstantial Strategist". The territory being covered is not so much about why CIOs should do strategy, but instead about how CIOs get to do it. Along those lines...
- Second: CIOs who report to CEOs have a fundamentally different "lay of the land" than do CIOs who report to CFOs or COOs.
- Third: A CIO doesn't have to see the whole company to be strategic; he or she has to see the whole information architecture on which relies a business operation that is directly accountable to a CxO. Certainly there are enterprise CIOs, but not all strategy is enterprise-wide. In fact, many companies have more than one CIO.
- Fourth: CIOs are often in a position to recognize an IT opportunity to alter the business model. But there is a huge difference between having (a.) both the responsibility and authority to do it, versus (b.) only the opportunity. The politics of the internal corporate governance effectively draw the boundary around the CIO's effective role. What's probably more interesting than the "CIO" title is what the other CxOs have agreed is the range of the so-called CIO role.
Posted by Malcolm Ryder at 2:47 PM
March 16, 2008
Innovation by CIOs: the Same Old Same Old
Proposed: Business is built on IT, and CIOs know more about what IT could offer to innovation, so they should drive the innovation.
On the one hand, it looks good on paper. It's not new, but it seems to make sense.
On the other hand... wait, where IS the other hand?
The CIO Insight Discussion hosted some talk from industry analysts Forrester and kicked off followup commentary.
Reader Jon McAdams had left an earlier comment there that saved the rest of us some writing... So I'll segue from some of what he was pointing at.
CIO's who don't feel very "chiefly" should rightfully question whether their compensation is in line with how they'll actually be measured. But in the world of performance measurement, speaking truth to power is personally relatively expensive. How do you afford it? There's the dilemma.
Proposed: Any CIO who wants to use the word "Innovation" more than once a business quarter should be prepared to provide the definition of what innovation is, by distinguishing its flavors from each other: the planned, the authorized, and the actual. If the CIO is a decision maker in all three dimensions, then there is, fortunately, no dilemma; there's just execution.
But in execution, there are two tracks to follow: priority, and production. If the CIO is not being paid to decide and validate their alignment with each other, then again there is, unfortunately, no dilemma. There's just the matter of whether other people around the CIO want to know what's real or not before they take the actions they actually take.
Let's face it, giving action orders to the "head of IT" doesn't require having a CIO or being realistic. Meanwhile, getting orders can be done with one hand tied behind your back. But being held responsible for the consequences of someone else's higher up decisions is clearly not a prescription for being the chief.
Posted by Malcolm Ryder at 10:59 AM | Comments (0) | TrackBack
September 21, 2007
CIO 2.0 part One
Faisal Hoque, father of the Business Technology Management Institute, talks about the issue of solving the right problem instead of the wrong one in the CIO Insight article "Convergence, Yes; Alignment, No." As CIO Insight put it, Hoque noted that "rather than a goal, alignment is a stage on a journey to a more complete merging of IT and business that he calls convergence." With convergence, Hoque explains, "The business model is so intertwined with IT that there's no separate orientation."
What are the key features of this view for the top IT manager, for the CIO of the future? The same as for the CIO of now.
The first is the working definition of IT, which must position IT as business technology. This means technology of the type of business, not technology owned by the corporation of business. Here is a brief primer on business technology:
The second key feature is the working definition of "management". In the abstract, this has to mean "drive and authorize all key decisions about the utility value of the phenomenon at hand throughout its lifecycle." Naturally, the scope of this responsibility may involve or even necessitate collaboration and power sharing, and this means that a model of value-generation must exist to which all can subscribe. If this is to occur with IT, the concept of "IT" must be "operationalized":
From there, the third key feature, the point of it all, is to apply the operational potential to the business needs: this is how the IT model becomes the "dynamic" of the business model.
dynamic
1817, as a term in philosophy; 1827 in the sense "force producing motion," from Fr. dynamique (1762), from Ger. dynamisch, introduced by Leibnitz 1691 from Gk. dynamikos "powerful," from dynamis "power," from dynasthai "be able to have power," of unknown origin. The fig. sense of "active, potent, energetic" is from 1856. Dynamics as a branch of physics was in use from 1788.
Online Etymology Dictionary, © 2001 Douglas Harper
Given the numerous points at which IT could be mapped to needs, it isn't hard to appreciate that the current state of a business operation may have to go through significant re-modeling (transformation) to base the business model itself on the influences of IT. Speaking of that, the evolution of IT's realization as a business enabler actually is a goal, not just a stage. But the sneaky punchline to this is that the business may not need to be its own "IT-enablement" provider. Fusing the IT model and the business model (value management) is not the same problem to solve as the problem of establishing competency in the role of IT provider (performance management).
(This discussion continues in the follow-on article CIO 2.0 part Two.)
Image credits:
http://www.how-to-draw-and-paint.com/images/BasicHorse3.jpg
http://www.chss.montclair.edu/~pererat/7751.jpg
http://www.tsc-global.com/index1.html
Posted by Malcolm Ryder at 5:29 AM | Comments (0) | TrackBack
September 19, 2007
Make IT a Business Strategy
In the CIO Magazine article Let the Business Drive IT Strategy, the visibility of many views on strategy helps to paint the map so that people concerned with IT strategy management can see where their relative starting points are, not just their goals.
But in that map, how did we wind up in so many different starting places that we decided to call by the same name?
Here is a 50,000 foot high view to consider. What does "IT Strategy" mean? Strategy for what? The candidates are found in two dimensions.
First - what is used:
- Services
- Resources
- Information
Second - how it is organized for use:
- Provision
- Architecture
- Property (assets)
Make a 3x3 matrix of the above, identify what needs to happen in each cell and who needs to care (owner, operator, consumer), and then on the business side at least everyone can see what they are trying to talk about.
With that view, it then becomes meaningful to talk about the business's ideas of performance (goals), value (impacts), and risk (policy and culture) -- with the objective of assigning people to be responsible for them and then investing to make those people successful.
This isn't about "succeeding with a strategy"... it is about actually managing with a strategy.
Posted by Malcolm Ryder at 8:44 AM | Comments (0) | TrackBack
July 3, 2007
In I.T., Time is Money
CIOs are usually asked to stop the spending! ...but actually they go on directing the spending of the most important currency of all.
In an interesting parallel, the McKinsey folks have been able to track the connection of IT assets to business performance not by simple cause-and-effect, but by naming the secret sauce in the middle, just as the people who discuss Operational Performance Management (OPM) have.
In OPM, the problem is often stated that something must show up to align execution to strategy. Although execution presumably exists to directly serve strategy, it often proves not to do it, and it needs an agent of some kind... a middle man. Disintermediation is not a good thing.
Well, some readers run, a bit carelessly, with the notion that McKinsey preaches better business performance through IT superiority. Picking the "execution-er's" nit, us contrarians say that while high-performing businesses may show IT superiority, IT superiority doesn't necessarily equate to getting high business performance. For starters, despite the promise of automation, we don't simply equate "I.T." with execution; nor business performance with strategy, since many companies gain even more by luck than by smarts. And instead, we think the good stuff happens in the middle (somewhere between IT and business performance).
To be fair, so does McKinsey. But to improve on their take: we like the elegant end-to-end trajectory of evolving the application of IT -- evolving it from practices (i.e., cost) to strategy (i.e. value). This line of thought is crucial to escaping the boring myopia of anxiety or thrill about "commodity" IT... And to avoid having the middle of the trajectory wallow in wishful thinking, it is necessary a la McKinsey to insert "alignment", but which here means "investment". The right investment is the secret sauce.
To put this investment in perspective, ask a business, "if you could have only one of the following -- more tools, more ideas, or more time -- which would you choose?"
On the main trajectory, investing in the best answer -- time -- will mean tracking and balancing what IT does to people versus what people do to IT. Why? For example, in execution, whether about innovation or about maintenance, time affects how people use IT; and in procedural design, people decide "how IT uses time"...
Looking for superior IT utilization? When time is granted to persons interested in trying IT, IT enablement is learned much more quickly -- which is then what allows IT to change business capacity. Without capacity, you can forget about agility, recovery, and growth.
Naturally, then, the business is strategically concerned with "buying time". So, take any organization and, in the trajectory, here is the alignment both literally and virtually: the organization's politics of "spending time" will determine how its people get the time, and thus whether its IT can actually advance the organization's strategy or not.
And guess where time is *controlled* ? Not in supply, nor in strategy, but in management. So, ultimately, in a virtuous circle, the CIO manages to ensure that time is spent on IT to actually "create more time" for the business, instead of losing it... But what is the #1 barrier to achieving this virtuous circle? Politics.
Posted by Malcolm Ryder at 4:25 PM | Comments (0) | TrackBack
June 18, 2007
How IT Assets come from Business Requirements
After twenty years of developing, managing, marketing and deploying IT, providers still have huge opportunities to miss the mark by giving the customer what the customer asked for instead of what the customer needed.
To see how much can still be missed in any new delivery, check this chart and ask whether the implementations you're familiar with came anywhere near covering what was important.
Key shockers to lookout for:
- Customers didn't know what they needed! How could they always be right?
- Providers weren't solving the right problem! Why would the quality matter?
- Most of all, requirements held no accounting for the difference between risk, complexity and difficulty -- so who knows when anything would actually "work"?
Posted by Malcolm Ryder at 11:35 AM | Comments (0) | TrackBack
March 11, 2007
The Ontology of Support in IT-Business Alignment
Business-IT alignment is an ongoing critical success factor of enterprise performance. There, "support" functions of aligning IT with the business are all part of just two basic management issues that describe the problem of responsibility in the business-IT relationship. One, how does IT production fare in providing the deliverables to the business? And two, how well do the needs of the business associate to IT's support? The issues mark the distinction between what IT can do on its own accord (production) and what the business finds valuable about IT (support).
.
Once fully articulated, the factors of the relationship's "operationalization" show the belief system that underlies the standing functional organization of the relationship at the given business.
From the bottom up, the layout reflects how the IT "service desk" attains a central role in the alignment. The primary responsibility of the service desk is to bring proper workflow to the support request incoming from the business. The nature of these requests follows along the type of concern that the business has, which falls within three main topics in the relationship's ongoing "conversation". Within each topic, the problem is to solve the potential imbalance or mismatches inherent between the subjects of the topic. These solutions are what comprise the ability of IT to properly align to the business.
As shown, the organization begins with taking what management has in hand -- SME's and assignment authority -- and codifying it for continual reuse by the business, in the form of two key interfaces: a catalog and workflow.
These interfaces moderate any mechanisms for systematically addressing the three key topics of the business-IT relationship:
- business (demand vs. supply)
- service (performance vs. operations) and
- IT (capacity vs. systems).
As seen below, catalogs and workflow each have roles in two of the three topics.
.
The substance of the three topics is found in the dynamics of the business-IT relationship, shown here as three factors -- effects, drivers and constraints. In each topic, those dynamics represent how the resolution of the topic's issues may arrive at a suitable level and type of affect on the business.
A key finding in the above is that we can count on the IT "effects" to be critical to the service "constraints", and count on the service "effects" to be critical to the business "constraints".
.
Another key finding is that any of the "effects" can be (and usually are) both categorized and measured, with the categorizations sometimes being both hierarchical and deeply detailed. However, management often gets lost in those "trees" to the extent of not being able to see the "forest".
At the higher level, the management effort must accomplish the following:
1. Define the business scope of the service responsibility: this means creating and "productizing" services. What are the SLAs actually covering?
2. Define most requests for operational support in terms of managing service quality. Classes of requests should indicate what depth of exposure must be addressed in the service's handling of the IT provision to the IT user (incidents, problems, changes, etc. a la ITIL). Within each request class, further categorizations should point at the two critical factors of continuity and quality. (Understand how incidents relate to continuity and quality; how changes relate to continuity and quality; etc.)
3. Based on evidence (probably "symptoms") from the IT user, categorize the suspected perpetrators in the request's issue about (or requirement for) continuity or quality.
.
This identifies, as seen below, where the touchpoint arises between the request and the workflow needed to satisfy it.
Posted by Malcolm Ryder at 4:38 AM | Comments (0) | TrackBack
February 1, 2007
I.T. Without ITIL
The most exotic thing about information technology has always been terminology. It is the key to the scientific success of the field. But quite naturally, the complexity of the science also has meant that the terminology works steadily against any increase of ease in the field's practical management. More and more cats pop up that need to be herded. The net result -- a nightmare of semantics -- caused what the Gartner industry analysts noted over five years ago: the overwhelming majority of cost in I.T. comes from not technology complexity, but management complexity.
Perhaps that's why it is that in these last three years or so, the I.T. Infrastructure Library, or ITIL as it is commonly now known, gained traction with the kind of momentum carrying an industry standard. ITIL describes a huge range of management processes using a vocabulary of enormous logical consistency, which can make the semantics of management suddenly unambiguous despite IT's complexity.
At the same time, the sheer scope of ITIL is fear-inducing. Many of those who would use it fall into one of two groups: those who look for evidence that there is actual practical import to sticking the toe in the bathwater; or, those who religiously convert. Analysts like Forrester Research say that the former group is about 60% of the gang, while about 10% are fully pious and immersed, leaving the rest either just thinking it over or dabbling.
On the spectrum between the larger and smaller group, the larger keeps its practitioners cordoned off (but not quarantined) in a swim lane... handling the semantics of ITIL as another special expertise hoped to achieve some natural ascendency, the same way an innovation outstrips or obsoletes legacies. The smaller "immersion" group swims the rough open waters of large-scale revolutionary change in culture. Because ITIL is primarily documentation, there is not a real threat that either approach will alter it's ability to provide consistent guidance. But giving good advice is not the same as causing it to be followed. The top obstacle to following ITIL, ironically, is still confusion. Why is this the case? Simply put, corporate IT groups are forced to move at a pace that is much faster than their ability to absorb ITIL, and they are loathe to risk, much less give up, hard-won benefits from pre-ITIL practices. Yet behind those benefits, they often don't have an effective overview of where they already are. Thus, following along ITIL's paths, they constantly run into forks in the road that don't offer the obvious correct choice. Net: ITIL is a maze.To get over this hump, they still need a way to see, in short order, how they can connect the dots between their current practices and ITIL's.
Following suit, the perspective represented in the picture below simplifies the identification of the pre-ITIL circumstances, locating the starting line for a move to ITIL without the threats of disruption or of time running out.
The key assumptions in this picture are as follows.
First, no one really cares about I.T. except for whether it is perceived and proved to be useful.
Second, there are only two major points of view on that utility: the lifecycle of items composing the IT infrastructure; and, the production that composes IT operations.
Third, all of the IT management, whether in infrastructure or in operations, is essentially about two things: how things are (i.e., states), and how things happen (i.e., transactions).
Those three assumptions, when aligned as shown, organize every critical aspect of driving value from IT utilization. From this point, the rest is a matter of additional levels of detail.
Since management is popularly understood to be impossible without measurement, and since measurement can't happen without semantics, it is hugely important that the perspective drawn so far does not rely on confusing semantics and meanwhile shows analysis as an ordinary, not exotic, activity covering the field.
Within the general framework, four main phenomena surface as the major management subjects. Driving these down into daily practices makes sense under the assumption that the point of the practices is to establish value in the utilization of the info technology involved.
The utilization is established on two fronts. One is to give form to the actual information technology that users can ultimately access and exploit; this is what is called "IT Services". The other is to give form to the mechanism that creates and sustains that access and exploitation; this is what is called "Support Services".
In an unconventional but easily proved distinction, IT Services is about the provision of the IT configurations; whereas, Support Services is about linking the IT to usage requirements, as systems for use. (These systems are essentially and primarily logical, and secondarily take on physical form as the peculiarities of the company hosting them might allow them to at any time.) Usually, in effect, it's the difference between supply and demand, between service level management and service level agreement, and so forth.
As seen in the picture, the two kinds of services cover (i.e., attend to) the four major subjects in a certain way.The types of services relate to each other because they work on the same subjects. But the services differ from each other in what it is about the subjects that are the key points of their respective concern and influence. These key points are added into the framework's quadrants to clarify the high-level of analytic detail that really matters for the services. This level of detail is the one that initially accounts for the co-existence and co-influence of the two generic types of services (IT and Support).
For followers of ITIL: the difference between IT Service and Support Service is not indicated in the normal ITIL vocabulary. Instead, the generic concept of "management processes" proxies Support services that bring IT services to the user or customer. ITIL largely provides a taxonomy of those management processes, and most observers first engage the taxonomy of "delivering" IT Services (defining and developing them) versus "supporting" IT Services (maintaining and optimizing them). But at least half of the trick in adopting ITIL is to orchestrate its management processes into standing "Support Services" as described in this discussion's framework, which is oriented towards managing the value of utilization.
Posted by Malcolm Ryder at 4:50 AM | Comments (0)
January 16, 2007
CIs, IT and the Good Life
Still, of the three historical areas, Asset management handles most of the money issues and thus often exerts more of a business profile, tending to lay more claim to entrenched authority. Thus its perspective gets a chance to influence thinking in other practices, and the most popular of these cross-over ideas is the idea that items have a "lifecycle".
"Lifecycle" expresses the notion that there is orderliness in the entry, habitation and exit of items within the life of the business itself -- an orderliness imposed by the accountability required of management. An item's "asset lifecycle" covers its birth-to-death milestones that describe how it originated, how it got into utilization and fared there, and how it ended up when no longer needed. All of this stems from a business preoccupation with ownership of the item, the presumed target of all benefits and risks.
Most recently, Configuration management has reared up as an alternate perspective for the accountability of the impact that an item has on the business. A "configuration" is a description of those salient characteristics, particularly in the perspective of the intended "best" utilization for successful work outcomes. If the item is a "business resource" (which of course all IT should be), instead of just business property, then the characteristics of the item are important because they indicate whether the item is fit for the purpose imposed by its utilization. It matters, then, whether the item actually has the desired characteristics, in the heat of the business moment. It is very unfortunate that the term "item configuration" was displaced (for some reason) by the relatively obscure term "configuration item".
Systems management has historically been responsible for making practical characteristics come about in real operational time. But at the business level, Systems management did not offer enough of the authority of "standards". Although "business" would "require" technical standards, there was still a gap between the technology and the logic of the actual utilization that came from business behavior with the technology.
As a result, while items might still have been seen as assets or as systems, there needed to be another way to represent the behavioral standards of the relationship between the business usage and the technology used. This standardization and representation took the form of defined Services. The relationship of the item to the Service became indicated by the item characteristics that were required by the Service -- and those identified characteristics are the "configuration" that defined the item in terms of the service. Thus we have the "configuration item", or "CI"...
Asset management's influence and lust for lifecycle accounting inspired the notion that, since most CIs are assets, CIs must have a lifecycle, too. But taking the notion only that far, confusion has sprouted about what point there is to calling the lifecycle a "CI" lifecycle as opposed to an asset lifecycle. Why have two different names for the same thing?
The answer is that the true lifecycle of a CI is not the same thing as an asset lifecycle, nor the same as lifecycles that might be imagined for engineering, nor other disciplines that manipulate the item. A CI "lifecycle" is not about the management accountability covering the concerns of:
- development
- ownership
- availability
- performance
Instead, a CI lifecycle is about management's accountability of the item's impact on the integrity of a Service. (Service Integrity is a shorthand label that we'll hang on to for future reference to this discussion.)
When prescribed business behavior for the utilization of the item is set up as a service, the two key issues involved are from the service's point of view -- about the progressive degree of provision enabled and the progressive degree of support applied, relative to the state of the CI.
In the matrix above, degrees of provision and support intersect to generate the "milestone" state of the CI that represents a major phase in the CI's "lifecycle". The matrix generates four lifecycle milestones from top left to bottom right, and each milestone represents a degree to which the CI supplies integrity to the structure of the live service. The weakest is relatively conceptual at the top left, and the strongest is very tangible at the bottom right. However, it is important to understand that these four milestones or phases are points on a continuous circle; changes in business needs may require that the deployed and controlled CI undergo "re-modeling" to regain alignment (correct "service ability") with the go-forward business.
One of the most important aspects of that understanding is that an item is not necessarily always a CI: in fact, during its existence, it is a CI from some timepoint to some other timepoint, and for some service or other service. An item may fall in and out of being a CI. The matrix helps to show what management thinking and activity explicitly handles the recognition and association of an item to a service as a CI.
It is also worth pointing out that if there is a dominant historical influence on this thinking, it is actually not Asset management. Instead, as should now be somewhat obvious, the dominant relevant precedent is Architecture, which literally pre-figures and prescribes what should be approved, deployed and controlled in a structure that turns an item into a resource. Where CIs are concerned, the structure is a Service, and the business uses the service to exploit the item.
Finally, all management disciplines are essentially perspectives first and policies second. There is no logical reason why they should by default be mutually exclusive of what they take responsibility for... instead, they should co-operate by together bringing a broader range of attention to any given item. In presenting the CI lifecycle matrix, the intent is NOT to stake out an area of privilege just for "Configuration Management". As further emphasized at the bottom of the illustration, several management processes may have a primary role in attending to the CI's progression through milestones, and these roles are not unusual for most IT management teams. Not coincidentally, the concept of a CMDB will mature into the concept of a Configuration Management System (CMS) leveraging a variety of relevant management information donors in a well-orchestrated manner.addressing service integrity.
Posted by Malcolm Ryder at 5:51 PM
December 1, 2006
The CMDB as a Knowledge Base
An executive overview.
In the front-office world of a business, the holy grail of a "360-degree view of the customer" is already old hat.
Well, much of what is now happening in the middle office -- the IT world -- revolves around the criticality of utilizing a "configuration management database", or "CMDB". This database is the key to a 360-degree view of any IT asset. In particular, it is a centralized repository of information about how items are defined and situated as components of the information technology infrastructure on which the business runs.
As a singularly authoritative (or "master") source of information about the infrastructure's components, the database content is very involved in the documentation and decision support for almost any business process workflow requiring IT enablement. But what is it about the components that the CMDB describes?
Typically the components for which the CMDB holds descriptions are referred to as "configurations". A quick survey of the CMDB literature shows that would-be CMDB users can get mired in great controversy about what consitutes a configuration, because there are so many ways to segment a chunk of infrastructure IT and legitimately call it a component. After all, the notion of a component necessarily refers to the idea of some larger entity that the component helps to make up. The problem is that any entity's distinctive identity must be defined with a boundary around its scale, complexity and purpose -- but just as any category may be said to be a subcategory of something else, any entity may be a component of some other entity. Thus it may be unclear where to draw a boundary, create an object, and call it a "configuration". The question always begged is "of what entity is this item a component?"
This makes it very difficult to decide what to include and exclude -- the CMDB's catalog of entities should be neither too general nor meaninglessly specific. How many levels of categorization and subcategorization (so to speak) must the CMDB contain?
In the below, we skip all of that confusion by looking at "things" in a more objective way. First, we take the notion of configuration not as a noun but instead mainly as a verb that has a result. The focus is on the motive for action. That is, nothing in the IT infrastructure is there except through the labor of making it fit into the company of other things -- and our first emphasis is on the labor that takes place to respond to the perceived need for including something that wasn't there before. This allows us to think of a "configuration" as the output of a system of functions, and the CMDB first of all collects facts about that output (and other ones, similar or related, in the same infrastructure ) -- as accounted for by its system.
But why collect the information? The primary reason is to put management of these outputs on a foundation of knowledge instead of on hunch. The CMDB's content can fuel knowledge by organizing its information into the three main contexts that matter to the difference between being managed and unmanaged.
Managed conditions always compare the actual against the planned and the authorized. This indicates three forms of knowledge that the CMDB would support: respectively, models, analyses and histories.
The essential CMDB content will be descriptions of states generated by the functions (as illustrated above), to be evaluated in these three contexts.
However, management tends to root itself in the posture of "operations" -- with the difference being that operations are mainly about organizational responsibilities while functions are about activity. This distinction is more profoundly yet simply identified in the hierarchy of management as shown in the next table. Top-down, starting from a focus on business value, the table rows address the questions "Why are we doing something?"; "how are we going to do it?"; and, "what are we going to do it with?":..
It is easy, then, to recognize the same top-down pattern in management's attempt to associate the needs of the business with the infrastructure that would address it.
Arguably, tactics are derived from respect for the customer's agenda, and functions leverage the offerings of suppliers -- so the primary challenge for differentiated management is in the operational dimension. Not surprisingly, Operations lays out responsibility areas in a way that tends to generally reflect functions. For example, the operational chain of development/implementation/administration/support is, on the surface, an echo of the functional flow of build/release/monitor/maintain. But Operations must intentionally, not coincidentally, associate its responsibility areas with the functions it can govern, if the dynamic is to be called "management". Operations must decide what functions will "execute the infrastructure" and how.
Consequently, what management wants from the CMDB is content that helps construct the artifacts of management that should populate the following framework. In this framework, captured knowledge explains how Operations currently puts functions into the context of the bigger management picture -- the one that generates business value. That overall knowledge-based governance looks to the CMDB to fortify its perspective and acuity on what to change, when and why.
Posted by Malcolm Ryder at 11:14 PM | Comments (0) | TrackBack
October 13, 2006
How to measure IT's contribution
Flashback from CFO: Magazine for Senior Financial Executives, Spring, 2005 by Malcolm Ryder
Regarding the notion of estimating how much revenue to allocate to every kind of corporate resource in proportion to each respective resource's contribution ("Revenue Is What Matters," Letters, Fall 2004), I have to wonder what purpose there is to that.
Not being an economist myself allows, perhaps, my view on this matter to spawn a useful question. Namely, without a definition of "contribution" there is no logic to the presumed "proportion," and don't we already know from real life that contribution means impact and that impact is defined by the system of measurement?
What most of us in IT and everyone in science have learned is that we can't talk about impact without talking about complexity, which means talking about interdependencies and frequently about the obscure order found within apparent chaos. If at Company X a $50 spreadsheet program in the hands of a $100K--per-year employee results in a discovery that generates $10 million in revenue, that's a great trick. And yet even if Company Y copies the same set of "resources," it probably won't get the same results.
The reason why accountants have not set or proved the so-called value of IT is because value is not generated by resources but instead by dynamics, and accountants don't measure dynamics. I agree that what is needed is a look at the answers already found in other disciplines.
For example, meteorologists measure systems and motion, such as high pressure, low pressure, and temperature, and from that they can attribute daily and even hourly impact to real causes instead of merely to gases. Likewise, coaches who actually know how to coach can tell you that the influence of the most talented player on the team can turn the team into a loser, where a much lesser talent can influence the team to win and so gets put on the field.
So the key is to break free of the notion of "resource" that is rooted in a concern for corporate property and learn to see that the elemental dynamics of situations are the real resources.
For most companies, the closest they come to this awareness now is their understanding that some company assets, like people and technology, must service something that they call processes, with processes representing the company's hypotheses of desirable dynamics. Logically, then, the process is the closest they come to defining the resource that should claim some of the credit for the revenue. What does the process cost, and how well is it managed?
Malcolm Ryder/Chief Strategist/Renovance LLP/
COPYRIGHT 2005 CFO Publishing Corp.
COPYRIGHT 2005 Gale Group
Posted by Malcolm Ryder at 9:56 PM | Comments (0) | TrackBack
August 12, 2006
Should we measure the ROI of IT?
Imagine not knowing whether spending on IT had any beneficial economic impact.
Should we measure the ROI of IT? Of course we should. But first we should learn how.
The ROI of IT is not difficult to understand. Confusion often begins with a poor articulation of the so-called "justification" for spending on technology. It's convenient to think of the justification as being synonymous with the return, but that hasn't prevented corporate America from deciding that it doesn't know what the ROI of IT is, has it?
The way out of the usual confusion is as follows:
1. Begin by understanding that you are spending on an *effect*, and that the technology is just a means. As the famous saying goes, "people don't buy drills, they buy holes."
2. Understand that "means" are not the same thing as "causes"... Despite automation, people decide what tools do. Decisions will either subvert or support the desired effect. Decisions create or destroy ROI.(See various writers, notably Paul Strassman, on the subject "Return on Management".)
3. Naturally, if the means have poor quality and are unsuitable to the task, they will inject either compensatory or remedial costs that will lower the potential overall economic benefit. But this "lowering" is because the potential extra cost of using the lesser-quality means is really a resource taken away from other more viable investment options. Returns are not found in budgets. Returns are found in portfolios.
4. Understand the actual role of IT. IT is simply a player on the bench. The game is won by the value of the plays. If you give your players the right assignments, then the play is run well and the impact of the play moves you to the goal. Assume that a poorly designed or inappropriate play will waste even a great player.
In sum, understand the difference between having IT that is good enough to enable the execution of the play, versus having plays good enough to win. You must invest in both, not one or the other. But IT does not cause the win. Except as regards IT's affect on the play, you cannot measure the ROI of IT with arithmetic; and since spending on IT is not usually the same decision as spending on strategy development, the correlation of IT spending against revenue or profit deltas is actually arbitrary for companies weak on strategy and IT architecture.
Posted by Malcolm Ryder at 10:16 AM | Comments (0) | TrackBack
August 7, 2006
Read once, Write many
Gil Grissom of Las Vegas CSI drills into the remains of Archimede's diary, featuring lots of smack about various Greek colleagues and babes, written during any of a series of famous bubble baths by which Archimedes is said to have discovered both buoyancy and the principle that ink smears.
According to story, jealous Christian scribes drained the tubs and wrote retaliatory remarks right on top of the original texts, thus inventing "tagging" and setting the stage for the South Bronx grafitti wars hundreds of years later.
Credits
Gil Grissom: Uwe Bermann, Stanford University's Linear Accelerator Center physicist, points to ...
Words: from a manuscript by Greek mathematician Archimedes at SLAC in Stanford, Calif.,
Gizmo: a high-power particle accelerator, set on "tickle", not "stun" or "kill"
Photo: AP Photo/Paul Sakuma
Posted by Malcolm Ryder at 6:56 AM | Comments (0) | TrackBack
August 5, 2006
Write Once, Read Many
And now, from the folks who brought us People Process Technology, this just in. The world's oldest computer chip, custodianship credited to the IBM Museum of Technology.
NOT.
Hey -- remember "PalmScript" ?
"Etch-A-Sketch" ?
"Unified Modeling Language" ?
"Moses" ?
"Bite marks" ?
Credits
Concept: Renee Ryder Mellon
Artifact: A tablet, said to be 7K yrs old, found in Bolivia. Look it up here...
Picture: belongs to the Associate Press. Bug them, not me.
Posted by Malcolm Ryder at 12:16 PM | Comments (0) | TrackBack
July 4, 2006
Business Value in IT Strategy
This picture describes the way that IT planning perspectives share the responsibility for discovering, integrating and balancing business priorities stemming from financial, environmental and operational requirements.
Strategists should consider, for example, how to place opportunity versus risks, resources versus capacity, and architectures versus agility.
These placements will then call attention to the nearby surrounding influences of real options, change management and economy of scope -- influences on analysis and design efforts in developing strategy with the apparently available opportunities, resources and architectures.
Those influences set the perspectives from which opportunities, resources and architectures are considered. The picture shows that they are related perspectives. The relationships feature overlapping perspectives, such as "risk mitigation" being handled by both real options and change management.
As a result of organizing within these influential relationships, strategic positions can enjoy inherently systemic support from the interplay of financial, environmental and operational events. This alignment of support makes the positions more sustainable, allowing the business to use them as a reliable foundation for its ongoing execution.
Posted by Malcolm Ryder at 11:02 AM | Comments (0) | TrackBack
June 16, 2006
I.T. Been Berry Berry Good To Me, Part Two
Our colleague Howard Hastings writes in:
Fundamentally, I agree with your concluding statements: that statistics from "the analysts" based on relatively small survey samples using questions of a naturally subjective nature are NOT very useful - unless accompanied by the explanations (read: deep and broad thinking) behind those questions and the final premise.
HOWEVER, I believe that the CIO Magazine article highlighting the Forrester numbers largely misses the key point - "IT Decision Makers" are NOT well positioned to properly and successfully influence the business (i.e. innovation).
Why? For those of us who "stumbled" into IT from business backgrounds it isn't that difficult to understand - IT people too often can't/won't adjust their own mindset and delivery to effectively communicate and/or work with business people. Essentially, "logical thinkers" generally don't see the need to empathize with the "targets" of their ideas … the notion that "experts" should be required to understand the motivations and perceptions of mere "users" is, in itself, irrational.
Anyone familiar with "personality typing" (Myers/Briggs, Keirsey, et al) will easily recognize this behavior and the inherent challenges it represents.
That said, I would strongly question the validity of successful innovation driven by "IT Decision Makers" being awarded a score of .200!
I suspect that most, if not all, of the innovation success came as a result of IT being TOLD that they needed to achieve a particular objective. Anyone who has been involved long enough in IT at senior levels who can be reasonably rational with themselves will admit that technology itself addresses AT MOST 30% of the overall solutions to business problems. The rest comes from people, processes, knowledge/content, etc. -- H.G.H.
Which reminds me of what I left out last time... the best examples of IT effectively driving innovation are examples where the use of IT was the actual basis of the innovation. But this still leaves two other issues to deal with. One of them is that the innovation might have been a highly successful output of IT, but the business built on the innovation might still be pretty poor business. The other is that there is a difference between innovative technology and innovative use of technology -- the point being that just saying "I.T." doesn't tell you much about what is actually happening. For more on this difference, search Archestra for the discussions on (a.) operations and competency; and on (b.) invention versus innovation.
Posted by Malcolm Ryder at 1:06 AM
June 14, 2006
I.T. Been Berry Berry Good To Me
The best quote of the year so far: from Romano Prodi, former president of the European Commission running for prime minister of Italy against incumbent Silvio Berlusconi back in April. Said Prodi about Berlusconi, "you lean on numbers like alcoholics lean on lamp posts, not to be enlightened, but for support..."
Yeah. That's the spirit! Numbers should be fought over. A bunch of new ones from Forrester, in CIO Magazine, show IT organizations doing the same old same old, when it comes to providing value to the business. In this report, IT's top batting average of .380 against Business Pitching feels bad, but that's really hot in baseball.
Just Makes You Think: Oh yeah, that's right... this stuff is pretty hard...
For the sake of skirting copyright, I memorized the information so I can now fearlessly just "tell you what I remember"... OR you could go see for yourself online (or...the June 15th hardcopy includes the Forrester survey numbers chart).
I remember that Forrester said:
1 - Improving productivity or products/processes rates in the high .300's
2 - Optimizing cash flow or customer lifecycles hits the mid to low .300's
3 - Powering successful innovation in process collections or in product collections steps in the mid to low .200's. Wipe your shoes.
But what do these numbers mean?
First, the way Forrester set it up, the batting average actually represents the number of "IT Decision-Makers" who gave IT strong credit when given the chance to do so. For example, almost-but-not-quite four out of ten gave IT credit for improving productivity or likewise for improving products.
Now, looking at the numbers and what they are attached to, is it insane to say that the more complex a problem is, the less likely IT is going to make an obviously critical contribution?
We know the problem complexity rises as you go from the top of this list (e.g. productivity) to the bottom (e.g., innovation). Why?
Well, in each case, think of the number of variables that are reasonably under critical IT influence as they combine with each other. In order of appearance:
- There are simply fewer of them when it comes to improving productivity or improving products/processes. (We didn't say the tasks were any easier, we just said simpler.) That level of influence is a lot like construction work.
- But the next level -- optimizing cash flow or customer lifecycles -- is more like winning poker games. More participants trying to not be on your same page.
- And the remaining level -- innovating (reconceiving, not just improving) products or processes is more like herding cats. More participants who see your page but could care less.
Here's the main suggestion. As we drop down the list, and move from productivity to optimization to innovation, the necessary influence on the variety of participants who need to buy in becomes increasingly less a deliverable of IT.
Going along with that, we can still hope that IT can contribute to the necessary influence. But then of course, we must identify what kinds of influence are necessary, before we can understand whether IT can make a significant contribution.
What this calls for is a perspective in measurement that can recognize and understand the game-saving catches, the turning point singles, the continuity of getting players on base -- the things that go missing in games that are not winnable. Eveyone sees the home runs, but most of the time, most games are won by most players being good enough to allow a win. Their individual responsibility is to be good enough for the other players, not to win the game by themselves.
The Forrester numbers superficially tell the story a little differently, but let's decode them. Given what was argued just above, they suggest that very few of every ten IT Decision Makers understand the difference between how well IT does its part and how likely it is that the IT part will "cause" a win. This further suggests low understanding of what it takes to win at productivity, optimization and innovation. That is, statistically, some of the decision makers may have given 100% credit to IT for effectiveness, but those that gave little or no credit (due to lack of understanding) dragged the Forrester averages down.
Meanwhile, the reason why batting .300 in a game is good enough is because it's enough to allow the other parts of the operation to add up to a win. Batting .300 represents about 100% of reasonable expectations, not 30% of requirements. The decision-makers who gave IT high credit likely saw this.
So the numbers we see from Forrester are not what we really want to see. Instead, we want to see the explanations given by the decision makers who credit IT with high effectiveness, and compare those explanations to the ones given by the nay-sayers.
Post Script: Saturday Night Live was a hit before lots of IT people were old enough to tell a joke. If you're older than that, you might remember Chico Escuela played by Garrett Morris, who broke the line that we cloned for the title of this article, but who for all we know now works in IT somewhere as a decision maker.
Posted by Malcolm Ryder at 4:48 PM
April 2, 2006
Business-IT Alignment: Revisiting ActiveROI
By the time the Y2K threat got serious in the corporate mindset, IT innovation had already reached a point of viability where replacing old stuff had to be taken as a serious alternative to patching it.
But it wasn't just the technology that needed to be reconsidered. As it is almost automatically remarked in the business conversation about IT, related people and processes also were in the mix -- and here came the dot-com wave.
Among various other things that "e-business" did to reposition IT in the enterprise, it gave an old teaching instrument a new meaning.
You may remember the elementray school spelling aid "I before E except after C"... For it's new web-era use, I translated it to mean "infrastructure before engagement, except after customer." The problem new to the day was that the web was now allowing customers unprecedented aggressiveness in dis-intermediating the corporate mechanics that ordinarily actually provided services. Customers emerged who wanted "do it yourself" relationships, while others emerged who simply had no patience any more for companies that mired them in internal production technicalities.
Effectively, in both cases the customer's punchline was: "if your I.T. doesn't make me happy, change it or I'm gone."
The hugely superior economies of keeping existing customers versus gaining new ones made the most sense of my new translation. But the implications for IT organizations were not really so new. The point-of-view on IT's operational performance just shifted from I.T.'s "internal" customers (business units) to the company's "external" customers. Internal customers had already had this attitude for a while, and everybody knew it.
Still, despite external customers suddenly getting their hands directly on company infrastructure, it seemed brutally obvious that IT organizations should not be held responsible for managing external customers. (Otherwise, what were business units for?) So the message really needing to be drummed was that internal customers needed to be better empowered by IT.
By abstracting the basic management steps to that empowerment -- resources to operations to relationships -- the model I first proposed set a floor under a wide region of research, from which several key further items grew. Among those, a major one well-rehearsed by 2002 forecast the IT Organization agenda as in the article CIOs: Managing the business's IT Agency.
Then, what brought that agenda to the level of the full CxO group was the problem of linking IT performance to enterprise performance. This problem enjoyed a huge rise in importance due to the maturing acceptance of having enterprise applications automate essential operations cross-functionally, despite hair-raising complexity in integrations and change management. While I liked referring to the celebrity of the problem as "Enterprise Chance Management", it wasn't much of a joke since it was also becoming more obvious that business opportunity was relying more and more on IT-enabled responsiveness.
Given the huge level of investment recommended by Y2K, enterprise applications, and the internet, the business need to understand the value of its IT capacity hit a high point that called for a way to put the IT agenda into a model of being managed by the business. In reply, I created (and own) the ActiveROI model -- a construct signifying the generation of business value from IT resource optimization, achieved in a continuous and proactively matured discipline. Translating the model into practice methodology, the consulting firm Renovance, LLP went to market. Renovance's elaboration of methods for applying the ActiveROI model was indicated early on in the whitepaper, "ActiveROI: Achieving Business Processes and IT Infrastructure Alignment through Real-TIme Management". (As a consulting firm, Renovance developed and offered trademarked practice methodologies of my copyrighted model, in its lines of business.)
From a CIO's perspective, the ActiveROI model describes that the enterprise's engagement with the marketplace runs on an organizational platform created by architectural and portfolio management disciplines that can coordinate IT.
But overall, ActiveROI understands performance in terms of relationships and the services that maintain them, while it understands resources in terms of events and the investments that address them. The critical thing to note is that services and investments are the two most highly discretionary offerings of the executive management of the business -- effectively defining the identity of the business that will predispose its opportunity in the market. As explained by ActiveROI, this "drills down" to the IT agenda and its business alignment.
By way of ongoing explanations and by hosting comparisons and debate, Archestra will continue to elaborate the ActiveROI model and several of its already-in-progress successors or offshoots -- including Archestra Runtime by myself, and works that certain colleagues may finalize for presentation via Archestra in the future.
- Malcolm E. Ryder, April 2, 2006
Posted by Malcolm Ryder at 9:50 AM | Comments (0) | TrackBack
March 14, 2006
Finding the "Enterprise" in IT
In running the business with a strategy, strategy must increasingly factor IT into its equations, because of IT's power to affect most of the conditions to which strategies design a response.
Going along with that, the working assumption is that a business organization must have IT-based capabilities that allow it to beneficially maintain and change itself in its target environments. A standard caution is that IT can always make things different, but that "different" is not necessarily "better" -- and the definition of "better" must come from the business.
Given those points, there is a logical hierarchy of values in IT-based business solutions. To reveal it, however, requires clarity about the difference made by automation and the difference made by information.
Superficially, we always recognize that information directs decisions and automation directs labor. But decisions also commit that labor, while taking into consideration that automation can change the feasibility of the commitment for better or worse.
As a result, we see that decisions drive automation -- meaning that information drives automation, not vice-versa.
Arguably, then, the top business issue to address with IT is to govern information access.
This makes the overall affair of IT management primarily sensitive to the successful provision of information driving the decisions. But what is meant by "overall"?
I. Solving the right problem
Keeping in mind that decision-makers are placed at all levels and locations of business production, adequate visibility and control of provision is a gigantic and daunting task. Processes that govern information access are the ones that most need to be automated.
But the point of governing that access is to ensure that decision-makers are supported securely, appropriately and efficiently, so that they can pursue business objectives.
This point provokes a general model for the relative business values of IT-based solutions. The importance of having this model is to set expectations consistently and to provide the most basic logic behind changing existing investments in, and implementations of, IT.
The solutions should contribute to one or more of the following very broad objectives, which flow top-down from the main desired business capability to the supporting functions, architectures and assets:
Taken together, the four concerns add up to maximizing the quality of the IT infrastructure as a business resource.
Specifically, solving the combined concerns -- governance, rationalization and optimization -- results in a positive ratio of resource capacity to business demand, which then allows strategies to "close the loop" by exploiting #4's ability to enhance #1.
II. Optimization
In optimizing resources, businesses rightfully ask, "how capable can we afford to be?" Regarding IT, this is a general way of pointing at the problem of return on investment. It might casually be seen as a cost/benefit ratio. But the flaw in seeing things that way is that, with adequate production supervision, benefits are simply desired outputs that are more or less predictable according to their price; to generate real business value, those outputs must still be used in certain ways.
For example, buying a computer and using a computer are quite different. In the first case, an asset becomes owned; but in the second case a resource is deployed (committed). Ownership and deployment have different kinds of value. By linking assets to live functions, deployment makes IT serve the business.
With this commitment, the natural inclination is to pursue as much functional potency from the asset as possible, and discard the asset when it can no longer measure up. That potency may even result in enterprise-wide impact.
Yet more importantly, the method and opportunity for achieving that potency may not be scalable cross-functionally or enterprise-wide. So this is not the gist of the notion of optimization nor of "enterprise" IT. The enterprise-scale value proposition is not to optimize the commitment of "all X number of components" but instead the commitment of the overall IT infrastructure as a resource. By analogy, it is managing an entire portfolio instead of a collection of budget line items. It is seeing the forest first, not the trees.
At the enterprise scale, the deployed infrastructure essentially becomes an environment for business operations, and IT management accordingly must step up to an environmental perspective. From that position, optimizing the environment basically means programming its dynamics.
For example: business typically organizes its information demands with desired flows of business processes -- and business processes are highly sensitive to changes forced by competition, regulation and economies. Because of that, the related IT processes that help govern and enable information access need to be not just reliable but also adaptable (i.e., versatile and/or flexible). This involves a critical dependency on the underlying infrastructure. Thus, due to ongoing change, deployment of infrastructure is also a continuous "environmental" process, not just an event.
But the programming is not just about addressing deployment for demand. It is also about support for utilization and allocation for supply.
In coordinating all three dynamics, the key characteristics of environmental-scale management feature an extent of visibility and control that intends to establish productivity and conservation in balance with each other.
As part of the environmental programming, management establishes the generally required conditions for this balance through several means:
- policy (which protects priorities versus requests)
- standards (which protects regularity versus options)
- security (which protects integrity versus exposure)
- economy (which protects assets versus consumption
While those protections are a major deliverable of management for achieving balance, the value of that balance at any time is determined by its relevance to business goals. That is, management's other key objective is to have the balance actually promote business development.
The problem is that business development so frequently pressures management with local demands that challenge the global balance. This threatens the environment's equilibrium, which increases the uncertainty about its overall quality versus additional and future demands. Because of that, what management wants is the visibility and control to maintain the environment's equilibrium while knowingly raising its overall quality as a resource.
III. Rationalization
The strategy for having that visibility and control requires a focus on services and architecture. Services predefine the relationship of deliverables to demand; and architecture predefines the relationship of capacity to services. The predefinitions allow the organization's managers (or providers) to offer things already known to fit into economies and scales, and locations and permissions, that they can handle -- and to more readily recognize and decide about things that don't yet fit. Among those things that don't fit are not only newly-emerged requirements awaiting organized support, but also potential threats to the integrity of the established services and architecture.
Unfortunately, the growth rate of a large IT environment may often have outrun prescriptive efforts to define it -- raising the number of exceptions, silos and risks. This simply means that it now has to be retrofit within the terms and principles of architecture and services -- that is, those become the elements of rationalizing the environment. The descriptive language of services and architecture will supply a different perspective from which to identify and assess the environment. Subsequently, discoveries will be made that indicate a need to make changes that will conform the environment to business requirements.
IV. Governing with IT processes
What this really means is that the environment at minimum has to be "trained", not necessarily rebuilt, and programming the environmental dynamics begins to accomplish this. But eventually the programming might require reorganizing things in ways that reveal omissions, defects or obsolescence in the resources, whereupon rebuilding is appropriate.
The challenge is to have adequate visibility and control of any reorganizing. Critical information gains or loses availability and credibility according to how its channels are gated, groomed and connected. Knowing that infrastructure modifications will range in types -- from innovations to deployments to shoring-up defenses, and from strategic to hostile -- policy and change management take on an enormous significance. Meanwhile, the implementation of business policy and business change increasingly must be supported through IT, and this means that business policy and business change must also be translated into IT policy and IT change. That translation must not be speculative, and the outcomes must be explicit.
V. Business management
From the business point of view, the purpose of relying on IT is to bring significant assurance to the safety, competency and advantage of whatever the business tries to do. For IT to offer this kind of value, it must be manageable, and the complexity of its manageability is the main barrier to the business being successful in the driver's seat.
To the extent that complex technologies can make technology management simpler, complexity breeds value by giving the business more practical influence on IT, of the kind that it intends. (Today's automobiles are the most complex ever, yet they are easier than ever to drive.) But the success of the business is predicated on its ability to tailor responses in real-time to the particulars of each opportunity event. Any given response -- a blend of characteristics including safety, competency and advantage -- may need to be significantly different from others, yet crafted from a known available capacity.
Thus, from the business standpoint, the enterprise IT management goal is to achieve the lowest cost of predictably sustaining the necessary degree of enterprise-wide adaptability of the infrastructure. With that established, business processes and business performance can in turn be more readily managed to business targets.
Posted by Malcolm Ryder at 1:20 PM | Comments (0) | TrackBack
March 3, 2006
Driving IT Bang for the Buck: Evolution, Improvement, or Innovation?
When we think of effective IT spending, we're focused on making the best current use of the money, given competing alternatives or emerging options. But increasingly, the basis of effectiveness in business spending on IT proves to be in how the business manages its reliance on IT.
Sometimes we don't have enough visibility of legitimate alternatives and options. The urgency of our attention to the purpose that justifies the spend means that this lack of perspective could be left unsolved. But for that reason, a diligent evaluation practice looks for opportunity costs that should be factored in. As part of this diligence, what remains to be emphasized even more is not how the IT will make the organization work, but rather how the organization is going to make the IT work.
I.
In the full cycle of management, the business first conceives and identifies why IT is needed before it makes any other decisions. To avoid taking the need for granted, this first decision means describing the business model in terms of what potentials are granted it by available IT. That is immediately followed with a forecast of how sustainable those potentials are -- which necessarily means identifying and selecting how to make them sustainable.
When that architectural aspect is clarified, the next part of the decision cycle must create a "delivery" organization that can constructively practice the architecture. This means two things:
- establishing the sources and resources that will produce the infrastructure from the architecture, and
- establishing the processes that will link IT production cycles to business operating cycles.
At that decision stage, reliable design and reliable production easily wind up being qualifying criteria used to distinguish the various opportunities, organizations and risks that the business will incorporate as the elements of realizing of its model.
Thus, investments in their incorporation aim to relate reliability to the goals of business. That aim immediately offers a perspective from which a high-level assessment of the current business investments might be done. Normally this makes us think of metrics; but as pictured below, the main point is to allow the perspective to stage comparisons and guide questioning. Here we might just catalog known commitments by critical business goals.
II.
Those commitments might then involve or indicate spending on IT. But, as described there and below, the associated "IT investments" are not about IT per se but rather about the application of IT. We can understand the idea of "application" by considering the purpose of the IT utilization.
- At the highest level of distinction, the business goals of incorporating the opportunities, organizations and risks are recovery, health or growth.
- Within each of those goals, sub-goals are development, maintenance, and change.
- And within each of the subgoals, another sub-level features assessment, design, and control.
Consequently, it is possible to ask questions at the management level such as, "Can we control the maintenance of our health?" or "Can we assess the development of our recovery?"
These are not IT questions -- but they are questions that present opportunities for IT to enable successful management outcomes. In turn, management is focused on enabling successful business outcomes.
Taking that framework of IT incorporation as the main perspective, it is easy to appreciate that business utilization of IT is nearly always altering something -- either a behavior or a current state.
The importance of how IT is managed, though, is in how well IT supports management's ability to intentionally change how the business can behave. (From here on we'll consider "change" in this larger context.)
III.
The observation just made emphasizes that we can and should compare the kinds of value offered by different classes of change, and then associate IT's effects to those values -- as contributions.
To demonstrate that, compare evolution, improvement and innovation.
Relative to each other, these kinds of change differently affect the state of the business:
- evolution permanently modifies the fitness of the business's model to the dynamics of the environment in which demand develops;
- improvement modifies the fitness of its conduct to the current and targeted demand;
- innovation modifies the fitness of its output to the needs of the environment's population.
According to perceived conditions regarding recovery, health or growth, business executives must determine when any of these three modes of change requires higher-priority attention. A timely reaction is mandatory, but proactive change is potentially strategic to optimizing the benefit versus risk of those conditions. That may result in new or extended initiatives to create the necessary related sponsorship and opportunity, including competencies and technical support that might drive spending.
To support a proactive stance, a good device to have would be a framework for envisioning, monitoring and ultimately predicting circumstances that we can agree will signify a need for change. Not coincidentally, those circumstances have the look and feel of key ideas offered within the business justifications for IT spending. That device might look like the following:
IV.
But given those considerations, executives and managers together should ask the "big picture" questions -- for example, whether an improvement initiative is the most likely candidate to produce better recovery, as opposed to an innovation initiative. At the same time, it is important to recognize that one kind of change may be an element of another kind and acquire priority that way. After all, form allows conduct, and conduct (i.e., production) allows product. As another more specific example, innovation may accelerate evolution, and improvement may create more opportunity (security, income, knowledge, etc.) for innovation. Thus, an improvement initative can strategically foster the goal of accelerated evolution. But likewise, the requirements for supporting an adopted innovation may obsolete improvement efforts dedicated to earlier production, eliminating that legacy cost while potentially releasing resources for new purposes.
These interrelationships are characteristic observations in portfolio management.
IT management must be focused on applying IT to business operations present and future. On the one hand, it is typical that an IT budget might be evaluated in terms of how much spending goes to "maintenance" versus "R&D" and so forth. Those generic classes correspond to how IT responds to the business requests for support.
But the rollup of dollars into those classes can easily obscure the more important and time-sensitive issue of whether the right things have been selected for maintenance, or the right things are being pursued through R&D. By calling for a distinction between wise spending and merely approved spending, we get to a conversation about how management leverages IT for the business -- as opposed to mere responses. In that conversation business and IT organizations together find the logical path to measuring the effectiveness of the decisions, and to measuring how much that effectiveness was worth.
The view that unifies their concerns is not one about how "IT investments create business value", but rather one that business value subscribes IT.
Posted by Malcolm Ryder at 8:16 AM | Comments (0) | TrackBack
March 2, 2006
Optimizing IT for Business
Business always enjoys the ability to directly engage IT resources as a response to business needs and robust technology markets. The business can directly drive the sourcing and provision of IT into its operations.
But the consequences of that engagement extend far beyond functionality and expense, into the broader ecologies and economics of the organization's health and growth, affecting business value and business risk.
Designing the business reliance on IT as a strategic outcome of resource management requires logically managing the investment of IT assets into models of service governed by accountability standards for business relationships and business performance.
Inserting management into the Business-IT engagement, IT operations create effectiveness on the basis of service capabilities that balance for the business demand and supply (of IT) over designated periods of time within the boundaries of funding levels.
- Catalogs and Contracts prescribe demand.
- Portfolio and Lifecycle management prescribes supply.
Between the value propositions associated with demand (justifications) and with supply (options), standards for practices in sourcing (buy/build) and provision (deploy/support) create more predictable and secured scenarios for balancing costs, risks and quality -- in both the availability of IT enablement for business functions, and likewise in the capacity.
The logical linkage of Services, as established by architecture and agreements, provides a basis for continuous measurement and improvement of the alignment mechanism established between IT impacts and business operations. This rationalizes resource allocations and optimizes the IT enablements of the business.
As a critical mediating influence on the business leveraging of IT, management brought by the IT organization (gray boxes above) sees to it that the business builds it expectations with proven alternatives.
Supporting the business visibility of the alternatives, and controlling the development and delivery of the alternatives, become logically collaborative strategic efforts between the IT and Business organizations.
Posted by Malcolm Ryder at 3:48 PM | Comments (0) | TrackBack
February 17, 2006
Executive Agenda for IT
In the diagram below, we have a bird's eye view on the major business initiatives reconfiguring the management of the enterprise's reliance on the IT infrastructure.
The view identifies that the key high-level motives of the organization are related in certain ways.
The enterprise wants to maximize the value of its autonomy and identity through decisions and actions that:
- differentiate itself in the market,
- optimize its modes of establishing impact and presence there,
- sustain the mechanisms that it uses to do so, and
- control the dynamics of its organization's internal makeup and external behaviors.
These possibilities are systemically related to each other. That is represented by the perspectives that are used to monitor the general states and conditions that presuppose the enterprise's health and/or growth. These perspectives -- governance, performance, architecture, and security -- collectively describe the approaches and models for monitoring the enterprise. The general understanding sought is of whether the way the the organization has chosen to structure itself and to act is viable for achieving its intended goals in the environment it has chosen to inhabit.
Also shown in the picture is the prominent place that stakeholders have between processes and performance.
Likewise, the key intermediary position between security and processes is typically occupied by policies.
The chain of influence formed by their inclusion explains how security is linked to performance -- meaning that the enterprise continually must balance the opportunities to which it commits against the constraints that it can recognize.
For the time being, though, this discussion focuses on the chain of influence that runs between the enterprise's two more overtly discretionary states. Governance and Architecture are both highly complex but they are also more fully synthetic designs than are security and performance, because they are less dependent on external forces to realize and maintain their intended design. As such, they are closer to the issue of the competency and maturity of the organization that can be established directly by management. The picture above expresses the target competency and maturity through identifying issues such as that standards mediate the dependency of processes on infrastructure, or that change mediates the production of infrastructure from architecture.
Taking this picture as a bird's-eye view on the top "surface" of the enterprise's structure, what lies underneath are layers of composition, for example such as "assets". The picture shown here allows us to consider enterprise assets in terms of each motive, perspective and linkage illustrated, detecting discontinuities and strengths of impact. While financial evaluations, functional evaluations (which include intangible assets), and physical evaluations of assets are already three ways to understand how assets become enterprise resources, we see more clearly in the picture here the circumstances in which any of that matters. Likewise, operations, relationships, and strategies are each layers to be interpreted.
The presumption of the different underlying layers highlights that the terms shown in the picture are necessarily abstract -- but it is that very abstractness that allows us to understand that they influence each other in an "essential" way, not just a circumstantial way. Understanding the enterprise from this model is mainly an act of interpretations. For example:
- From an organizational viewpoint, it's not hard to see the organization defining itself in terms of the linkages such as rules, systems, services, etc. by which it institutionalizes itself for attending to the primary motives.
- From a practices viewpoint, it's not difficult to understand from the picture things such as that compliance is a management responsibility that derives from the influence of rules, policies and requirements.
- From a disciplinary viewpoint, BI and BPM have evident locations and sensibly share influence on agreements or "contracts" by discovering and then formalizing the conditions for assuring appropriate deliveries.
While the abstractions and their interpretations cover a wide range of management phenomena and business objects, we'll always eventually wind up back at the huge reliance that the business has on information technology in order to just stay on the playing field. As a result, it is appropriate for IT executives to interpret IT plans, operations and impacts with this same picture of the enterprise, acknowledging that the portfolio of IT implementations can be evaluated for its completeness and effectiveness by considering how much support is being generated for the alignment and balancing of the items in the picture.
Posted by Malcolm Ryder at 3:49 PM | Comments (0) | TrackBack
February 11, 2006
Linking Economy to Profitability
After a five-year pendulum swing of spending to cutting to spending, we've managed to stretch across four chapters of the IT-Business relationship: Y2K, dot.bombing, BackToBasics, and now Compliance Versus TheTopLine.
In these chapters, the story of transitions also features patterns overlaying other patterns.
For example, over the phases, we'd see that:
- the role of an IT infrastructure was swinging from being a risk factor to a success factor, back to risk, and back again to success. Meanwhile...
-The business model credibility was swinging from supply-chain angst to demand chain angst, back to supply, and back again to demand.
With patterns like those to find and juxtapose, there is plenty of room for examination of cause-effect relationships in how technology evolution and architecture may have precipitated new phases or ended them.
No question, this examination must necessarily acknowledge both intended and unintended effects. Business reliance on IT is a double-edged sword and, as shown with space exploration, we get to know how to reach a place too soon-- but only later how to stay there, and sometimes almost too late.
Yet, respectful of the need for wariness, we can honestly look at each of the aforementioned phases and, with the clarity of 20/20 hindsight, see for each one the gigantic "DUH!" that shouldn't have had to be. Obsolecence, irrational speculation, anorexia, and opacity if not arrogance... all of them butt-kicking poisons from the business side, not the IT side.
Because of that, where the topic is "intention", there is another big story, too, about the glacial maturation of what must be considered "business intelligence" (BI). Although at the moment mired in the learning curves of collaboration and analytics, BI's ultimate goal of achieving a sufficiently comprehensive perspective is perhaps represented most clearly by models such as Kaplan and Norton's Balanced Scorecard and European systems for systematically including the measurement of intangible assets, such as Karl-Erik Sveiby's Monitor and Juergen Daum's. At any rate, the rush is on for businesses to actually get smarter through intelligence -- with the twist being in the emphasis on having the right kind of smarts.
So, lessons learned: while IT makes action almost too possible and makes info almost too widely available, these are relatively intrinsic qualities of IT -- characteristics that have the great potential to simply erupt without regard to management, and therefore are not reliable barometers of business value in IT. In turn, that means we can't build value management on the basis of those characteristics.
The real issue for management is not to "enable IT" to do those things but instead to harness and leverage IT's innate ability to be an enabler itself. Business management is the source of return on IT investment.
In that light, some interesting points surface:
- The characteristic dimension of the business focus on IT management is, except for professional developers, not technology development!
- Neither, despite all the rage and benefit, is "business-IT alignment" the essence of IT management's focus on the business; that is really a business management issue.
- However, abstracting and separating the business and the information technology, the common challenge of managing IT is that IT's impact on business activity is so intense. In IT's role as a business "enabler", the critical success factor is the degree to which IT impact organizes the business rather than dis-organizing it.
Business management must step through the logic of that success. The logic has at least these three pillars:
(1) From the business perspective, for IT to be nutritious and non-toxic, the basic business need is to deal with what it is about the business that IT aligns and how IT does that.
(2) The responsibility for managing IT's role belongs to the business, not to IT. Responsibility for appropriate production within the role belongs to the IT management organization.
(3) What business needs IT to do in the business, just as business needs other functional elements to do, is to align economy and profitability, so that having one of them doesn't diminish the other. The way IT does that is to optimize capacity.
I.
The way business uses IT for optimizing capacity is by modeling business management of IT's impact through processes and portfolios.
IT inherently offers the kind of speed and scale with which a business must build and sustain capacity in today's marketplace. With capacity as a mandatory "given":
- Processes are responsible for economy versus capacity; and,
- Portfolios are responsible for profitability versus capacity.
Managing the contribution that IT makes through processes and portfolios allows IT to align economy and profitability through the organizing of capacity.
The huge top-level significance of that observation is in its implications for strategy and change management. Strategy presumes to model the competitive advantage that the firm can capture from perceived opportunity, while change management presumes to stabilize organizational resiliency and thereby keep the business positioned for opportunity. But in the effort to balance risk versus value, strategy reflects demand, and change management reflects supply, while neither must actually include financial optimization to be logically valid. The fact is that they both are simply designs that are fully able to get "their" jobs done while being benignly neglectful of financial stress. The organization actually has to figure out whether it can use these designs, but if it can't use them it doesn't mean they are broken; rather, just inappropriate.
Thus, with IT being such a dramatic enabler of both strategy and change, managing IT should in particular target helping to fit the strategy or change to the organization's terms of self-sustainability. In this regard, Process helps ensure that capacity is effectively useful, Portfolios help ensure that capacity is effectively directed, and IT supports both of them to get it all done.
II.
One analogy for this is that capacity is the "stored energy" or "battery" of the business. IT is what charges the battery. Consumption of that power is where processes do their work (economy), but the application of the power is where portfolios do their work (profitability).
By another analogy, processes make capacity into skills, and portfolios make capacity into value commitments. Furthermore, between those two, management creates behaviors, from which actual outcomes derive. Since the behaviors can either propagate or negate the potential of the skills to address the commitments, the benefits of skills (economy) may or may not apply to the opportunity represented by the commitments (profitability). Business management, through generating behaviors, makes the link, using decisions to deliberately leverage the skills for the commitments. IT supports that management, by literally incorporating the decisions -- that is, by making them "actionable" (functional) and thus producing behaviors.
In short, IT must produce resources; managers must deploy them, and the business must commit them. This perspective guides the assessment of IT's relation to both performance and return on investment. IT-generated capacity can give managers of business behaviors more options, but the value of the capacity is not created by IT -- rather, by the business modeling of both the consumption and commitment of the capacity. High performance presumes successful execution of good models, but meantime the models must be relevant to the strategy. Finally, strategy must be sensitive to the possible capacity that IT can generate, without arbitrarily "assigning" value to the possibility.
III.
In what follows over the next several iterations of this document or in other followups, we can illustrate that concept in more ways, as well as more specifically. For example, business process management (BPM), business intelligence systems such as configuration management databases (CMDBs), and performance knowledge systems like operational performance management (OPM) bring implementations of information technologies to more directly bear on the model-oriented management that optimizes capacity.
But the immediate general statement to be made is that the business needs appropriate capacity to address its desired opportunity; and it uses IT to provide itself with not just capacity in general but specifically with appropriate capacity.
Understanding business from an IT perspective is of vital importance to IT providers who must come up with useful resources. In that regard, superior architects power superior IT providers.
But more important is the flip side: understanding IT from the business perspective means understanding what business management decides to do with IT. IT management must take its direction from business management. The directions it takes are mapped out in processes and portfolios.
Posted by Malcolm Ryder at 7:52 AM | Comments (0) | TrackBack
February 9, 2006
Optimizing Business Services
"The more things change, the more they stay the same."
With major transformations of computing foundations happening about every seven years, this phrase doesn't seem to apply to the alignment of business and IT. Some industry writers point out that in many business organizations, by the time the enterprise was sufficiently mobilized to do client-server computing, it was practically too late -- because the internet had already arrived as the new baseline platform. For those organizations, this meant that the difference in computing from old point A to new point B was even more drastic.
But did these organizations do the same old thing with the new technology? Likely not. Executive commitment to new technology is more likely the result of first becoming aware that the right things to do now are different from the earlier things, and can't be done properly with the earlier stuff.
On the other hand, how about the parties that want to do business with the organization? Did they want the same things as before? Over the timespan of the technology transformation, new products and services were envisioned and launched in the markets, in some cases creating new businesses. Some of those new businesses were possible because the new technology made it viable to be a producer or provider of the new product or service. But all of them were possible because a customer, partner or other sponsoring stakeholder made it worthwhile to spend what it takes to create the necessary quality of the product or service. There was always a limit, though, to the amount of spending that is tolerated -- pressured not so much by the level of demand for the product or service as instead by the need for the "investors" to preserve their other ongoing opportunity.
In this scenario, spending on IT has had the very large burden of efficiently and desirably linking the timing and level of production investment to the level of quality delivered on demand.
This investment-versus-quality perspective sounds and feels like "cost-vs.-benefit" but it is primarily sensitive to the idea that both the inputs (investment) and the outputs (quality) are defined as "acceptable" by parties external to the organization. As it turns out, that imposes an excellently sobering discipline on the management of the spending -- and naturally there is then a question of whether management can live up to the discipline.
As an intermediary force between investment and delivered quality, managing the organization of information technology in the enterprise structures the spending allocations around business terms like "effectiveness", "performance" and "compliance" -- major indicators that the use of the investment is reliably headed towards the goal of delivering sufficient quality. For the recipient of the product or service, quality is not an imbedded characteristic of the product or service; instead, it is actually a measure of the compatibility and impact of the product or service under conditions of use. Producers can always aim for "good enough" quality, but they have to be diligently attentive to when and how the user raises, lowers or otherwise changes the standard.
We are generally accustomed now to thinking of IT assets synonymously with "investments", since the assets proxy for the actual original investment inputs. But in that, the inherent problem is the difficulty of assuring that the asset will in fact support outcomes that get measured as positively effective, highly performing, and reasonably compliant regarding the objectives of the associated stakeholders.
Effectiveness
To ensure that the asset does provide appropriate support, it is managed for its availability, its functions and its interactions -- through requisitioning, engineering, deployment and support.
The results of those management approaches are inventories, systems and processes that are used as building blocks for services that the business will provide.
The most general challenge in this management comes from the variability of demand; different users need different things at different times and places, and to produce appropriate responses the organization has to navigate production options that let it stay within the boundaries set by requirements. Management's dual task is to accomplish whatever levels of requisitioning, engineering and deployment are needed to satisfy the customer, but to also satisfy more general operational requirements for net effectiveness, performance and compliance.
Performance
With these potentially competing requirements and constraints facing them, management may employ a wide range of tactics, mixing and matching them in various models of delivery and support. Thus, the objective, by definition, is to leverage complexity for value.
But this can mean that availability, functions and interactions are determined, contributed, or controlled by different parties at different times. The reliability of these parties' participation becomes a dominating risk factor that itself must be addressed through a variety of means including standards, monitoring and agreements -- all of which must be practical, sustainable and enforceable within the period of related demand -- then ultimately changeable when demand itself changes.
When the internet reached its first critical maturity level as a platform, most organizations were suddenly able to see how much the stakeholder's reliance on the business management of IT could drive the IT operational agenda. Enabling customers through the business's IT became a competitive mantra. But malfunctioning IT could disable the service needed by a customer relationship; and at the same time over-engineered IT could languish in underutilization because it was not stimulating, or not connected to, a priority demand.
The twin needs of management to minimize disruption and waste while producing value and opportunity make optimization the most important word in the management strategy. But an inherent problem in optimization is coordinating the management of multiple subjects; they require a common reference for value (from production) and for progress (from execution).
Optimization
Business services, described properly, offer the common reference. As a production, the purpose of a business service is to leverage the functionality of IT for the customer . In execution, the service addresses business requirements, with a predictably acceptable combination of cost and quality.
The full definition of a service always includes the requirements to which it is intentionally exposed. To optimize the service, managers must be able to logically associate the requirements analysis with the characteristics and attributes of the service.
Defining those associations and tracking events related to them generates a description that all managers can share, helping each manager to identify when activities in their respective domain are significant to the state of the service. Monitoring correlations of events across the domains can establish critical factors of success and risk for the service performance.
By definition, "Performance" refers to the level of achievement towards a target responsiveness under demand. For managers, this includes a key distinction that must be maintained. The distinction -- between business service performance and IT service performance -- is important to the understanding of how managing IT creates value in the business.
- The performance of the business service is largely a matter of targets that are defined by the customer's perspective on fulfillment of needs. The customer is a client of the business. Business delivery of tailored fulfillment is a major objective.
- Meanwhile, IT functionality that is organized for the business service is managed as an IT service to the business. IT service performance is based on targets that are defined in terms of the business's perspective on provision of enabling resources. The business is a client of IT. IT provision on demand is a major objective.
Posted by Malcolm Ryder at 5:18 PM | Comments (0) | TrackBack
January 21, 2006
Top Ten Things Everyone Should Know About ITIL
1. The celebrity and challenge of CMM (capability maturity models) redirects focus away from the true value of ITIL -- ITIL is about maturing the business competency of IT organizations.
2. The competency means organizing capability so that it has business value.
3. Management processes, collectively, are the link between IT capability and Business demand.
4. The management processes must be integrated in order to continuously coordinate the involved assets, events, requirements and demand.
5. The tangible deliverable of the integrated management processes is an IT infrastructure for Business.
6. The intangible deliverable of the integrated management processes is IT service assurance for Business.
7. All deliverables can be evaluated; specified deliverables can be measured.
8. Measurement is only one kind of information necessary for process integration to successfully support the business. Belief, preference and priority describe the business in a way that critically constrains success.
9. There is no such thing as ITIL "Compliance". Instead, there is compliance to requirements that are ITIL-compatible, but the requirements are defined by the business, not by ITIL.
10. ITIL is a framework of models for implementing management processes, not a rulebook of technical standards for managing implementations.
Posted by Malcolm Ryder at 4:03 PM | Comments (0)
January 12, 2006
Compliance versus Compatibility in ITIL implementations
A key challenge of organizing service management practices along the guidelines of the IT Infrastructure Library (ITIL) is the issue of focusing on the objectives of practice as opposed to the mechanics of practice.
ITIL addresses this challenge by describing what differentiating effects of the practices are the ones that service managers and service customers should see in common as an outcome of any of its given management processes. These differentiating effects are where value in management improvement is measured.
The virtue of the followup process recommendations is that they link to those values by describing proven approaches to generating measurable and relevant results from the execution of the service organization.
The important execution results fall into two broad categories: interactions and outputs.
That may seem obvious, and it reflects the ITIL adopter's natural emphasis on processes. But what most organizations must remember to observe is that execution involves procedures, priorities and decisions blended together. Processes are just a mechanism for predictably binding those components of execution together, given the resources and culture of the particular organization that is responsible for conducting the process. By definition, the process cannot "override" those organizational elements because it is made up of them.
Every organization has specific characteristics of its resources and culture that can significantly vary or even disagree with those of another organization -- and even between one part and another part of the same organization. These differences stem from business requirements, funding histories, current knowledge, and other preconditions. Yet these disparate organizations have in common basic business functional responsibilities such as managing IT services.
In acknowledging that, ITIL clearly refuses to specify any particular resources or culture, but instead it provides operational objectives, along with numerous models for supporting them in the form of management processes.
When the organization prepares a service management process from an ITIL model, the process is said to have a degree of compatibility with ITIL.
The main goal of an ITIL Adoption initiative is to establish a known and measurable level of management process compatibility with ITIL.
Management processes have three fundamental purposes that link the ITIL compatibility to typical business needs for cost management, procedural effectiveness, and adaptability. Within the constraints of expense, target impacts, and change, the purposes of the needed management processes are, generally, to account for:
- why something should be attended to;
- what kind of attention it should get; and
- ensuring that appropriate attention is applied.
The first purpose is to establish regularity in associating response procedures with identified demand. Service stakeholders need to have a good idea of how demand will be handled before the demand is urgent. Key tasks to perform include:
- classifying and monitoring demand
- defining procedures and their scope, and
- granting permissions to both requestors and responders.
The second purpose is to establish the terms by which historical and current events will be described for triggering assignments and for analyzing changes in conditions. Key tasks to perform include:
- establishing quality-managed information repositories
- tailoring communications to fulfillment and auditing roles
- regulating the capture and transmission of critical event data
The third purpose is to prescribe enforceable responsibilities in the participation of all parties to a procedure. Key tasks to perform include:
- defining roles
- allocating resources
- tracking interactions and results
Meeting those three general obligations will result, respectively, in the development of rules, terminology and authorities. These management artifacts are typically used as building materials for organizational functions-- and can normally be used to compare a current organization against another current or any future proposed organization. However, those materials are not inherent indicators of functional performance; as with any resource or construction, their value to performance comes from how they are used, not from what they are. This reiterates the primary importance of objectives in the scheme of things, and that the notion of best practice is rooted in the objectives rather than in the procedures.
To sum up the above observations, an organization takes on an initiative to adopt ITIL guidance of the development and implementation of management processes that are compatible with service management objectives.
The guidance proactively reinforces desired levels of consistency with known best practices, but the guidance does not specify an organization's particular processes.
Rather, it helps to model process design and development for effective support of the key objectives of the service provision and relationship.
Posted by Malcolm Ryder at 12:26 PM | Comments (0) | TrackBack
Why You Can't Comply With ITIL
ITIL provides a framework of practice guidelines that offer a business-like model of managing IT operations.
To use ITIL effectively, comparisons need to be made between the resources and other commitments suggested by those models, versus resources and commitments that, for the given timespan under consideration, are certifiably available to and from the organization that wants to follow ITIL guidelines.
That comparison reveals the options and risks that:
(a.) get translated into decisions about what priorities and tolerances will be attached to actual resources and commitments, and
(b.) are controlled thereafter by management.
The translation, in other words, produces a set of requirements that are logically compatible with ITIL. These requirements can be intensively site-specific as well as idiosyncratic of the particular business.
The next step is to execute management processes such that the organization will comply with its peculiar ITIL-compatible requirements. The result of the compliance to those requirements means that the organization will become to some degree compatible with ITIL , even while potentially differing substantially and significantly from another ITIL-compatible organization.
The actual degree of compatibility is recognized as a level of "ITIL" maturity. But almost irrelevant to ITIL itself is the set of things about the organization that are not yet compatible -- irrelevant except to the extent that those incompatibilites are actually inhibiting or preventing further ITIL-maturation.
Meanwhile, at every point and level of ITIL-maturation, the impact of compliance to the ITIL-compatible requirements offers some amount of practical and measurable impact on the business, and that impact (whatever it is) will be examined in terms of "business value". The level of business value is not guaranteed by ITIL -- rather, ITIL helps to design greater opportunity to generate more value.
The actual business value of the impact will be strictly dependent on the strategic objectives and competitive positions of the business operations -- a set of issues for which the validity and scale lies entirely outside of the models of ITIL guidelines. But the business operations are logical "clients" of ITIL-guided improvements in IT operational competency.
Executives and Managers need to understand the difference between ITIL-Capability, IT's Competency, and IT Capability.
IT's Competency seeks to exploit improvements in IT capability as modeled by ITIL. But IT's Competency is essentially defined in the relationship with the client of IT: "competency" is a consistently appropriate responsiveness to the real-time demand of IT users.
ITIL-guided improvements achieved in IT capability can contribute to that competency through the benefits of good management. Management takes the responsibility for generating value from whatever level of IT capability currently exists, for whatever reason it exists.
But additionally, managers want to see that actual capabilities, if they are being modeled after ITIL, are getting stronger. This is a separate and important problem because of the burden that adopting ITIL places on organizations, when other paths to capability improvement (outsourcing, hiring, etc.) might be feasible from the perspective of the business.
Thus, organizations need to understand what level of "ITIL-capability" is necessary for the business at the different levels and segments of the organization, and not attempt to over-shoot the demonstrable business feasibility.
But management should primarily aim in all occasions to achieve ITIL-compatibility as a way to improve IT's Competency.
In light of all of the above, the notion of ITIL "compliance" is at best an abbreviation that helps to market ITIL's importance along with general commitments to standards. This might be an acceptable and even productive metaphorical take on ITIL. But at worst, if taken literally, the notion of ITIL "compliance" sends the organization and its management off on an expensive and furious path to solving a non-existent problem.
Non-existent? Case in point: organizations that are not really very mature in their ITIL-compatibility may still be entirely capable of generating high business value from IT operations; it just depends on what kind of demand the business is placing on them. This is at least historically verified, although it may not be true of most businesses past or present.
That said, for even successful yet immature organizations, the issue is one of whether their economies of scale and "economies of quality" allow them to be agile enough to keep up with evolving business demand. That is, will their capability offer enough to be competent? Here, the key point is this: synchronizing actual responsiveness with actual and foreseeable demand is "good enough", while pursuit of a hypothetical perfect match to some other model is arguably irresponsible unless it somehow magically places no unacceptable burden on being immediately good enough.
IT Capability improvement is thus a parallel consideration to IT's competency improvement. In particular, if the business determines that it is not being demanding enough to achieve a reasonable level of the potential represented in the business model and business plan, IT's capability might become a decisive new factor, with greater capability offering the business new kinds of opportunity that can be exploited for greater business value, and lesser capability being an all-around inhibitor.. This is not , however, a business decision that is essentially dependent on ITIL-maturity -- and certainly not dependent on a false concept of "ITIL-compliance."
By analogy: you're not likely to win a playoff game if all you have is your third-string rookie quarterback -- a not very mature quarterback. But in such a case, winning now instead of losing now will require having the right (probably other) persons call the plays, having the right additional roles execute well, and having everyone use the same system of coordination so as to maximize efficient pursuit of the only advantageous paths to the goal. Your longer-range intent will always still be to bring a great quarterback into your game. On the flip side, adding a great (very mature) player to an average team can obviously improve the team by adding new dimensions to its options and execution. But the rest of the team must be capable of taking advantage of the quarterback's ability, and it may need to be reorganized in order to gain that capability.
So, if your organization has an ITIL Initiative and you are frustrated with a perceived lack of "progress", it is entirely approprate to first review whether expectations are driven by a definition of the right problem to solve, and likewise whether the requirements that performance assessment is based on have been derived primarily to represent competency instead of merely capability.
Finally, if your primary perspective and responsibility is "compliance", then you are engaged in an initiative whose fundamental justification is risk management, not competency. In this case, there is no built-in conflict from using ITIL as a frame-of-reference, but the performance assessment should be based on measured changes in risk factors that are demonstrably linked to capability levels, not based on competency-driven business value factors.
Posted by Malcolm Ryder at 10:12 AM | 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 30, 2005
When Rules are required, Requirements rule
Business has a history of asking for IT to enable new capabilities, and IT has a history of giving the business those things while falling behind itself in the same progression of operational management improvements. So when the "non-expert" business users establish the norms that are acceptable for these capabilities, it is ironic that IT has to learn the capabilities from business.
For many years, consultants have had the capability of explaining the difference between business requirements, implementation requirements, and infrastructure requirements. This set the stage for also explaining the relationship of the three sets of requirements.
But the value of that capability would simply shift around according to who was the most influential sponsor (aka, the client) of the development project the consultant was working on. Meanwhile, the importance of aligning the different requirements was too difficult to prove except where enterprise architecture was taken seriously.
Now, as provided by today's IT, the visibility and control of operations is giving the business experiences and awarenesses that extend more "democratically", enterprise-wide.
As part of this awareness and experience, rules are much more in the foreground as stabilizers and optimizers for decision-making. Basically, rules describe the decisions that have been made and approved about how responsiveness to demand is to be implemented with risk and efficiency already factored in.
But because they are ultimately aimed at demand, rules derive their real significance from how they relate to requirements. So in fact it is requirements management that establishes the environment for effective rules management. Requirements will drive the need for aligning rules, but it will also drive the need to change them. Decisions about requirements themselves are always the most important issues to get right, while technology becomes a critical tactical factor in whether those decisions are actionable and thereby practically meaningful for business value.
Thus, because technology is "globally" increasing direct awareness and the ability to do something about it within the organization, it almost automatically becomes necessary, instead of optional, to manage rules strategically.
Michael Voelker, writing in the November 1, 2005 issue of Intelligent Enterprise, discusses Business-IT alignment in terms of how responsibility for managing business rules is balanced across the organization.
Such responsibility may be presumed even before the capabiity exists to live up to it. But with IT, the business can best help itself by ensuring proper support for IT production.
So, two key thoughts follow on that story. One is about management maturing from a special professional function into a general organizational competency, thanks to IT distributing the opportunity to decide effectively.
The other thought is about how increasing experience, enabled by IT, becomes expertise that loops back to the conception of what IT ought to be doing. When business uses IT to drive "better IT", both parties win.
In the case where IT allows the business to more freely allocate responsibility, the business gets something new, but the business viewpoint on what should be possible then feeds back to IT in ways that will change IT by making it more like a business. What we're seeing, in effect, is a practical iteration of enterprise architecture, with enterprise-wide adoption finally possible through more tangible terms.
Posted by Malcolm Ryder at 7:19 PM | Comments (0) | TrackBack
November 28, 2005
ITIL, Optimization, and the Performance Management Approach
Business derives value from the utilization of IT in the same way that it derives value from the use of money or people: the business applies the asset to enabling those events that have a designed ability to impact business conditions.
Assets may be applied directly or indirectly to the target event.
- Directly, the asset is deliberately "consumed" by the event itself. This involves using the asset as a material element of the event. The event may employ, transform or exchange the asset, in order to produce another output.
- Indirectly, the asset may be used to deliberately affect circumstances surrounding the target event. By "circumstances", we mean conditions surrounding the moment or location of an event.
Consumption and circumstances often develop independently, and they often coincide without much resistance on the way. But management's intent is to replace coincidence with planning, and move consumption and circumstances to co-operation .
If cooperation didn't need to be planned, we wouldn't need management. For this concern, the proper focal point is not the assets, but the events in which they are involved.
I.
In producing cooperation, one of management's primary responsibilities is to establish compatibility between the circumstances and the consumption. With assets at stake on both sides, competition for the supply and deployment of assets is an issue. Since no event goes unfollowed by others of equal importance, organizations need to know what will happen to their capacity as an aftereffect of the cooperation.
In effect, whatever requires the cooperation -- namely, the target event -- is seen as something that must either conserve or replenish assets, so that business will be continuous and ongoing instead of episodic or temporary.
Yet placing that restraint on the target event must not prevent the event from bringing the needed impact on business conditions.
This reflects a broader principle: environmental conditions are part of the "infrastructure" for business functions, and meanwhile, consumption (business function) has prerequisites (specifications). Circumstances (environmental conditions) have effects (states) that must productively correspond to those prerequisites.
This "productive correspondence" of current specifications and current states is exactly the compatibility being sought from management.
Consequently, it is evident that the key issue is not asset management; rather, it is event management driven by business requirements -- which is the ordinary description of business capability.
II.
The history of the business capability is largely recorded in the history of events that occurred under the pressure of demand. As pictured above, an "event" is the overall result of interacting capacities and requirements. Thus, we easily expect an event to vary widely as the number and strength of influences on its separate elements varies. The primary threat to manageability of events is the inability to control that variation and maintain a useful synchronization of the elements.
In periods where management efforts are successful, events are the normal focal point of attention to whether the business is getting what it desires from IT. The benefits of events are the most ordinary measure of success. When event benefits fall short of desires, then the typical approach is to look for what disabled the event from being beneficial. This disability will usually be found in either of two areas: one, the context of the event (as in time and place); and two, the makeup (causes) of the event.
In accordance with the "event model" discussed so far, we can especially appreciate thatprocesses are used to place controls on the makeup of an event, so that the event's final character is appropriate to desires.
Ideally, a process predictably selects and coordinates the event's elements, with as much aggressiveness and detail as necessary to assure the needed character of the event. By increasing the process's ability to reliably find and control necessary event elements, management can mature the process to a point where the timing and location of a certain type of event also becomes more and more predictable -- which is hugely valuable to selecting and organizing responses to demand.
Process-modeling (now evident as a form of "event-planning") usually seems highly convenient to management. Mmanagement readily adopts a "process" approach to designing and cultivating desirable events. And more maturity in the approach promises the business greater opportunity to create (or find) and leverage advantageous business conditions, strengthening the approach's justification.
But acquiring strength and quality of maturity cannot be taken for granted. This means, in turn, that the assumed benefits of processes are always to some degree uncertain to occur.
“Complexity is intrinsically predictable,” Wharton management professor Saikat Chaudhuri notes, with a very major caveat. “If one places sufficient resources and project management strategies in the right places, it’s possible to manage the complexity. You can learn how to do it. But uncertainty, by its very nature, requires constant adjustment. This type of flexibility is tough to achieve, especially in the middle of integration activity.”
Challenges to process maturity are a part of the uncertainty, affecting the makeup of anticipated events. Another big part is shifts in demand, which reflect changes in the context of events. This indicates a need for an alternative to process management to serve as the lynchpin of business value.
III.
In the discussion that is most interesting to business people, the working definitions of "performance" pertain to the generation of value versus demand. Business runs on competitively satisfying external party demands -- and it is constantly translating those external demands into demand on its internal constituent organization. In that light, maturing the management processes for events-- which links an organization and its environment -- is a critical aspect of managing improvement in performance.
Yet with management process maturity in place, the unpredictability of demand remains a highly significant type of uncertainty threatening management results. Because uncertainty is a fact of life; organizations must simply take a useful position against it.
Thus, complementing event management, the most critical aspect of deliberate performance improvement will be demand management.
Consider "benefit" in a general sense, as a constructive impact of an event. The effectiveness of management is measured by the benefits delivered, and events deliver the benefits; so we continuously scrutinize how we manage the enablement of the necessary events.
But without at least hypothesizing alignment of events to demand, it is difficult to foresee what "benefits" (if any) will likely be obtained -- thus leaving operations without a significant justification. Demand management represents the "business dimension" of overall operational alignment -- events are planned specifically against the known or expected range and scope of variability in demand.
This makes it clear that "performance" always presumes a capability with a justification -- and that is the most important slant that ITIL has on IT management.
IV.
Being able to foresee benefits is essential to executive responsibilities for planning. With planning, we chart the overall path from capacity to events to benefits to demand. The path must be accurately envisioned as management efforts.
The IT Infrastructure Library (ITIL) documents key principles and practices that organize the IT management path from capacity to demand. In describing how organizational resources are used to conduct the practices, time-tested examples of management processes are offered that show the coordination of distributed assets, utilization controls, and business requirements. Because processes are so important to implementing the management of these factors, process integrity and maturity are enormously important objectives of ITIL's information. Yet often the approach to understanding ITIL is too easily distorted by a competing perspective -- not the necessary one of "implementing management" but instead the habitual one of managing implementations.
The misfortune of this latter perspective is that it significantly discourages understanding and appreciation of ITIL at the organization's executive business level. The key to repairing or avoiding this situation is to understand how ITIL information helps to describe the management of events that characterize the business capability.
Performance Management is an evolving discipline that uses forms of communication and visualization that are strongly suited to mapping the origins of and connections between an organization's assets, functions, events and demand.
To maximize the positive influence of ITIL in the organization, performance management instrumentation can bring two things to executive attention:
- relevant business issues expressed in terms of the ability to impact events; and,
- the improvement of that ability as a consequence of pursuing compatibility with ITIL.
The target effect of the ability is to drive benefits that improve the infrastructure for business functions.
The key is to communicate this ability to drive benefits as more a cultural effect than a merely mechanical one.
With the more conventional "mechanical" view, the active drivers of business benefits (from events) are usually more about linear procedures, assignments, and accounting -- concepts that gain their meaning at deep levels of granularity and organizational segmentation. Their main objective is to establish compliance in the organizational activity, which fosters predictability (a lower risk) and scale (a benefit).
In contrast, by "cultural" we mean that the active drivers of business benefits (from events) are goals, priorities, and agreements -- concepts that need to be collectively meaningful across the organization. The main objective is to establish compatibility within organizational diversity, which fosters agility (a lower risk) and resourcefulness (a benefit) in the focus on demand and progress.
One thing we want to know is whether the two approaches shape different kinds of events in order to deliver benefits in their different ways.
V.
Rather than assume that a given business problem can be solved by differing benefits, we normally assume that the problem calls for a certain benefit and that we can get it, if necessary, from more than one kind of event.
But generally, events are cultivated not only to deliver certain benefits but also to do that with certain characteristics.
.
In driving the benefit, any advantage of the cultural approach over the mechanical would first be researched in how it addresses management's responsibilities for producing three critical delivery characteristics:
- functional excellence,
- quality, and
- economy.
Typically, each one of those characteristics can be framed as a measurable effect of premeditated standards, expertise and efficiency -- factors that go into shaping the events that are the source of benefits. So, what we can consider is how a cultural version of these factors differs from a mechanical version.
Standards, expertise and efficiency are all intended to maximize the stability and continuity of the health of the business by "optimizing" organizational responses (events) that generate benefits. Stability and continuity presume that the way the event occurs should leave the organization in the best shape to both use the benefits immediately and make additional future efforts. However, "management" brings intentional design to the way the event occurs. So, we look for the "optimal" outcome in the effect of the design.
- From a cultural standpoint, "optimal" means that risk and opportunity are in balance.
- From a mechanical standpoint, the "optimal" concern is the balance of cost versus output.
Within either case, the challenge to stability and continuity is fundamentally the same: despite the uncertainty of demand, which increases complexity, achieve an intended balance.
VI.
Optimization is the name of the effort to resolve the complexity. Optimization is not just opportunistic, but instead it follows a model, to logically pursue the highest priority outcomes. Here we have two models from which to choose -- a cultural approach and a mechanical one.
A cultural perspective on standards, expertise and efficiency does not exclude or contradict a mechanical one. Both perspectives emphasizes the idea that managing uncertainty in business is a critical success factor, and they both aim for stability and continuity of the business.
Instead, the cultural perspective argues that both stability and continuity are predicated on goals, priorities and agreements -- and that goals, priorities and agreement require dynamic and collaborative maintenance.
To associate either approach with the needed business benefits, we start by identifying and cataloging the functional expectations and targets that we attribute to them regarding:
Standards -- how they contribute to functional excellence,
Expertise -- how it contributes to quality
Efficiency -- how it contributes to economy
That is, we look at each of those as evaluated from the perspective of:
- business opportunity and risk (cultural)
- execution output and cost (mechanical)
The group of findings generated about the two approaches represent our expectations of them. Those are then immediately set against the logic for creating business benefit. That delivery logic will necessarily include these two components:
- The organization's availability of resources must be sufficient to realize the expectations.
- The combination of resources must amount to the "means" for generating the events that deliver the target business benefit.
Initially, the question is whether the necessary means are evidently "more likely" to be generated and sustained for the cultural or mechanical approach. But shifting demand changes the focus.
Understanding how to deal with demand means acknowledging the challenges of complexity. Complexity features a multitude of moving parts trying to come together to hit moving targets. Generating value from the complexity is tough:
- the organization must be resourceful enough in its diversity...
- to engineer appropriate events in real-time...
- from circumstances that have variability frequently exceeding "best case" or ideal formulas.
Dynamic, collaborative access and utilization of resources may be the only path to meeting a business need -- the path facilitated by the cultural approach.
The difficulty of the cultural approach is that it is more complex and thus is harder to organize and measure in a singular, objective way. Addressing that problem, the evolving discipline of performance management provides a solution that can consolidate these influences in a centrally manageable view.
Given that, the general importance and advantage of the cultural one is that it proves to explicitly relate to a wider range of demand on the business.
VII.
Demand management is staged as a shared responsibility of business and IT.
In planning, monitoring and measuring the coordination of resource diversity and demand variability, executives find that performance management can track and illuminate IT's contribution, position and progress.
In turn, leveraging ITIL should be done in ways that aim to maximize consistency and persistence in coordinating diversity with variability.
ITIL's guidance offers IT and business stakeholders a single way for both parties to see requirements and operations. The alignment cultivated through that common view reinforces expectations that consistency will increase in the Business-IT relationship.
The business intends for that consistency to translate into business capability, but the range of needed capabilities introduces more complexity against the intended operational effectiveness.
ITIL describes ways to resolve the complexity, towards consistency in the IT enablement of business capability.
With IT organizations expected to implement management that cultivates beneficial events, bringing ITIL to performance management helps the IT organization to describe the logic and importance of the difference that it makes -- i.e., "IT's value" against demand.
Posted by Malcolm Ryder at 12:11 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
November 10, 2005
Is ITIL "strategic"?
As the shared literature on ITIL seemingly moves into the billions of pages, organizations wonder simultaneously how to get a grip on it and what the real prospects are of getting more out of it than must be put in.
What's not in debate is ITIL's importance as a scientifically attractive set of practice guides, ones which can launch IT organizations up the stream of a business's progressively increasing ability to derive value through enhanced quality:
- Practices -> Standards -> Resources -> Investments
This way of describing ITIL's impact also shows that there is a significant distance to traverse between practice and strategy.
All strategies hypothesize a relationship between operational choices and the effectiveness of outcomes. In fact, while we tend to think of a strategy in terms of "cause-and-effect", it is more realistic and accurate to think in terms of choices-and-effectiveness.
Naturally this puts emphasis on being able to define the type of effectiveness that is targeted -- after which we make relevant enabling choices. On one level, business seeks to make itself more valuable through its operations. On another level, business seeks to make its operations more valuable through the use of IT. Since its investments in IT are fashioned after that intent, the quality of its IT investments is what the business wants to strategically enhance. ITIL offers abundant guidance to "the business strategy for IT."
ITIL's management points and goals can be summarized in a now-classic itemized fashion. But more importantly, they can be stated and grouped to reflect where key business intentions about enablement through IT are addressed to extract, drive or protect value.
Utilization
-Incidents: Restore normal service operations
-Availability: maximize effectiveness of real-time business function access to the IT infrastructure
-Continuity: control risks to availability
Control
-Problems: Manage infrastructure errors
-Changes: Maximize efficiency and minimize risk of infrastructure changes
-Capacity: cultivate and evolve the infrastructure to cost-effectively meet expected business needs
Environment
-Configuration: control and report the versions of all infrastructure components
-Release: plan and manage deployment of infrastructure components
-Service Levels: manage operational compliance to IT user agreements
Operations
Service Desk: maintain a single point of contact with business consumers of IT services
Financials: manage the economy of targeted service delivery and support
Business Advocacy: bilaterally manage the formal relationship between IT provider organizations and business IT customers
Since all of those management points and goals are desirable, the main adoption issue is to distinguish them by both importance and urgency. That will drive a prioritization of the many initiatives that would support adoption of ITIL guidance in the form of operational procedures.
Identifying importance and urgency in terms of "business needs" is where links between ITIL and strategy can get forged. In general, "important" means that something is a success factor towards the need, and "urgent" means that leveraging it must be pursued in an immediate window of opportunity if its benefit is to be assured.
Satisfying the need invokes activities that IT can or should support. The quality of that enablement is generated and fortified by the IT management practices, and improving the practices draws on ITIL. But the practices must focus on how to organizationally support the established urgency and importance. So, for example, this might translate into pressure for agility, scale, economy, or other qualities -- to be met and maintained by moves reflected in the framework below:
In this framework, IT's alignment with the needs of the business is seen from an ongoing performance perspective instead of just as an individual event. The business looks at alignment by assessing how key objectives representing "successful" IT responsiveness are handled in four significant areas of business requirements. Each area of requirements is a distinctive one that represents limits and expectations on business activity. ITIL offers guidance for improving capability in each of these objectives and areas. The business, however, must determine which objectives and areas are the ones most relevant to the current and imminent need.
Combining an objective with a requirements area is a way to describe the nature of the problem to be solved, and a capability is a key solution approach. While capabilities can combine for greater effect, as is shown in great detail in the ITIL guidebooks, their value should still remain visible in terms of success addressing discrete business problems.
Managers who are thinking in terms of scorecards should consider that any capability should be measured in three ways:
- the level of capability in terms of benchmarked comprehensiveness (as inherited or trained)
- the effect of the "as-is" capability level on the problem to which it is applied (as prescribed or designed)
- the capability's impact over time across the variety of circumstances presented by the operational lifecycles and evolutions of the business (as implemented or contracted)
Appreciating the noted capability status and history, managers should look into what requirements area of the framework most prominently features relevance to the business problem at hand, and gauge the match or mismatch of capabilities within the area. This will establish evidence that certain capabilities are logical starting points for systemically improving IT execution.
Posted by Malcolm Ryder at 9:00 AM | Comments (0) | TrackBack
October 20, 2005
Information as Product -- or, the buck stops here
"When information is free, only bums will have information." - M. Ryder, 1998
Ephraim Schwartz, editor at large at InfoWorld, shot out a cautionary this week about the impending extinction of CIOs.
The trajectory he drew is pretty straightforward: CFOs have personal accountability sign-off for the "version of the truth" sold to stockholders and checked by the government, the auditors, and the law -- so the CFOs are grabbing the reins of information management.
At first blush these reins are the decision-making authority about the actual "systems" used to manage the information. But here's a quick thought: since the systems are composed at least of the tools plus the processes, are the CFOs taking decisions about the processes away from CIOs, or just decisions about the tools?
Thanks to the rapid evolution of business process management (BPM), it looks like that question is actually worth asking. Because of BPM, we know the following: on the one hand, a faulty process might be running on perfectly capable tools; on the other, even mediocre tools might be properly enforcing a good process. Who is responsible for what?
That kind of difference lets us know that there is a real distinction between what the CFO really needs to worry about (the information management process) as opposed to what else there is to worry about (the technology management process). It's just too hard to believe that CFOs want anything to do with the technical architecture other than to enjoy good cost/quality ratios from it.
Says Schwartz, "As far as I can tell, in the future IT landscape, the CTO, rather than the CIO, will report directly to the CFO." This is consistent with the idea that the CFO has either absorbed or dissolved the "CIO" job, leaving a different technology guy still in place. But not all information management is about the CFO's reporting. A lot of bits and bytes whip around just to make sure that other things get done, like mail delivery or content backups or customer verifications. The question still begging: is there a chief process guy?
It's fun to torture the holy trinity of people/process/technology for many reasons, but one of them has always been the apparent arbitrariness of not having the CTO accompanied by chiefs of people and chiefs of process. Strategically managing the capacity for targeted production quality would be the mission-in-common for these chiefs -- and yes, it's not whether they exist by other names but whether they are given that mission. But managing the actual performance of the production mechanism is still a different issue.
In terms of production, information is a product, and it seems that Schwartz foresees the CFO stepping into the role of senior-most product manager to minimize anxiety about the "performance" of information management.
If that's becoming true, there are two ways to consider this further. One, why shouldn't the CIO position simply evolve into that "product manager" role? And two, should there also be other product managers, aside from the CFO, who are responsible for the other ways that information must service the company?
********************************
Stop the Presses. Elliot King is the editor-in-Chief of BPM Strategies (the members-only publication of the BPM Institute / BPMinstitute.org) and chair of the Dept. of Comunication at Loyola College in Maryland.
His article, "Process Management Approach Leads to Competitive Government" discusses how the Florida Dept of Revenue did not wait for performance management standards to be legislated.
The DOR is building balanced scorecards for each of its core processes. Florida DOR has identified 70 core processes. Dale Weeks is the chief business process and leadership officer at the Florida DOR.
Let the games begin.
Posted by Malcolm Ryder at 12:40 PM | Comments (0) | TrackBack
September 19, 2005
Productizing IT Resources for Business
Directly or indirectly, a "business-view" of IT always asks the basic question, "what do we have and how can I use it?" This perspective connects IT capacity with business capacity, implicitly relying on provision being managed to the requirements of the business.
Given the dazzling diversity of options and sources in all things IT, a framework of "business requirements" will put pressure on the provider to work not just as a supplier but as an agent. In that case, the availability of "appropriate" and "manageable" IT is assumed by the business but realized by the provider. The business attributes value firstly to the provider's process for satisfying business requirements -- and relies on that process.
Successful realization of the right IT for business is essentially the same problem of "bringing the right product to market"... Timing, cost, quality and availability are all success factors in the value of production and provision. Among the worst case scenarios are to bring the right thing at the wrong time or the wrong thing to the target location -- emphasizing why the definition of demand is a dominant issue.
The basic challenge for the provider is to manage value end-to-end from production through provision. Using a simple working definition, practical "value" is the effective difference made towards intentions. In that light, we can easily see that "value" is generated in different ways under different circumstances while across all of that variety it also maintains a common focus on the intention of meeting the demand.
Functioning like a business, the provider has four key stress-points along the course to fulfilling demand. At each stress-point, the balance amongst the success factors cited above can be manipulated to some degree. As seen in the illustration below, each point (bottom left to top right) can significantly support an adjacent point in the chain, so improvements at each point can optimize the overall throughput of value to the final provision. The process alignment cultivates value.
This example highlights the management related to minimizing the risks to the stability (reliability) of the IT environment, as seen from a business point of view. This view features the concern for the value of "what we have" and "how we can use it" -- each as supported through managing capacity and controls.
Posted by Malcolm Ryder at 7:47 AM | Comments (0) | TrackBack
September 18, 2005
IT Value versus Business Value
Many of the problems in understanding "IT's value to the business" stem from the desire to jump from point A to point D without going through points B and C.
To trace the proper connections, some basic working definitions are needed. Here, "performance" refers to the relative level of achievement through execution, while "value" refers to the importance of the difference made by the performance.
From that, the points "A through D" in question are:
A - IT Performance
B - IT Value
C - Business Performance
D - Business Value
The usual assumptions are that "IT value" should be measured in terms of business performance, consistently associating the utilization of IT with the business outcomes in a causal relationship. But since IT cannot be used effectively by the business unless IT is managed, the first criterion of IT's potential benefit is whether selected IT resources are appropriate to their intended usage. IT specifications make it clear that "IT performance" must establish the "rightness" of the employed IT for the responsibility planned for it.
Next comes the manageability of the selected IT resources, which determines the day-to-day "value" (i.e., the effective difference to intentions) of the IT.
But successfully bringing the tool to enable the business task does not mean that the task will necessarily be executed well. The harsh reality is that many tasks are now originally formulated on expectations that are impossible to support without IT -- yet the tasks have other dependencies as well, and IT will not "cause" the task to succeed. Meanwhile, utilization of IT per se may be suboptimal, most likely due to complexity and competition in its deployment.
Respecting IT's power to inhibit planned execution, business-oriented management of IT can take a highly proactive stance on mitigation as a support strategy for business capability. The goal is to actively cultivate an operating environment with high compatibility to business performance objectives. For IT leverage, these compatibilities most notably include IT resource management (ITRM), business process management (BPM), change management (CHG) and network/systems management (NSM). In the picture below, we see how business-level concerns with managing the operations environment surround yet are joined by the IT management areas.
In these areas, minimizing inhibitors to leveraging IT resources effectively fosters greater ability to concentrate on driving productivity towards planned and actual impacts that distinguish the business's value.
Posted by Malcolm Ryder at 10:47 PM | Comments (0) | TrackBack
September 14, 2005
The Business Value of IT Operations
It's safe to assume that every IT organization leader in every mid-to-large sized company is being pointed by the company executives at the need to demonstrate IT's "business value". To ultimately survive this challenge, we have to avoid proving the wrong thing for the right reason, and avoid proving the right thing for the wrong reason...
I.
Debates seem basically unavoidable when it comes to deciding what "business value" means. But until the meaning is defined, it's difficult to decide on what should really be included for demonstration. Not surprisingly, the things that distinguish "business" audiences -- their respective roles, objectives and priorities -- virtually guarantee that there will be multiple perspectives on the idea of "value" -- reflecting role-sensitivity. Meeting the demonstration requirements for all of these different perspectives is a gigantic burden on IT managers.
Even when all the bases get covered, too often the results seem to not correlate meaningfully with the business outcomes that the executives themselves are measured by. From 50,000 feet high, Business changes while IT doesn't, or IT changes but Business doesn't... and it seems that the two things are independent -- so a lack of confidence in "demonstrated value" persists.
II.
At the core of that problem is the possibility that the wrong kind of relationship is being hunted down, for no good reason other than that it would be exciting if it proved to be true. Namely, we want IT to "cause" better business performance, because IT is tangible so we hope thereby to mechanize our success.
At some point, though, and let's take now as a good one, it becomes smarter to look for a kind of relationship that shows more consistency.
This can start with leaving behind the idea of "causal" (or systematic) and replacing it with the idea of "systemic".
An important way to address the issue of business value is to ask what business does that is done "better" due to I.T. utilization. This question, which is a particular point of view, looks at I.T. as an enabling resource for business capability. The systemic perspective looks at the influence of the resource on the whole "ability" -- which is represented by the business task.
III.
Capability enablement is achieved through operations that allow the business to leverage the resource, and that leverage practically represents the resource's influence.
To institute this, business coordinates management of those operations as a logical organizational unit within the overall management of business operations.
At that point, a big part of the complication in value assessments is that the "logic" of the organizational unit is not linear. Instead it is multidimensional due to the variety of ways that the unit should establish the leverage business seeks. This is about the variety of responsibilities invested in the role of the operations.
In the case of IT operations, we derive the dimensions from basic expectations, in this way:
- First, business enablement is not the same thing as business execution. Knowing a language is not the same as public speaking. Being trained is not the same as performing.
- Second, managing enablement is a scope of responsibility requiring attention to the form, function, purpose and acceptance of the means of enablement offered to the business by operations.
- Finally, IT operations are the provider, not the client, wherein the operations value to the business is established.
What are the key dimensions of the provider role, as seen from the business point of view?
The model below shows the systemic relationship of the four business perspectives -- supply, production, delivery, provision -- that IT operations is accountable for in its provider role of manager of IT enablement of the business.
As for the value of the provided enablement itself, effectiveness is the essential concept behind assessments.
IV.
Business's ability to use IT effectively is one of the major strategic objectives of IT operations; but effective utilization must have an objectively sensible meaning. If there is real meaning to the idea of "business value", there is no point in holding IT accountable for value outside of the context of the business's management of its tasks. The cost, speed, efficiency, control and impact of the task are representative aspects of the "whole" ability supported by the resource of IT.
The business must find that its dependency on the provided enabler was sufficient for the necessary performance level of the business task. But there is a logical limit to how much the enabler's contribution can be held responsible for the target outcome of the business task. The success factors of the business task include more than the IT component, and the idea of the task's "success" includes more than just the completion or output of the task.
Considering those issues together gives the business fair warning on how to envision IT's involvement in the answer to the question "how predictably and frequently can we do really well what we need to do?" IT does not decide what the business needs to do. But the more IT utilization can be attributed to a positive answer, the more valuable IT is to the business.
Posted by Malcolm Ryder at 9:36 AM | Comments (0) | TrackBack
September 2, 2005
Demystifying ITIL
Making ITIL useful and sustainable in practice means stepping back far enough to see what it is on the whole, and then making the right decision about how to approach it closer so that the effort is not wasted on solving the wrong problem.
ITIL is a highly detailed, highly annotated model of an organization that produces and provides information technology "services" as products.
The details largely cover issues regarding the design of management processes involved in providing services of accountable quality. The annotations largely cover issues regarding:
- the value of the services to the business user.
- the value of the services producer/providerto the business client.
Existing organizations can study and interpret the model in three main ways:
- test examples of how to institute operations
- identify success factors in functional accountability within operations
- identify potential omissions and enhancements, at the functional (i.e., capability) level, in the existing service production/provision system
Because an organization's institutions, accountability methods, and systems are all at stake vis-a-vis ITIL, the organizational model presented by ITIL is always potentially very risky to emulate.
In order to emulate the model, organizational changes are implemented according to the influences of one or more of the three ways that the model is studied and interpreted.
Investments in the changes will likely need to be strategically justified in terms of operational mission, and/or tactically justified in terms of opportunity costs.
The interpretation effort, an early link in the whole chain of ITIL-engagement events, is a typically weak link. Interpretation must be motivated, and the motivation must be shared by the operations managers and the change managers -- or at the least, synchronized .
Together, operations managers and change managers are the defacto organization. (This is keeping in mind that management is more about roles than about job titles.)
Existing organizations that do not want to re-organize can use ITIL as a comparative model.
Existing organizations that are willing to re-organize can use ITIL as a conceptual demonstration of organizational principles, helpful for guidance.
Despite such a practical and simple difference in the purposefulness, approaches to ITIL are often very confused because of the way that ITIL is usually promoted outside of managed communities of practice.
Even from comprehensive introductory coverage like that of the September 1, 2005 issue of CIO Magazine, gaining an authoritative point of view on ITIL is a real challenge due to the range of descriptions applied to each important facet of concern. In this article alone, it appeared that from one authority to another, ITIL aspects could be this, could be that, or could be somewhere in-between:
- A knowledge collection or a framework...
- Organizations or departments...
- Practices or methodologies...
- Management standards or customizable...
- Management functions or processes...
- and management of processes or governance.
The problem is not that these oppositions are mutually exclusive; in fact, they are usually interrelated. But all the terms are somewhat loaded; and the variations make it difficult to coordinate key players around the same high-priority starting point and value proposition -- which is what necessitates an approach that continually markets cross-functional capability maturity.
Does this make a capability maturity model the common denominator of ITIL adoption across all companies? No: the common denominator is strategic urgency, underwriting organizational change management at the executive level. A more complex issue is how to maintain the urgency, and a capability maturity model is instrumental to doing that.
Posted by Malcolm Ryder at 1:15 PM | Comments (0) | TrackBack
August 31, 2005
Be careful what you ask for: you might get it
IT expert N. Dean Meyer runs down the sources of confusion about products versus services, and internal versus external customers, which plague organizations trying to establish business-grade accountability for their efforts by using catalogs.
This one should not be missed.
Posted by Malcolm Ryder at 9:49 PM | Comments (0) | TrackBack
August 23, 2005
Business Enhancement and Constructive Innovation
This just in from the 23 August 2005 Member Edition of the McKinsey Quarterly: McKinsey surveyed what global executives think about technology and innovation. Their results stated:
"Fifty-three percent of CIOs and CTOs cite the ability to innovate as the most important capability for growth... [but] 33 percent of technology executives see improving their companies' current products as the key driver of growth -- a significantly higher proportion than the 19 percent who favor developing new products..."
In other words, when growth is the objective, improving existing products is more effective than developing new products, so is "innovation" -- the top tool -- primarily important for product improvement, instead of for new product development?
This is interesting largely because of the persistence with which the business value of IT is debated. Looking at overall business spending on IT, various analysts (collectively) calculate that only 10% to 30% of the spending on IT is dedicated to what is generally termed "new initiatives" as opposed to "sustaining initiatives"... On the surface, it would seem that IT is already doing what the business wants!
But that makes us wonder what IT organizations consider to be "new" -- because we want to know what part of that "new" is about growth: a little of it, or most? And does "sustaining" include improvement? Or do budgets actually leave out improvement as a target? Meanwhile, where does "improvement" best fit in: with "sustaining", "new" or both? Sorting it out looks like this:
This larger perspective helps to organize our questions and formulate better ones. For example, now we know to also ask how both new and sustaining activities contribute to growth, and we can imagine that they contribute to other objectives as well.
In fact, a better and higher-level unifying theme for the language of IT's business impacts is the idea of strategies for business enhancement. The importance of this phrasing is that it separates the problem of how something is getting done from why something is getting done.
In the case of the McKinsey survey finding, "growth" is the "why" of what people want to get done. The exact point of interest in McKinsey's findings is that the folks who "run IT" believe that the reason why products should be changed is that it will cause the business to grow. Although it doesn't initially seem like it, the baseline contrast to consider in those findings is the emphasis on products rather than on something else -- not so much about whether development is more important than improvement. What do we do about products, to drive growth?
And yet, development versus improvement is still a big issue, because those are two pretty different types of capabilities. More importantly, they are two different types of responsibilities to charge to the business managers, who either way will look for support from IT. The business, not IT, needs to establish the case for why one or the other offers the better competitive advantage that we can assume will foster growth.
II.
One of the most basic management beliefs is that growth comes from "competitive advantage". This idea means that the company's most significant difference to its customers and partners is preferable to the difference offered by other companies. Furthermore, it means that achieving the particular differentiation must be a sustainable capability if it is to be realized as a critical success factor in the business. Sustainable need not mean "permanent" -- but it does mean consistent throughout the period of need.
The secret in understanding this position, however, is that the "difference" can be of type (characteristics offered) or of amount (supply offered).
Strategically, in the customer's eyes, dissimilar offerings (e.g., products) are different in approach to their needs, while similar offerings are different in quality provided.
Meanwhile, for the provider, what the idea of "advantage" always includes is a gap of one kind or the other between its offering and other companies' offerings. The challenge in business enhancement is how to create and preserve the most opportune kind of gap.
Approach and quality are paths to two different kinds of value, so either one can be a source of advantage. This indicates key ways to think about how products are handled.
Development seems obvious as a way to tackle "approach". A new kind of product is probably the default example of "innovation". Improvement, likewise, seems to be the default for "quality". A product upgrade is a normal example of this.
In both cases, the customer or partner envisions being able to do something "practically" unprecedented due to the particular product; and the distance between the old ability and the new one is the value gap.
In fact, we should appreciate that in both cases, the value gap does not exist primarily because something hadn't been thought of before, but instead because it hadn't been available before. This is why we need an expansive definition of "innovation"...
Meanwhile, what really lies behind the notion that products can drive growth? In reality, "Growth" reflects the market taking advantage of the availability, while "advantage" reflects the supplier finding a way to expose and leverage the gap when other suppliers have not.
Therefore, consider the fact that without changing the product at all, using it in an unprecedented way might generate value where there had not been value before. The context of the product is actually more basic to value than is direct change to the product.
Said differently, if the circumstances are right, new value can be generated without a change to the product. But in turn, this means that the ideal reason for a change to the product is to increase its relevancy to the circumstances into which it is introduced. At the least, we need to master our identification of the circumstances.
III.
Taking a cue from the popular saying that competitive advantage is gained through something that "changes the rules of the game", we can imagine modeling the product's circumstances as the set of perceived rules and/or the apparent system presented by the dynamics of the circumstances.
From there, it's really a question of how we use what the model shows us.
We should assume that the model describes why availability is deficient -- but, that the problem is just an illusion that can be dispelled with one of the following:
- an alternative model (such as a different perspective);
- by closer inspection of the existing one (revealing a "loophole");
- or by high-speed iterative refinement (eliminating interference).
Thinking along those lines, here is a possible breakout of business enhancement options.
Innovation - change the rules and/or system.
Offer Choice - displace the value gap in the current model, by presenting a different model with equal viability. (Transistors versus vacuum tubes; DVDs vs. VHS)
Renovation - reinterpret the rules and/or system.
Offer Resilience - circumvent the value gap in the current model, by combining the boundaries of its given expectations in a different way. (Ali's Rope-a-Dope against George Foreman; Annie Hall's wardrobe)
Optimization – master the rules and/or system.
Offer Quality - close the value gap in the current model, by eliminating barriers to delivering prescribed features. (High-mileage SUVs; synthetic diamonds)
All three of those options can generate a value gap between the supplier and its competitors. But what is equally important is to understand what value gap currently exists in the market (i.e., the mind of the customer or partner), according to the model of the market, and then to choose the best of the three options for attacking it -- Choice, Resilience, and Quality.
In reality, because value is determined by context (the stakeholder's circumstances) more than by anything else, each of those above possibilities might be addressed through either development or improvement -- whichever is more necessary for the targeted context.
But where business growth is the issue, and growth is built on the value, is innovation primarily important as a path to product improvement instead of to development?
Our answer is threefold:
- Growth can be triggered by identifying a new kind of customer. Matching the product to the new "customer-context" might require invention and/or modification. When the customer attributes value mainly to the "new", we are saying that innovation is an effect -- but the approach to that effect might not be innovative...
- Where growth is concerned, product improvement should be seen not just in terms of quality but also relevance and availability. The point is to make the difference that is important at the time to the paying customer. In order to literally make the necessary difference, an innovative approach might be necessary, and there we are thinking of innovation as a cause.
- Distinguishing innovation-as-a-cause from innovation-as-an-effect can profoundly affect the identification of related activities and their priorities. The concept of "whole product", which includes all the issues that surround an item and successfully fit it to the customer, tells us that since customers decide the value, they practically define the idea of the product that is the set of key characteristics to be invented and/or modified.
This warns us that when we are working on operational investment objectives, the most logical generic semantics of "innovation" are that it is one approach to meeting requirements.
Innovative development and maintenance of products in their lifecycle is one level of consideration. Innovation can help meet product requirements at any point in the product lifecycle, from concept to upgrade or retirement.
But as to whether "new products" are more important to business growth than are "improved products", the matter is one of whether business innovation is necessary to meet market requirements.
Posted by Malcolm Ryder at 4:41 PM | Comments (0) | TrackBack
August 22, 2005
A Management Framework for Service Operations
Running IT like a business means that there will be ongoing operations managed on the whole to ensure that deliverables to the business meet business objectives.
Seeing this ability as a competency instead of as a case-by-case event puts management on a different footing. Producing a deliverable is NOT the same as meeting objectives, but management must organize production in a way that it CAN be the same, on demand.
The picture below associates many of the variables in this management effort, by positioning them relative to each other in a framework (central white 3x3 grid).
- The dimensions of this framework (black row and column headers) represent the way the operation applies its structure to the business fulfillment effort.
- The arrows identify the key issues in the structural throughput of operational delivery, from the essential starting points of capacity (architecture) and demand (specifications).
- Managed operational capabilities that are committed to the business are shown at the top three rows. Their influence is concurrent, and their overlaps from left to right show when they influence each other.
- Outputs (in green) result from the activity in the rows, and list the terms or expectations by which the business rates the operation.
For the full secret decoder-ring elaboration of this chart, see the sequence of illustrations that follows.
Here we'll build the framework issue by issue.
Posted by Malcolm Ryder at 6:00 PM | Comments (0) | TrackBack
August 18, 2005
A Management Support System for IT Service Value
Very recently I received an invitation from a colleague, Eugen Oetringer from EDS in the Netherlands, to study (and share commentary on) an IT Strategy Management Process design.
The most prominent feature of the design, in my first viewing, is the solution that it proposes to the practical problem of just-in-time research that is inherent in conducting service delivery while coping with change and diversity in IT operations. In fact, the design's emphasis on the responsibilities for "development" and "production" anchors its concepts in terminology that is inherently compatible with addressing Business clients in terms of specified quality and value. The noted challenge is that specifications are forwarded into operational environments that are often not built or managed to ensure successful communication. The consequence of that challenge is that alignment is forfeited or damaged between development and actual production, the second link (after specification to development) in the enterprise's value delivery chain.
Also at first reading, it seems equally valid to consider the design as a governance model instead of as a strategy management process. But for the sake of retaining appreciation of the scope of the design's importance, it may be more useful to emphasize that a process for managing the execution of strategy will have:
- a model that guides it,
- a performance objective that relies on compliance, and
- technologies that support the practical implementation of the model.
Eugen's design explicitly details those items in the context of accountability to business needs and policies, thus linking it conceptually with governance.
That said, the design's primary objective of describing how to bridge the gap between development and production winds up exploring how knowledge management supports change management in order to align IT with the business. One of the most important points to take away from the design is that "strategy" is a set of knowledge to be managed, and cultural adoption of the strategy is a result of empowering users to leverage the knowledge in order to adapt.
What does the support of this leverage look like? It is strategy lifecycle management. As the author puts it, "The IT Strategy Management Process takes the strategy from the owner, runs it through an approval workflow, publishes it to the target audience, drives for compliance, takes the feedback from the user communities, provides the feedback to the owner and drives the owner to release an updated version in a central repository."
The whitepaper reviewed above is here, and its parent book from the same author, published by Van Haren Publishing, is titled "The IT Strategy Management Process: Supporting IT Services through Effective Knowledge Management".
Posted by Malcolm Ryder at 7:59 PM | Comments (0) | TrackBack
August 15, 2005
The Conceptual Basis of Configuration Management Data
Technology functionality offers business tremendous capability, but for functionality to be meaningful it must be translated into utility.
For this reason, the most important view of IT asset items is of their configurations -- that is, of the organization of assets as resources. Business awareness of configurations powers managed utilization that proves to be effective instead of just continuous or diligent.
Said that way, the role of data about item configurations is evident. In particular, what is important is data about the business management of the configurations.
The high level business view on IT assets revolves around the main business benefits associated with what they offer to business capabilities -- namely:
- capacity, security and agility.
However, the day-to-day management of the IT item configurations is more directly involved with three key business constraints on those benefits:
- ownership, control and alignment.
These constraints are just one set of several major groups of things that change and that therefore call for management attention in order to calibrate and assure optimal utilization of IT's functionality.
Before we look at an illustration of these changes and how business awareness affects them, let's recap what configuration management data involves in this discussion.
- Configuration: a definition of how asset items are deployed as resources
- Management: specify, approve, implement, support, and modify the configurations
- Data: recorded observations about the management
With that understanding, the illustrations below proceed from the issue of managing against key constraints, down to the relevant level of data about managing configurations.
The illustrations show why information about the management efforts is tantamount to business intelligence about the configurations.
First, the overview, detailing the above comments on business awareness:
Following on that set of business issues is a set of management performance issues, shown below. Business information (matrix at top) about the proposed value of IT deployments must be related to information (cube at bottom) about how deployments are actually being managed. Although the issues are typical for all companies, the information (to be determined) will be unique to each company and will change over time.
A key feature of this overall perspective is that it distinguishes data describing the configurations from data describing their management. While both kinds of data are necessary, understanding utilization requires a description of the management phenomena that account for why IT is impacting the business as it actually does. With that understanding, managers can better decide what to do about configurations, when to do it, and why.
(For a discussion on the Resource Status Information view in configuration management, see the article Operations Intelligence - The Business Logic of the CMDB here in the Archestra collection.)
In summary: the IT impacts on the business are the result of management decisions. Management decisions create resources from IT assets in the form of configurations, and deploy those resources into the operational environment of business objectives. Our illustrations here point out the type of information about management that makes up a huge portion of the "business intelligence" needed for decision-support to direct the assignment, leveraging and optimization of the resources.
Bringing this back into the business management context, companies find configuration management significantly and even strategically influencing planning. In the illustration below, this influence is traced around a closed loop of business enablement typified by enterprise architecture's extension into configuration management.
The understanding and management of events calls for the company to be able to describe events in terms of the items and circumstances that they involve. Why?
The assumption is that everything happens -- whether intentional or not -- occurs because some part of the business is trying to make something happen. Events are effects, so the problem is to understand what events mean when they happen (impacts), and to exert some control over them (causes). To do this, the configuration of the infrastructure is constantly checked to determine how events (and their meaning) relate to (a.) the infrastructure's capacity vs. demand, and (b.) the infrastructure's integrity versus demand. The main objective is to develop manageability of the events. That requires sophisticated ways of describing events, especially in terms of what "items" are involved in the occurrence of an event -- in other words, the collection of item definitions that allows analysis of the infrastructure. So, for example, the analysis drives decisions about whether capacity and integrity need to be addressed through initiatives or problem resolutions (i.e. repairs) regarding development and/or security.
Posted by Malcolm Ryder at 8:56 PM | Comments (0) | TrackBack
August 11, 2005
Discovering and Defending Competitive Advantage with Technology
Bob Evans at InformationWeek posed a conference theme of "Business Process Innovation: Using Technology To Redefine and Reinvigorate Competitive Advantage." As Evans reflects, the current resurgence of business attention to managing business process improvement points to breakthrough champions such as Wal-Mart (and Dell), who present the prospect that IT-based superiority is the killer strategy of the day. By describing "what they do with IT" as business process, the call goes out to get business process innovation underway. Bob asks his readers for a reality check on this theme.
Taking him up on his offer, I wonder and ask might this theme be the right incentive pointing at the wrong problem?
Let's look at a company's business processes -- using the analogy that companies are like athletes. Speaking candidly, when we say "a company" we are talking about its leaders and managers. By analogy, leaders represent the athlete's knowledge of the possibilities of how to play the game, and managers are like the trained muscles of the athlete. Processes are simply ideas conceived and enacted in the heat of the moment of play, but rarely are they sustainably effective except when they originate in *both* the concept and the training of how to play. In other words, business processes are a company's "technique"... Yes, it can be memorized, rehearsed, reused and optimized, but technique is not automatically the same as advantage.
Actual competitive advantage originates in having the competency to exploit opportunities anticipated by the understanding of how the game can be played. Otherwise, advantage is just a theory.
Athletes who rely on competency win more often and longer than those who rely on something else. And competent athletes with a better understanding of the game realize that they have to keep refreshing and expanding their competency, to exploit the opportunity that can be envisioned in, and that can develop during, the game. By implication, at least, one's competitive advantage exists because your competitors have an inferior understanding of the game, an inferior preparation for the game's opportunities, or a mix of the two defects.
Unless your technique forces your opponent into those deficiencies, it is rather not likely that you have advantage simply because you have better technique. So, changing technique is not particularly useful unless there is already an expansion or shift in one's understanding of the game. (This understanding is what Brad Gilbert gives Nick Bolleteri's tennis geniuses to make them better than they already were.)
If all things other than technique were already equal between competitors, my claim about technique's limitation might be false. But since all other things are usually NOT equal, most companies do not have to rely on innovation of technique to establish or renew competitive advantage. Instead, technique for most companies is about survival, not advantage, and to get an advantage they need a privileged opportunity. The question for them is how to get that opportunity.
More likely, technique creates that opportunity when the opponent makes a mistake. But whenever it's too difficult to make the business opponent make a mistake, we need something else to "create" the opportunity -- such as vision or fitness. In this light, we want technology to increase our understanding of how the game can be played and/or increase our effectiveness in exploiting opportunities born of that understanding. But that is not business process innovation -- that's architecture.
So, to directly explain-- not by analogy -- this view of competitive advantage through technology , let's look at the details, beginning with the idea of "competitive".
By definition, the occasion of "competition" exists because there is a limitation on the availability of an opportunity. This still allows two different perspectives on the competition: one, who gets the greatest availability; and two, who gets the most out of the effort. This duality is why "agility" and "performance" are so strongly linked in the innovation of management itself, where formerly "strength" and performance were the focus. But let's assume that we're always talking about the condition of being competitive, not the results of the competition. Here, we'd want technology to support our new focus on agility.
Next let's work with the idea of "advantage". This idea has to mean "having the higher probability of gaining a decisive slice of the opportunity's availability." There are various ways that this might occur. And let's say that "a higher probability" is a relative position: then there are various interesting positions. Using technology to approach them makes sense mainly to the extent that those ways have already been identified. But the additional question is, how might technology help us to discover positions that give us an advantage?
Next there is the understanding of the "opportunity" itself and what it depends on. For example:
- If the opportunity originates in being "the timeliest provider of the most urgent value",
- and if the hold on that opportunity is sustained by being the most capable renovator of the value provision,
- and if technology is the dominant critical success factor in both cases,
then a company's key assumption about the technology is that it "actualizes" the business opportunity by enabling dynamic functional alignment with the opportunity.
In sum, this shows technology contributing to "realizing" the availability of business opportunity (i.e., getting competitive advantage) in four ways or levels, which logically progress (from bottom to top) as:
- persistence
- alignment
- enablement
- discovery
These levels, which are objectives of technology utilization, respectively reflect (bottom up) a company's options, capabilities, relevance and presence in the game.
Any given company may be weaker or stronger at particular levels in this setup, but without significant episodes wherein current-state accomplishment is satisfactory at all levels simultaneously, there is little reason to expect that competitive advantage will materialize long enough to take advantage of it. The secret to the success of the Wal-Marts and the Dells is not the use of technology per se but the awareness of the competency needed to make the difference.
Posted by Malcolm Ryder at 9:18 AM | Comments (0) | TrackBack
August 5, 2005
Value Capture through Execution
What is the real point of an IT business case?
Most proposed changes to the IT infrastructure of a business are intended to make "execution" better. Better execution goes by many names: productivity, efficiency, resilience, intelligence, and more. Since a proposed change typically competes for attention and support against other proposals, the idea of "better" cannot be separated from the sense of what is "necessary"... This means that agreement on priorities must occur, and the black arts of winning agreement commence.
Certainly, the job of presenting a business case is to win the agreement, just as a prosecutor or defense lawyer is out to win. Yet in competition, these adversaries are unified in taking the same piece of strategic advice: "Don't confuse your issue with facts!" In other words, they openly give each other permission to exercise poetic license. But if your business decides to accept this modus operandi from its managers, then it should also just dispense with the requirement to argue in terms of ROI, as well.
In fact, the ROI bit is often misguided, anyway. If building engineers were held only to the standards that ROI calculators so often are, we've have to conduct the business mainly in large disposable tents. Why build a business case that won't stand up?
Instead of ROI, the business case should be argued on value. Strictly speaking, value is what you call the importance of a difference. If that importance is measurable in dollars then so much the better; but since the dollars come from the value, you first have to make the value . And just how is that done? A business case must be able to identify and convey the value generation. To do that, it has to start with a logical understanding of the phenomenon.
Let's start that with a solid working definition. Execution is: the pursuit of a goal, as based on certain enablers (means), in the context of desired types of achievement.
Organizing activity in terms of execution is the typical result of planning. Plans therefore might be prescriptions, formulas, methods, programs, or other designs for interaction and interdependency of activities.
According to the achievement level realized in execution, we say that a certain "performance" has occurred.
According to the importance of that performance in its context, we say that "value" has been generated.
The most straightforward example of a practical context is an objective. That brings us to the key point: that value accumulates towards an objective, and different types of value may collectively apply to a given objective. (For example, imagine watching various contributions of cash, supplies and services push up the red dye in the big "thermometer" poster used to advertise progress in a fundraising campaign...)
The objective represents a concern such as a perceived business need -- essentially, a strategically critical success factor of the way the business believes it must be or act in order to generate "business success". The most straightforward description of the business success is (when properly defined) the mission statement. Usually, a mission depends on several different things coordinating and cooperating effectively, which indicates that there is a variety of ways to add value. At any time, based on the collective effect of those things, the status of the pursuit may thus be deemed more-or-less "successful".
From that perspective, the proposal's idea about changing the way that the business is enabled to execute must always be, logically, about:
- improving the value of its performance, which means...
- improving the achievement of its underlying execution, which means...
- improving the effects of its enablement.
Therefore, any enablement option is meaningful because of its presumed and targeted effects; this describes the basic level of discussion of a business case for an enablement proposal.
Will the witness please answer the question!
Typically, enablement is seen as a deployment of resources, with the now classic categorization of resources being people/process/technology. Of course, there are other resources -- such as time, money and permission -- that are equally critical. But here, the main point is that investment in enablement will be directly attached to ways that resources are affected (moved, added, changed, combined, deleted), and those ways will be described in a plan. The resource view of the investment, however, is merely the left side of the proposal...
The right side must attach the investment directly to the execution that will drive "performance." How? Since value is derived from execution-in-context, and since the context is about what kind of difference is made, then what must be understood is the difference claimed to be addressed by the type of enablement proposed for funding.
As described by example of the following chart, this is a general perspective on planning and justification. The chart gives answers to the question "what is it about the business that the proposed enablement will affect, and how?" The answers to "what" are (across the top) aspects of the business for which improvement is a desired benefit. The answers to "how" are (down the left side) itemized issues that represent success factors addressed in the planning for performance.
In viewing this chart, it is important to remember that the overall business goal is not "value" but instead that the goal is a "mission success" -- a success that is predicated on the value added, by execution, towards business benefits. These benefits (across the top), which are high-priority for the business, are thus understood to be "objectives"... Finally, in our scenario, where the proposal is going to bring a "new" configuration of technology to the existing situation, the IT organization gains more power to enable the business -- which makes the IT organization more successful; therefore, the types of enablement that the proposal identifies are logically seen as "objectives" (down the left side) of the IT organization. This lets us understand why funding the proposal is an investment in both the business objectives and the IT objectives.
What's clear from the above is the investment idea of value for money. Each of the issues in the chart (such as exposure, efficiency or capacity) is an opportunity to generate value, using the support of funding. What's important about the detailed logic of the discussion is that "value" is not left casually misrepresented by so-called ROI. Instead, value is something showing explicitly why the proposal makes sense; and in turn, that provides more logical support for economic impacts that are associated with the proposal. Without establishing the logic of the value-generation, calculations of economic impact are speculative.
Punchline: ROI does not validate the business case; instead, the business case validates the ROI.
Posted by Malcolm Ryder at 3:08 PM | Comments (0)
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
July 19, 2005
Fast, Pretty, and Cheap
Bob Evans over at Information Week wrote up the importance of HP's new CIO Randy Mott to its strategic needs. Mott is the mastermind behind Wal-Mart and Dell superiority in IT enablement of business performance.
Is strategic success portable? Evans points out that, "During the five years Mott was CIO at Dell, the company's revenue grew more than 60%... among Mott's biggest contributions were helping the IT team set strategic priorities and putting in place global standards... At Wal-Mart, Mott specialized in cutting latency out of the supply chain and ultimately increasing customer intimacy by helping to ensure that the seller was offering what the buyer wanted, when the buyer wanted it, and at a price the buyer accepted. As a result, in the six years that Mott was Wal-Mart's CIO, the company's sales almost tripled..."
Clearly Mott is a guy who knows how to get things done. But let's recap that: Mott focused his (IT) operations on three things:
- speeding up the runtime throughput of operational processes
- aligning IT's support of the business to its clarity about buyer's requirements
- making that sustainable and affordable in a way that allowed continuous progress over several years.
In a nutshell, he made operations fast, pretty and cheap.
The official joke about fast-pretty-cheap is that you can pick any two of them but you can't have all three. But evidently, getting all three really is possible, and when it happens you become Number One in your niche.
So, what's interesting to think about is how those three impacts rely on each other. In general, we're looking at how the operation establishes a fit with (a.) its environment, (b.) with the prospective customer/beneficiary, and (c.) with the market. When productivity feeds quality and quality feeds acceptance, you get a winner.
Faster operational throughput presumes that the chain of inputs and outputs that link functions and processes together is "streamlined". That is, the functions and processes all know what is the right direction to go in, and they offer little resistance to the environment they are moving through. "Efficiency" is an easy way to refer to minimizing resistance while strengthening direction, but policies and standards actually go directly to the problem in a more profound way. By reducing the number of operational variations that will be attempted in the first place, policies and standards reduce the volume of necessary downstream corrections and distractions, while making it easier to recognize when recurring activities are actually generating benefits or risks.
Clarity about the impacts of activity underlies operational quality, and quality is pretty. Impact clarity means that the downstream benefits and risks of most importance can be targeted more accurately and confidently. As a result, quality promises can be made more rationally and certainly, which increases the customer's interest and attraction.
Customer requirements come from the perspective of the customer's needs, and the greater the need is, the more valuable it is to satisfy the need. But meanwhile, the usual laws of supply and demand apply. The availability (supply) of that satisfaction is a strong lever in prices. But the customer's need (demand) can also range in two ways: from critical to merely discretionary, and from few people to many. So, the smart business wants to focus on the most valuable "sets" of requirements. By tailoring the fulfillment operation to quality for a particular importance and volume of need, economy of operational scale is easier to determine, and improvement there allows more attractive pricing and coverage for customers. Then, of course, what finally makes quality inexpensive to produce is better sales that readily pay off the investment in quality.
So the fast-pretty-cheap trick is not about which one of them to leave out. Instead, it is about how to order and align them. This also reflects CIO Mott's approach when he first arrived at Dell. His first steps were to reduce the number of planned projects by 90%, leaving only those most important to business capability for making products more marketable and sellable. Recognizing that cost is always a critical issue, his initial emphasis was actually on prioritization and focus, not on cost. As Bob Evans quoted him saying, "once we got our priorities set, we were able to be a lot more effective." And we know that both Dell and Wal-Mart are price leaders as a result of their effectiveness. It looks like the best way to reach "cheap" is to stop wasting effort, and do the right work.
Posted by Malcolm Ryder at 7:55 AM | Comments (0) | TrackBack
June 25, 2005
The Net of the 'Net
Guilty of hunting most of my news-before-lunch online, I pushed through and out of a thicket of links into a cool breeze of clarity in IT consultant George Spafford's article on the net present value of a network (available through the JupiterWeb / Earthweb.com syndicate).
Spafford puts a stake in the ground: "we can safely assume that for any network, only 20% of the nodes will create 80% of the value." But on his way there, he points out (even more importantly in my view) that any node on a network can be counterproductive as well as productive, and if productive it can be in many ways.
That means the value produced through the network has to be developed, through decisions that determine when, where and why nodes behave the way they do. The variability of these decisions is the network's potential range of productivity.
Fully appreciating what this means, it's important to not think of the network in terms of something bounded by its physical components. Instead, the network is an environment to be managed, and the value drawn from the network is the "return on management".
That said, what is the virtue of a network, as opposed to other forms of environmental organization? For example, if a network is not the same as a "system", what is the particular distinction behind its design?
The important difference is what essential types of functionality the design pursues.
Systems are designed to be self-contained, drawing effectiveness from the fact that they are securely bounded, which allows for predictability of functional efficiency based on controlled processing of fixed resources.
Networks are designed to find resources, drawing effectiveness from the fact that they are not physically bounded yet provide control of how resources are found.
Seing systems as being resources allows us to envision making a network that finds and connects systems, and naturally explains a division of labor between network management and systems management.
As we continue to explore different types of networks including technology, society and processes, it remains always basic that the productivity and value we imagine is invariably due to the integration achieved within the network, through management.
Different environments have differing ecologies, from which productivity and value are derived. For example, we know that a tropical island environment offers different opportunities and methods to generate value than does an inland desert.
These ecologies are not just circumstantial constraints but instead are the cultural level on which management must also be conducted if any pretense of sustainable value-generation is to make sense.
And so it is that in any network, a culture becomes the "boundary" or domain of the value that may be obtained. Meanwhile, a network can host multiple cultures. Any determination of the network's value must acknowledge that the evaluation presumes certain preferences about which cultures should be hosted and how they should co-exist...
Posted by Malcolm Ryder at 9:55 AM | Comments (0) | TrackBack
June 17, 2005
CIOs: Managing the business's IT Agency
In the new industrial revolution, IT is at the center of the business evolution, and CIOs are at the center of the IT revolution in business.
Business now knows that reliance on IT means that IT is a business element, not just a tool. In the old dysfunctional relationships, LOBs get burned by providers, CFOs get angry about the wasted money, and CIOs take the heat. As strongly reflected in the Deloitte survey on outsourcing (covered by Christopher Koch at CIO magazine), companies have definitely found that the dysfunction isn't departmentalized internally or externally but instead ecologically systemic. Thus, merely leveraging lines of authority (for example, against the IT organization) doesn't make it go away; instead, capability maturity must set in with executive management of the relationships.
The biggest barrier to climbing the maturity ladder is the perspective that the IT organization is simply a repository of skills and assets -- a store -- instead of a management center for business operations. This perspective essentially displaces operations strategy with procurement, and then laments the poor state of the architecture on which enterprise economy of scale is supposedly built.
To have a shot at operations strategy, the business needs CIOs to manage the relationships between CFOs, LOBs and service providers. Experience has taught the enterprise that CFOs and LOBs alike must be able to count on the CIO function to provide knowledge, assurance and leverage of the providers of IT and IT services.
In effect, the CIO function should be an executive-level broker of IT and services for the enterprise, and with the overview of enterprise needs the CIO also manages the opportunities of importance to the service providers.
In governing provision against requirements, CIOs "own" the work of IT services providers, to generate ROI for the CFO and the enterprise, while likewise generating and protecting value for the LOBs from the services. Whether the providers are internal or external, CIOs must manage supply and demand equally well.
In managing the performance of the IT work, CIOs must focus the work to satisfy the business customer. This means the work must be executed in business-terms, to assure continued quality of service against the objectives of the business.
Run like a business, the new "IT Organization" features a blend of internal and external resources. At minimum, the CIO needs to:
- know where the strengths lie with all the involved providers,
- be able to call on them reliably, and
- know when to rebuild, reposition, or replace them, to keep up with the business.
But lessons must be learned from those who have the most experience. The performance of this new organization is modeled most clearly by the situation of external providers. Since they ARE businesses, their performance has always determined whether they got new business and stayed in business. They set the bar. Internal providers must work well based on the same type of competencies that make external providers successful performers.
Core competencies of external providers include managing skills and customer relationships to ensure that work such as projects and infrastructure changes align with the business and with required service levels, both current and future. As complex as that often is, the even bigger challenge is to understand how to collaborate on business requirements at the operations level instead of just at the infrastructure level. In collaboration, roles are the key, and provider competencies only count in terms of the role. Here, the critical differences are between being a contractor, a facility and a partner. All three are responses to the question of "how the business' work gets done" ... but providing the client's operations with (respectively) a business resource, a business environment, or a business competency are drastically different responsibilities for a role to address. Mismatches of client expectations and provider roles are lethal. To proactively align them or reactively reconcile them, the CIO should model the collaboration of providers as an operations strategy, and market the strategy both internally and externally.
Posted by Malcolm Ryder at 7:56 AM | Comments (0) | TrackBack
June 16, 2005
Linking Business Performance and IT Performance
Usually this subject starts off with the word "alignment" in the banner, which amounts to a freebie in getting folks' attention. Why resist here?
The idea of "linking" instead of aligning comes from the sense of correlating Business results and IT results, just as we would say "evidence shows that the consumption of lots of butter is linked to weight gains" or that "drug abuse is linked to higher crime rates".
Correlation generates something we can call the tension of implied causality. The challenge is to see through the implication and find out where the correlation is coming from.
If we take the word "performance" to mean "the degree to which functional outcomes have achieved targeted levels", right away it becomes important to see what distinguishes the IT targets from the business targets.
The business-side follow-up to that step is to ask, "in what way are the targets of the IT functions relevant to the business?"
Examining relevancy turns out to be the breakthrough. For any business, there is a general way to describe its functional ambitions.
- Every business needs opportunity, and operations with which to pursue them.
- In the face of market forces, the business must be concerned with supporting both the operations and opportunity, and also with transforming them as necessary.
The key business question is, given those two facts, what does IT do that matters?
As shown here, IT contributes to establishing and protecting the ability of the business to leverage the environment that it is in. With IT's contributions, the business can develop itself against requirements at an acceptable level of risk. The business has four really big stories to tell.
Each of the four stories -- Agility, Effectiveness, Deployment and Availability -- represents a major capability of the business functionality that responds to a critical requirement. IT's role is to "provide for" (not simply to supply or deliver) the capability. For the tactical capability to support business operation, the business looks at IT's contributions to Availability, such as through service management. A strategic capability, such as for transforming opportunity by exercising a competitive competency, tells the business to look at IT's contributions to Effectiveness, such as through BPM. IT would likely bring Change Management contributions to Deployment, allowing risk-controlled reconfigurations of workgroups and systems to enable transformation of operations. And so forth.
The punchline of this picture is that, seen through targeted contributions to business capability, IT performance is "linked" to business performance in a way that is best discussed as IT's business value.
IT's strategy for making those contributions is not the same thing as the business strategy, but the business strategy will impose priorities and weights on the four general capabilities, and IT will then strategically respond to that. By understanding how those business weights and priorities originate, IT managers can be more proactive in foreseeing and recommending IT contributions that are strategically sustainable and valuable.
Posted by Malcolm Ryder at 4:00 PM | Comments (0) | TrackBack
June 15, 2005
Business-IT Convergence? What happened to Alignment?
CIO Magazine, covering thinking from their CIO's Perspectives on Enterprise Value conference, reports that we've gotten ourselves into another semantic knot. But not a tough one. The debate pits "convergence" versus "alignment". Is Convergence the new and improved Alignment? Is it time to change horses again?
Perhaps what's going on here, in this overall discussion, is just reverse-engineering the underlying systems of a good plan...
Alignment (noun) is a process having the objective of real-time structural compatibility. But convergence (noun) is an event, literally a co-incident, with the characteristic of having critical influence on the state or direction towards some outcome (which is why we care to notice it).
Fundamentally, alignment emphasizes compatibility -- essentially, "usefulness". Convergence emphasizes concurrence -- essentially, "agreement".
But the two-ton idea casting a shadow over both alignment and convergence is "Integration". What hasn't changed with the terms-du-jour is a goal of integrating whatever is called "business strategy" with whatever is called "IT strategy". What has changed is that we now can usually distinguish the need to have operational motives align from the need to have operational outputs converge.
As we move into performance management, we kick things up a level where we then start working on the problem of "making outputs align" and "making objectives converge"; but we already call that "planning."
Posted by Malcolm Ryder at 6:50 AM | Comments (0) | TrackBack
June 11, 2005
The Business Management of IT
Should enterprise IT organizations (ITOs) be modeled to run like an autonomous business partnered or contracted to its enterprise client, or to run like a captive business within the enterprise business?
It may seem that the jury is permanently out on this, as various theories abound on the relationship between the enterprise's business model, business strategy, ITO models and IT Strategy. Over time, certain relationships may prove to predominate for businesses of given industry, scale and maturity.
Meanwhile presuming that the business pays for IT, which means that the business is the "customer", what should surface as a set of "constants" is the breakout of how IT management is optimized to business concerns, and how that optimization actually makes a difference to the business.
Every business must organize IT in a way that is visibly logical when handling three critical challenges to business-oriented control and capacity:
- Availability versus Costs
- Demand versus Operations
- Risks versus Requirements
The following Archestra framework illustrates the relationship of issues pertaining to that optimization and differentiation.
Posted by Malcolm Ryder at 5:08 PM | Comments (0) | TrackBack
The Business Optimization of IT
Should enterprise IT organizations (ITOs) be modeled to run like an autonomous business partnered or contracted to its enterprise client, or to run like a captive business within the enterprise business?
It may seem that the jury is permanently out on this, as various theories abound on the relationship between the enterprise's business model, business strategy, ITO models and IT Strategy. Over time, certain relationships may prove to predominate for businesses of given industry, scale and maturity.
Meanwhile presuming that the business pays for IT, which means that the business is the "customer", what should surface as a set of "constants" is the breakout of how IT management is optimized to business concerns, and how that optimization actually makes a difference to the business.
Every business must organize IT in a way that is visibly logical when handling three critical challenges to business-oriented control and capacity:
- Availability versus Costs
- Demand versus Operations
- Risks versus Requirements
The following Archestra framework illustrates the relationship of issues pertaining to that optimization and differentiation.
Posted by Malcolm Ryder at 5:08 PM | Comments (0) | TrackBack
June 1, 2005
A Business Relationship Management Framework for IT Service Provision
The organizational structure of a business creates "organs" which have functions vital to the business. The IT organization created by the business will make the most sense as a component of the overall business system. Since business organizations at any time are different amongst businesses, and are different for any given business from one time to the next, the subject at hand is not so much what the ideal IT organization looks like but instead how to be an optimal IT organization for the particular business.
I. The organizational mission
Cows and people both have hearts, but one heart won't substitute for the other.
All businesses are enabled by IT. Seen as a functional business organ, the IT organization has both a primary responsibility and a primary objective.
The IT organization's objective is to manage enablement of ongoing business fulfillment of customers' (and other stakeholders') demand.
This enablement is executed within business preferences and tolerances -- targets set for both the types and levels of the enablement effort's performance, value, quality and risk.
Meanwhile, enabling business fulfillment is not solely accomplished through IT. For assuring the desired enablement, the IT organization's special responsibility is to succeed in managing information technology (IT) in three dimensions:
1. Requirements (representing business needs)
2. Changes (representing the business environment)
3. Assets (representing business investments)
Of the three dimensions, Change is the most directly challenging to manage.
All three dimensions feature difficulties stemming from complications (such as incompatibilities amongst many separate factors) that accumulate over time. But relative to the other two dimensions, changes involve much more direct struggle with complexity (such as interdependencies and their uncertainty).
To optimize the business cost/benefit of change against complexity and uncertainty, the basic job of managing IT systems must be executed within policy constraints that are nothing less than how the business explicitly prioritizes and accounts for its dependency on IT.
Meanwhile, because business-change is the rule rather than the exception in the life of the business, IT Management is naturally responsible for maximizing it's ability to manage changes to the "business-enabling" IT.
In that scenario, IT Change management is the central and most critical issue in the IT organization's mission. To tackle this, there needs to be a good picture of what the business impact scope of IT Change includes, along with a corresponding picture of the scope of both business management and IT management practices to be applied.
II. The architecture of enablement
IT's execution on enabling business's fulfillment is conducted on three levels of competency above and beyond hardware and software systems:
1. Processes - which are measurably composed, objective-driven activities.
2. An operation - which is a resource-managed integration of processes.
3. A "service" - which is an operation that is policy-based and customer-driven.
This scope of activities must be woven together in both IT and business practices. With change being the crucial issue in the reliabiity of the business dependency on IT, current business priorities always set the legitimate terms for alignment of IT's practices with the business's.
In this alignment, the overall arc of business expectations is as follows. Typically, business activities subscribe and leverage assets, consuming them on at least a temporary basis. Business assets include things, money, information, time, skills,and processes. From the business perspective, services convert these assets into on-demand resources and so are an essential link allowing the business to use its assets to meet its requirements. Therefore, managing services is an essential business competency, and managing changes in business finds the management of services to be a critical success factor.
"Performance" in IT's enablement of business fulfillment therefore refers mainly to a level of success achieved in providing appropriate services, on demand but also across continual change. From this perspective, the provision must be affordable and reliable. Business value comes from that performance tightly tracking with business priorities. And business perceives quality in the IT effort mainly through the consistency with which the effort delivers value through the current level and structure of management. Finally, the business sees risk in the effort according to the evident likelihood that the quality can be effectively leveraged for the requirements of the business-level priorities.
All of these business perspectives identify the IT organization's handling of assets, changes and requirements on business terms -- regardless of how the information technology is designed and deployed. As the famous saying goes, although a drill makes a hole, customers aren't paying for drills, they're paying for holes. In the form of IT services, the IT organization makes the drills, but the reason for doing that is to deliver business services -- the holes.
III. Re-aligning ITIL
The defacto standard for IT Service management is ITIL, which identifies a comprehensive approach for defining and managing services as products such that IT organizations can maximize the cost/quality ratio of the services for the business.
But taking another step in this consideration, the IT organization must acknowledge that no product actually delivers value except through the way that it is used. To more directly address that, the following framework describes and relates management processes of the IT organization as they are dedicated to the business utilization of IT services.
While incorporating the management process distinctions now standardized in the ITIL vocabulary, this Archestra framework positions the processes such that their different roles are quickly targeted from a perspective more sensitive to business drivers that generate demands on IT -- such as needs, investments, and the business operating environment. Each of those drivers significantly influences the business's perception of its relationship with the IT organization as opposed to just with the services.
(For an enlarged view of the graphic, click here then right-click and print landscape.)
The framework offers a very symmetrical assignment of management concerns. The symmetry more explicity recognizes the major business issues of the IT environment (not just of the current IT infrastructure); and it readily refers to the enterprise operation as extended to third parties beyond the corporate campus.
A key benefit of this reframing is to stage better predictive power and "normalized" tactical comparisons between legacy vs. evolving (or otherwise heterogeneous) enterprise architectures. The framework makes the point that change management is the nexus for all key business issues addressed by IT architecture and must strategically integrate them. Furthermore, the framework decodes the exciting buzzwords agility, integrity, reliability, and of course alignment by explaining where and why they should enter the conversation. For example, agility is spotted as a demand-driven crossing zone or balance point between support and delivery, reflecting IT service value.
The other significant specific difference between this framework and the ITIL publications framework is that "Continuity" is associated here with Support instead of with Delivery. The reasoning for this is that aside from the contingency planning (i.e., the design) aspect, Continuity is primarily and essentially an issue of problem management and recovery. Meanwhile, the more important aspect of its classification is that it falls on the side of enterprise risk management.
For a discussion on how the framework generates and tracks ITSM process integration, email me.
Posted by Malcolm Ryder at 2:10 PM | Comments (0) | TrackBack
May 31, 2005
The Business Logic of IT Services
Business reliance on enablement through IT has evolved into a necessity for IT strategy to become a design element of business strategy.
Seen as a critical success factor, IT enablement describes the basic underlying assumption of the business's execution of strategy. That is, overwhelmingly due to IT, operational fundamentals such as communication, analysis, and processing are meaningful and viable in the face of change, costs, speed and regulation.
However, the relationship of IT to business is not one of simple cause-and effect.
Intuitively, we link motivation to importance (i.e, what is valuable) and we link automation to opportunity, which goes a long way towards clarifying the main difference between business strategy and IT strategy. But they must be reconciled.
Reconciling the strategies means to develop assurance that alignment is established between the type of opportunity generated and the type of value pursued. In alignment, "opportunity" represents satisfaction of certain pre-requisites for subsequent gain, and "value" controls the prioritization of possible effects leveraged from the opportunity. In alignment, prerequisites-for-priorities, rather than cause-and-effect, is the key relationship.
Practical institution of alignment is an ongoing management function. Business organizations and technology systems are both developed with the idea of their being functionally reliable, but their respective functions reflect significantly different design dynamics that easily diverge or lack synchronicity. Functionality in technology systems is increasingly focused through automation, while the functionality of a business organization is increasingly focused through motivation.
The successful business operation is one in which the negotiation between organizational motivation and systems automation is successful.
Typically, where motivation is the business basis of effectiveness, and automation is the business basis of availability, their combination generates the execution capacity of the business. To manage that execution capacity, the alignment negotiation must internally balance motivation against change, costs, speed and regulation -- and do the same for automation -- and then balance the two against each other.
Customers experience that execution capacity as the "availability" of the entire business, through the business response to specific customer demands. In effect, to the customer competitively evaluating things, the business behavior represents what the business "wants to do". The question is whether that perception is favorable or not.
For managers who want sustained execution at a level that creates advantage from the customer's evaluation, it means creating descriptions of business availability that literally make sense in terms of organizational motivation. For example, does the business want to do follow-the-sun customer support? If so, why?
Regarding IT, the description should highlight IT's enabler role in the business. In the business view, "value" describes the importance of something. The objective of IT meanwhile is to create or enlarge opportunity for the organization to pursue selected value.
Approaching the bottom line
IT can be pretty successful in its role, however, the business must still actually use the opportunity to get anything out of it. In fact, when assessing the "value" and "return on investment" of IT's role, the difference between them is that while business value describes the importance of IT's role, ROI actually describes the business opportunity IT creates, more than it does the business result. The business ROI of IT's role can correlate with business value but it does not cause it.
In aligning opportunity and value, the primary agents are processes and policies which act as mediators. Most simply, processes coordinate goal-oriented activities, and policies likewise coordinate decisions.
Pragmatically linking IT strategy and Business strategy
As a mediating agent, the design of a process or policy ideally navigates or corrects the various functional strengths, weaknesses, opportunities and threats (SWOT) characterizing the technology systems and likewise the business organization.
Processes and policies often want to perfect their respective SWOT solutions separately, and/or to target either the systems or the organization but not both. The danger in this is that disparities between events and accountability will usually develop, sometimes with extremely counterproductive impact.
Therefore, for aligning the business-IT relationship, the most critical aspect is the correspondence created between processes and policies. To generate and sustain maximum business capacity, they must ensure that they way they shape operations is complementary to each other, collaboratively managing responsiveness within accepted tolerances. (Typically, this is where businesses are advised to specifically model the interactions of people, process and technology -- and where now a pronounced emphasis on performance management and governance has emerged.)
Whether the issue is the systems or the organization, Directors and Managers in the business live with the additional responsibility of continuously tuning the SWOT solutions to minimize constraints which especially provoke future risk, opportunity cost, and malfeasance.
This strategically important adjustment occurs as the outcome of dialog that discusses the business model. Because the form and/or the "metabolism" of the business model adjusts over time to its market environment, the dialog is ongoing or recurring, and changes to the constraints are iterative.
Thereafter, the collection of constraints allowed in the systems and in the organization represents the business' operational tolerances, which typically are documented or institutionalized in the form of practices (adopted) and agreements (contracted).
"Services" operationalize these practices and agreements by defining the way that planned availability (or "IT supply") is finally allocated and requested against planned effectiveness (or "business demand"). The definition provides a common "interface" for business and IT to manage execution capacity through a lifecycle of needs, orders, fulfillment, replenishment and improvement.
Posted by Malcolm Ryder at 8:09 PM | Comments (0) | TrackBack
May 20, 2005
Who is IT's customer?
It's the spring of 2005, and this week's reading was similar to most prior weeks in that analysts and consultants pointed IT towards achieving more strategic delivery of value by focusing on the "customer". But as usual, there is a buffet of choices about who the IT customer actually is: direct, indirect, internal, external, and more, and mixes of them to boot. Does this make the original question to unwieldy to be helpful?
As a preface to answering, it's worth noting that there are different reasons for IT in a business because there are different kinds of businesses. It's reasonable to assume that the focus of IT should "default" to the needs of the business model.
This assumption makes the discussion begin with how those needs are articulated into supporting operations that IT enables, producing the satisfaction of the needs.
How does the business define and measure that satisfaction?
One perspective looks at results that represent the concrete outputs mandated for delivery to stakeholders. The stakeholders include customers, employees, shareholders, and basically any other "business partners" who measurably and intentionally contribute to the protection, health and growth of the designated business.
Another perspective looks at the functional mechanism for the production of those outputs. This mechanism includes the resources, systems and fulfillment processes that day-to-day generate the business deliverables within established costs, priorities and locations.
We're used to seeing assessment techniques that hold IT "accountable" -- sometimes for the results, but sometimes for production. Those assessments have a lot in common, though, because the implications of doing any of them is always the same. They investigate whether IT's impact is:
- desirable;
- optional; and/or
- exclusively or uniquely due to IT.
With those facts in hand, the next stage of consideration is:
- should any of those impact characteristics change?
- who cares if they do or don't?
- why do they care?
- how much do we care about who cares?
Imagine not asking those last four questions: omitting them leaves no way at all to determine a connection of IT to business strategy. This argues that there is a level on which what IT does is promoting things either towards or away from strategy, but that there is a different level on which the business actually responds to the opportunity given it by IT and closes the deal in the form of measurable value delivered and gained.
That level is... business management. And this means that business managers are the direct customer of IT. To make this point more strongly, let's look at what it means to be a "customer".
As a customer, you have what we'll call a need. Your need is based on the desire to have and use a capability of some kind for yourself. To satisfy that need, you search for and acquire an enabler of that capability. The enabler is what we call a "product". The way that the enabler works for you is what distinguishes it as one kind of product versus another kind. Typically, what IT provides is an impact that can be delivered as a product. The impact may be delivered in the form of a tool or a service (and therefore note that a "service" is a product). Once the recipient starts doing something with the impact/product, the capability exercized by that user becomes the sign of the "customer's" presence.
If we look at a business, and we think of how IT gets used, we usually come up with multiple types and populations of users. But if we imagine removing IT impacts (the enabling "product") from any of those user-groups, the effects on the business will be most crippling when IT impacts are removed from managers. Why? Because the success of the business is fundamentally predicated on targeted functional organization, not on labor output -- and at a fairly low threshold of combined speed and size, competitively sustaining the organization is virtually impossible without IT-enabled management.
So, if we assume that the business must have IT, then it is easy to see who is the primary "customer" of that IT.
Posted by Malcolm Ryder at 12:21 PM | Comments (0)
April 27, 2005
Productivity and Performance Management
Over at CIO.com, Christopher Koch, CIO's Executive Editor, blogged in his Koch's IT Strategy channel (Apr 14, 2005 "Productivity and Plain Vanilla") that productivity and competitiveness are showing loose correlations with IT spending. This issue of whether IT matters evidently continues to be a debate, yet I wonder if the problem is that the not-new, almost 10-years old answer (see Paul Strassmann on management) is simply unpopular and is still getting ignored. Occasionally, this answer gets to poke its head into the room, opening the door all by itself.
As Koch reports: "Economists and IT pundits are divided as to whether IT has any real productivity impact at all... Eric Brynjolfsson is outspoken in his belief that there is an improvement in productivity and competitiveness among companies that spend heavily on IT... But Brynjolfsson, who is management professor and director of the Center for eBusiness at the Massachusetts Institute of Technology's Sloan School of Management, emphasizes process change, rather than software. In a recent interview with Gartner, he identified seven characteristics of the 'digital organization' from his study."
Interestingly, nearly the entire set of characteristics discussed in reference to Brynjolfsson's study have to do with *performance management* and not with productivity. Here's what I mean: productivity is about the level of output that is achieved through the consumption (i.e. processing) of resources. That's why process design is always at the heart of the productivity issue: does the process effectively connect the kinds of resources used with the kind of output produced? Why or why not?
That working definition makes it more apparent why a "debate" on IT's value to business productivity is somewhat strange. A business uses the output of its processes as its resources, in order to achieve other outputs on a different level of impact. IT's role (point A) typically is to improve and sustain the ability of processes to generate the desired process outputs (point B); thereafter, the business must make use of the process outputs (point B) to generate business outputs (point C). So we're simply looking at "productivity" on two different levels.
Regardless of the company studied, we will not find point A driving point C. We will find point B being managed differently from company to company, just as we find point A being managed variously. Dealing with point B is where Performance Management comes in, to begin to translate the second (upper) level of productivity into competitiveness. Performance management will bring a model of why productivity makes a difference in establishing a company's necessary relative advantages in competing for position, revenue, mindshare, and other elements of success.
This doesn't mean that performance management isn't active at the "point A" level. But at that level, the most important observation is that level A productivity's potential roles in business productivity be clearly distinguished and understood: -- a pre-requisite is not the same thing as a cause.
Managing pre-requisites is different from managing causes, in that causes are tightly bound to forecasted effects, while prerequisites are bound only to opportunities. That is, causes generate effects, but prerequisites only allow them.
Draw your own conclusions, but visit Gartner for the interview, and many thanks to Mr. Koch at CIO.com.
Posted by Malcolm Ryder at 11:25 AM | Comments (0) | TrackBack
ITIL - avoiding ITIL implementation mythologies
A consensus exists that ITIL - the defacto standard reference for IT service management - is a library of descriptions of "best practices". But it is crucial to note that in those descriptions, there is content pertaining to several different issues, three of them for example being objectives, practices, and processes. Just saying "best practices" does not logically mean that all three issues are best, nor understood, nor self-fulfilling for an organization. Saying "best recommendations" is more likely to the point.
It's an understandable urge to acquire the best "solutions" that makes some organizations try to force-fit ITIL -- acquiring by forcing themselves to fit ITIL's apparent prescriptions of behavior. Unfortunately, that doesn't work unless everyone wants it to. Meanwhile, organizations can't just simply run an "ITIL.EXE" installation wizard.
This calls for revisiting the idea of "implementation" on a fundamental level. Strictly speaking, implementation means *applying* something (an implement!), as a practical function within an existing operation. Our corporate experience with most large "applications" is that they must be customized to the targeted operational environment before they can "go live" and survive to deliver ROI. But the whole trick to that is to first understand whether the application must be customized to the current environment or to a future environment, or somehow to both. The IT organization, as run by its managers, *is* the environment. The dynamics of that environment are all about people and the reasons why people will do things.
Therefore, the typical prerequisite elements of "implementation" are always "target, commit, adapt", respectively meaning (1) the goal to adopt the implement; (2) the commitment to the necessary level of operational performance; and (3) the ability to adapt to using the implement.
Put differently, the necessary trio of implementation success factors is strategy, maturity models, and change management. Without this trio there is no rational roadmap available to guide the evolution of the organization from its pre-ITIL orientation to its ITIL-orientation. To create this roadmap, organizations may or may not need outside help, but the point is for organizations to embrace the concept of ITIL-orientation as opposed to ITIL-installation.
Posted by Malcolm Ryder at 10:26 AM | Comments (0) | TrackBack
March 12, 2005
Business Alignment in ITSM
Much of what can be figured out about aligning the impacts of IT with the objectives of the business requires the willingness to understand IT as a business. This helps to bring a vocabulary into play that is less technical yet entirely pertinent to the problems at hand. But IT disciplines still need not be forced to resemble non-IT affairs; instead, their business context and direction is what makes them valuable where otherwise they might have just been forceful.
With the business seen as a customer, it is easier to accept that IT impacts should be "productized", and that evaluating IT should happen from the perspective of whether the business is getting a good deal for what it asks for when it orders what IT can offer. The general story is one about the product provided for the payment made. The more specific story is told in terms of how IT takes responsibility for what the business experiences. The following illustrates this story.
Service Availability & Capacity features the management of engineering, configuration and utilization.
Investment Protection features the management of procedures, resources and demand.
Both revolve around “quality”, which is essentially the perceived difference between the provider’s delivery and the receiver’s expectation.
Quality issues pertaining to business reliance on the IT infrastructure most readily surface in three types of events: incidents, problems and changes.
The language required for understanding this perspective on quality needs to be generic, but it mainly points at risks:
- Incidents refer to interruptions of normal user activity.
- Problems refer to defects or errors in intended product makeup.
- Changes refer to alterations of authorized standard provision.
In all cases, the biggest issue is that they occur unexpectedly and compromise the value to be delivered from their respective subjects (i.e., from user activity, product makeup, and authorized standard provision). Timing can make things better or worse.
Against those uncertainties, control is sought. A “control” should be understood generically – as an instance of formally combining a responsibility and authority within a supervisory activity.
Investment Protection works against the erosions of optimal value by proactively instituting “controls” on how:
- the availability and capacity of the infrastructure (as established through engineering, configuration and utilization)…
- … is maintained against the essential business requirements – which are, namely, the pressures of compliance (specifications), cost, and supply levels.
This table generally shows how, from bottom left to upper right, controls for maintenance of service against the business pressures follows suit. For example, at their respective points, managing certifications directly acts on compliance to specifications, while managing orders directly works on levels of supply.
Meanwhile, the connections of one set of controls to another is conversational:
- from left to right, or from bottom to top, the dialog is mainly about assuring response capability;
- from right to left, or from top to bottom, the dialog is about enforcing current priorities.
Business-oriented IT solutions naturally look at integration across IT and business disciplines, by emphasizing attention to these conversations.
Posted by Malcolm Ryder at 7:29 PM | Comments (0) | TrackBack
February 23, 2005
About Enterprise IT
I.T. in the Enterprise:
The number one "problem" in enterprise I.T. is not techniques fighting resources, but instead it is politics fighting strategy. For I.T. to succeed, a strategy derived from the culture must prevail over the politics derived from the culture.
It is so simple to understand why "successful" I.T. must run the gauntlet of first culture, second politics, and lastly discipline:
- People think they have to get something done.
- They want something to do it with.
- They have to get whatever that is.
- When they get it, they have to actually use it to get something -done.
- Sometimes they do what they originally thought they had to do.
- Sometimes whatever they do causes what they thought they wanted to effect.
Because each one of those six steps is rife with uncertainty or trade-offs or both, the probability that appropriate technology will flow through them all to be appropriately applied is always changing.
Accordingly, without change management, there is no probable IT success.
But without policies, there is no change management.
And without strategy, there is no probable policy success.
Posted by Malcolm Ryder at 3:16 AM | Comments (0) | TrackBack