Category Archives: IT Infrastructure

Common IT capability shared across an enterprise.

Why Some Projects Should Be “Led,” Not “Managed”


I’ve posted before (many times!) about Business-IT Maturity, and the common “sticking points” that most IT organizations run into around the mid-point between low and high maturity.  (See, for example, here, here, and here, or enter “Sticking Point” into the search box.)

Walking Ever Faster Will Not Get You Running!

If, arbitrarily, you pick 3 levels of Business-IT Maturity – say Level 1 = low, Level 2 = medium and Level 3 = high, you will typically find that the things you have to do to get from Level 1 to Level 2 not only won’t get you from Level 2 to Level 3 – they will actually prevent you from reaching Level 3!  The trick is to recognize what these things are, and that you are entering a very different learning curve.  For example, if your solutions delivery process is broken, you need a great deal of rigor and discipline – in the form of Project Management and a Systems Development Life Cycle.  That will get you from “chaotic” (Level 1 in my hypothetical 3-Level scale) to “managed” (mid-Level 2).  But over time you will find the limitations of a “managed” approach to solutions delivery – especially when you need to implement “fuzzier” solutions, such as social media, or business analytics.

One Size Does Not Fit All

With solutions delivery, one-size does not fit all, and the methodology that works well for a relatively easily pre-specified transaction processing system (order-to-cash, for example) will not work well for something that is less predictable and more emergent.  Hanging in there with the “official” methodology (for fear of reverting to the chaotic situation that persuaded you to implement the methodology in the first place!) will frustrate the developers, annoy the business client, and will probably lead to a poor or unworkable solution – which will upset everybody!  What is needed is a finer-grained way of categorizing types of business solutions, and flexibility with methodologies to fit the best approach for a given solution type.

What Worked for Transactional Systems Won’t Work for Innovation Solutions

Collaboration and Knowledge Management initiatives are not readily planned using traditional project management methods – they tend to follow an ‘emergent’ pattern that is typically non-linear and somewhat unpredictable.   A traditional planning style, with detailed deliverables, work steps, activities and due-by dates must give way to a more iterative and organic approach.

Social Media Projects Should be Led

You cannot mandate participation in a community – you can invite participation and create reasons to do so. You cannot schedule a date by which a given percentage of a community will be collaborating on a wiki, for example – you can only set expectations, model desired behaviors, and create good reasons for people to become active users of the wiki.  Then you must reevaluate the results and adjust the approach in the light of experience.

Recognizing the Hard-Won Battle – and the Need to Fight New Battles

It seems that sometimes the battle of getting from Level 1 to Level 2 Business-IT Maturity is so hard won, and the win so apparently fragile, that leaders hang on to the methods that got them to Level 2.  This is about being really good at solving yesterday’s problems.  It’s a different world today, and the ways that technology and information can be exploited for business advantage demand different approaches.  Don’t let the trappings of Level 2 restrict your ability to get to the next level!

Enhanced by Zemanta

 

About these ads

The Decline and Fall of the IT Organization?


With apologies to Ed Yourdon for my plagiarism of his original the book title, published back in 1993, “The Decline and Fall of the American Programmer“.  (Though I don’t recall if Ed gave apologies to Gibbon for first using this line!)

For a blog entitled “IT Organization 2017″ and for a management consultant who has had a very satisfying professional career consulting to IT organizations, the title of this post may seem both extreme and inappropriate.  However, I use the title not just as a controversial ‘hook’ to attract readership, but as a sincere expression of what I think is happening today – and will continue to do so.  The traditional role of the IT organization is on the decline and will never return to the importance and business value impact it had over the last 50 years.  The good news is, there is a crucial new role emerging – and for IT leaders that can envision and lead the new possibilities, I believe there’s a bright new future – perhaps brighter than the traditional IT leadership role.

So, Who Screwed Up the IT Organization?

I’m not sure this is anyone’s ‘fault’ per se, or could have been avoided.  Rather it is a natural by product of technological evolution.  Back in the late 1800′s, many corporations employed Chief Electrical Officers.  Nick Carr gets into this nicely in his aptly named book, “The Big Switch.”

A hundred years ago, companies stopped generating their own power with steam engines and dynamos and plugged into the newly built electric grid. The cheap power pumped out by electric utilities didn’t just change how businesses operate. It set off a chain reaction of economic and social transformations that brought the modern world into existence. Today, a similar revolution is under way. Hooked up to the Internet’s global computing grid, massive information-processing plants have begun pumping data and software code into our homes and businesses. This time, it’s computing that’s turning into a utility.”

The shift from electricity as a highly specialized resource to commodity took about a decade as standards such as voltage, alternating current, plug and socket configurations, and so on were settled.  Once the standards existed, businesses could simply plug into a grid – electricity became a commodity, and the Chief Electrical Officers become extinct as the Dodo.

An Historical Perspective

The first commercial mainframe computers, the LEO were created in 1951 by J. Lyons and Company, a British catering and food manufacturing firm.  The idea of a food and catering company today designing and building it’s own computer is unthinkable!  I remember in the late 1960′s, businesses such as Massachusetts General Hospital were creating their own programming languages, data base software and teleprocessing monitors – activities that would be considered wholly irresponsible today.  I wonder if 15 years from now we will look back at the turn of this century and be bemused by the fact that typical companies of any size at all maintained IT organizations – in some cases, thousands of IT professionals – writing programs, tending help desks, and so forth.

So, What’s Happening to the IT Organization?

For many years the annual surveys of top CIO issues list business-IT alignment. It’s a noble and challenging goal – and it’s no longer the right goal! A combination of technology advances, advances in standards and architectures (mostly prompted by the Internet revolution) and the increasing IT literacy across the business means that the challenge has moved beyond Business-IT Alignment to Business-IT Convergence.

From Business-IT Alignment to Convergence

Let’s drill further into this convergence phenomenon. Today, many IT activities, including project management, information analysis, application configuration are devolving into Business Units while others are consolidating with support functions such as HR, Finance, etc.  Helping to drive this is the rapid consumerization of IT devices and services, with iPhone’s, iPads, Android devices and the like becoming an important window into business systems and information.  Further driving this is the increasing ‘IT Savvy’ and confidence with IT that business executives, line managers and workers (especially, knowledge workers) increasingly feel.  This is in part generational – people entering the workforce with high IT literacy, and in part a byproduct of people’s engagement through social media, e-commerce and so on.

From Owning to Sourcing IT Capabilities

The last decade or so has seen a shift from owning all needed IT capabilities (data centers, server farms, software teams, application development groups, desktop support, etc.) to sourcing these capabilities externally.  Today, traditional functional outsourcing is being continuously expanded, and now often includes Business Process outsourcing as well as the outsourcing of compute power, data storage, IT infrastructure, applications and platforms through the rapid rise of Cloud Computing.

Information is Becoming both Strategic and Implicit

Information is becoming an increasingly strategic asset.  There is compelling research data showing how companies are successfully embracing and competing on business analytics.  At the same time, data is also becoming implicit to business management and operations – increasingly representing what the business manages and how it manages. In many respects, the context for IT today is becoming less about IT and more about information – the ability to capture, integrate, interpret, predict, and act is increasingly the holy grail of competitive advantage – and that belongs in the business – not in a separate specialist group.

So, Where Do IT Capabilities Belong?

Now, I’m on dangerous ground, because the answer depends – on the nature of the business, IT savvyness of business managers and knowledge workers, and their vision for how they want to deploy and manage information and IT.  But, I’d argue that many IT capabilities belong in business operations.  For example:

  • Business Process Management
  • Business Analytics
  • Project Management
  • Satisfying Business Unit application needs

Other IT capabilities belong in the governance of the business.  This might include, for example:

  • Enterprise Architecture
  • IT Strategy
  • Portfolio and Program Management

And finally, some IT capabilities should be centrally coordinated and shared. Examples here include:

  • Common and shared IT Infrastructure
  • Enterprise Applications

So, What Are the Implications for IT Leadership and the IT Professional?

I will save that for a follow-up post, but suffice it to say that most companies and their IT organizations are not quite ready for the shift I’m espousing (and, indeed, predicting).  And, I think it is the clear responsibility of IT leadership to help lead this revolution – ensuring that it is orderly and safe – ensuring that the business and IT professionals are fully prepared and able to take advantage of business-IT convergence.

Please join me in the next post on this topic – and in the meantime, please weigh in with your perspectives and observations.

Painting by Joseph-Noël Sylvestre: The Sack of Rome by the Barbarians in 410

Enhanced by Zemanta

Threats and Opportunities in the Cloud – Coming to a City Near You!


I’ve posted before about Cloud Computing and I am delighted to let you know that I have been invited to speak to this topic at an upcoming CIO Forum Series sponsored by Pariveda Solutions and Microsoft Windows Azure.

I believe that there is an inevitability to the Cloud as a new way to deliver capability and functionality and that the implications are far reaching for IT organizations.  One implication that I am already seeing play out is the disintermediation of the IT organization as businesses look to short cuts and workarounds to get their pet initiatives deployed.  This is not inherently bad, but it is a slippery slope.  Businesses will unwittingly take on risks they don’t understand and ultimately, it will be the responsibility of the CIO to sort out the mess!

Cloud Computing and Business-IT Maturity

I’ve also posted extensively on the Business-IT Maturity Model and for this CIO Forum Series I will be examining the threats and opportunities for Cloud Computing at each level.

The event will be held in 4 US cities as follows (please click on the link for the city you are interested in signing up for to be taken to the appropriate registration page):

Here’s a quick introduction to the events:

Agenda

The agenda for each session will follow the same format:

  • 6:00 – 6:30 Drinks
  • 6:30 – 7:30 Dinner
  • 7:30 – 9:00 Introduction – Threats and Opportunities in the Cloud
  • Business demand and IT supply maturity:
    • Challenges and Opportunities at Level 1: Infrastructure and Core Solutions
    • Challenges and Opportunities at Level 2: Business Process Enablement
    • Challenges and Opportunities at Level 3: Product, Process and Business Model Innovation
  • Understanding the Cloud Provider Landscape
  • Real-World Cloud Cases
    • Level 1 Case: Scaling through Infrastructure On Demand Outsourcing
    • Level 2 Case: Extending reach and enhancing customer experience
    • Level 3 Case: Innovating products and business models
  • Building your Cloud Agenda
  • Panel Discussion
Enhanced by ZemantaPlease join me and my co-presenter, Brian Orrell for what promises to be an informative and enjoyable evening!

Three Ways To Increase IT Organizational Agility


Back in a September 2010 post, I asked, “How Agile Is Your IT Organization?  How Would You Know?“  The question came about as part of a research project I’m involved in through my affiliation with Formicio.  The aim of the research is to identify the factors that make IT organizations agile and recommend how agility can be developed as a core capability.  (Phase 1 of this research is still open – please feel free to participate by completing a survey here – it should take about 30 minutes, is free, and I believe you will find the questions stimulating!)

What Does ‘Agility’ Mean to an IT Organization?

Wikipedia defines agility as:

The ability to change the body’s position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, endurance and stamina.  In business, agility means the capability of rapidly and efficiently adapting to changes.”

From the perspective of the research project, we defined IT agility as:

The ability to rapidly and easily incorporate new technologies and methods into the way the IT organization operates, thereby having the capability to effectively sense and respond to changing business conditions in a timely manner.”

Why Does Agility Matter to an IT Organization

Simply stated, most business executives I speak to feel that their IT organizations lack agility! To paraphrase the typical response:

Things take too long to get to the point where they are delivering business results, and the IT organization typically seems to be behind the curve on emerging technologies!”

You may disagree with this statement, but I think most of you will agree that it is the common perception of your business executives.  In a world that seeks instant gratification, that is a value that is not typically embraced by IT organizations – and perhaps it should not be?  In a world where the business and competitive context can change almost overnight, increasing IT organizational agility should become an active goal.

So, What Have We Found?

The data is still coming in, and the numbers being crunched, but a couple of early observations:

  1. Your perspectives on Enablers and Barriers to agility depend upon where you sit.  In a federated IT Operating Model (some centralized, some decentralized), those that sit in the central camp tend to see shared IT capabilities as enablers of agility, whereas those in the decentralized units tend to see shared capabilities as inhibitors to agility, and seek more freedom from the ‘mothership’ in order to increase agility.
  2. Even with the definition of IT organizational agility provided as part of the research, its meaning is very squidgy and Rorschach-like – you read into “IT organizational agility” what you want to see.
  3. Fans of Agile Development equate IT organizational agility to Agile Development – they are essentially one and the same to them.  On the other hand, when you drill into what teams are doing with Agile Development, what you find is all over the map.  To some teams, it is a license to take short cuts, no matter what the consequences!
  4. Governance is desperately misunderstood!  This will be a subject of a separate post (or two!), but what I am seeing as I pour over the research findings indicates some governance perceptions that are way off base.  Again, it depends where you sit, but while some see governance as an agility enabler, others (in the same organization!) see it as a major barrier!
  5. The very different perspectives on what is meant by IT organizational agility and why it is important is quite troubling – if you can’t agree on what it means and why you want it, you are unlikely to increase your IT organizational agility!

Three Ways To Increase IT Organizational Agility

So, given those findings, here are three relatively ‘quick wins’ that will at least get your leadership talking in the same direction (excuse the mixed metaphor!)

1. Get clarity on what IT organizational agility means to you.

Don’t get wrapped up in academic definitions – focus on what it means to your organization.

  • What are your business drivers for IT organizational agility?  If you were more agile, what good things would you be capable of that you aren’t today?
  • Complete the tool in our research survey and use the 6 Domains of IT Agility to drive discussion internally on your enablers and barriers to agility.
  • Get to a consensus on the factors that need to be worked on for increased agility.
  • What do you see as the connections between agility and collaboration?
  • What do you see as the connections between agility and knowledge management?
  • What do you see as the connections between agility and Enterprise Architecture?

2. Identify where Agile Development fits in and how you will exploit that without increasing project risk.

Get clarity on Agile Development – what it is, and what it is not!

  • How do you define Agile Development for your organization?
  • When, where and how should you use Agile Development?
  • How will you define and monitor success?
  • What ‘unintended consequences’ will you look for and how will you mitigate against them?
  • What else is needed to increase IT organizational agility above and beyond Agile Development as you’ve define it?

3. Get to a shared understanding of IT Governance.

Get clarity on how you define IT Governance.  Again, don’t get wrapped up in academic definitions – define what it means to your organization.

  • What are the various aspects of organizational governance in your organization? (Don’t be limited by “formal” structures – consider aspects such as empowerment, decision rights, accountabilities, processes, culture of compliance, consequences for compliance or lack thereof.)
  • What is it about your IT governance that enables agility?
  • What is it about your IT governance that inhibits agility?
Enhanced by Zemanta

Do You Have IT Organizational Clarity – Part 3


This picks up on Part 1 and Part 2 in this series on IT Organizational Clarity.

In Part 1, I discussed the importance of IT Organizational Clarity, the symptoms when clarity is compromised, and the challenges of trying to address those symptoms rather than the root causes that lead to compromised clarity.  Part 1 closed with a discussion of the two key dimensions along which IT Organizational Clarity can be tackled – scope (units of IT Capability) and meaningful and assessable characteristics for evaluating and improving IT Capabilities.

In Part 2, I discussed ways to define IT Capabilities and provided guidelines on the manageable number of IT Capabilities and appropriate depth of decomposition.  In this post, I will describe three different types of IT Capability.

Not All IT Capabilities Are Born Equal

It is helpful to classify IT Capabilities into one of three different types, as illustrated in the graphic above.

Value Chain Capabilities

At the core are those capabilities that take inputs, add value, and deliver outputs to a customer or end consumer (in the world of IT, these tend to be services and products).  Think of these Value Chain Capabilities as those that the end customer appreciates (hopefully!) and is willing to pay money for.

For example, as a business user, I may have a business problem I’d like IT help to solve.  That problem (or opportunity) is the input to a Value Chain.  The first Capability that will approach that problem adds value by analyzing the problem, identifying and proposing a solution.  As the business user, I appreciate that value has been added – drilling into my stated problem and offering (and perhaps demonstrating via a prototype) one or more proposed solutions.  The next Capability in the Value Chain might take the chosen solution and develop and deploy that solution.  Again, as the business user, value has been clearly added – taking a proposed solution and delivering it.  The final Capability where value can be added is supporting and maintaining that solution – again, a recognizable way of adding value for me, the customer.

Ultimately, as the business user or consumer, these are the only Capabilities I care about and am willing to pay for (directly or indirectly) because of the value they add for me.  Unfortunately, while these Value Chain Capabilities are necessary, they are not sufficient.

Enabling Capabilities

Value Chain Capabilities typically draw upon other Capabilities that enable them.  Think of these as Shared Services that are common to other Capabilities, or to other instances of problems/solutions working their way through the Value Chain.  Examples of IT Services that might enable the Value Chain Capabilities include Project Management, IT Operations, and IT Supply.

Alignment and Governance Capabilities

Value Chain Capabilities also typically depend upon other Capabilities that ensure that the work they are doing is aligned and governed to ensure they are operating effectively and in the interests of the enterprise.  For example, determining which business problems will be addressed, which solutions will be selected, how staff and resources will be allocated are all important control that Value Chain Capabilities will be subject to.

Why These Distinctions Matter to IT Organizational Clarity

The distinctions between Value Chain, Enabling and Alignment/Governance Capabilities are significant:

  1. Different types of IT Capability tend to be optimized towards different value propositions, with implications for how they are organized.  For example, Enabling Capabilities tend to be optimized for Operational Excellence (as shared services, they need to deliver predictable, consistent, quality services at the lowest possible cost).  Value Chain Capabilities tend to be organized for Customer Intimacy, delivering what specific customers want; anticipating customer needs.  Alignment and Governance Capabilities tend to be more about decision-making – rather than delivering services, they make decisions or provide decision-making frameworks – think Enterprise Architecture and the mechanisms and structures that support it as Alignment and Governance Capabilities.  As such, these tend to be networked, linking stakeholders and decision makers, and optimized to maximize the business value delivered or enabled by IT Investments..
  2. Some types of IT Capability lend themselves to alternate sourcing more than others.  For example, Aligning and Governance Capabilities lend themselves the least to straight outsourcing approaches (do you want to pass decision rights to an external vendor?)
  3. Different types of IT Capability lend themselves to different funding models.  For example, Value Chain Capabilities lend themselves to direct business funding, whereas Enabling Capabilities lend themselves better to indirect funding models (e.g., overhead charge).

IT Capability Model Example

As an illustration, below is a ‘normative’ IT Capability Model.

The Fractal Nature of IT Capabilities

Note, that as you decompose any IT Capability, you will generally find that the decompositions will have a similar structure – a primary Value Chain, drawing upon underlying Enabling Capabilities and influenced by Alignment and Governance Capabilities.

For example, Manage Business-IT Portfolio & Programs might decompose into the following sub-Capabilities:

In the following post, we will look at the assessable characteristics of any IT Capability as a means of determining Capability Maturity and determining how to increase maturity and thereby improve performance.

Enhanced by Zemanta

Do You Have IT Organizational Clarity – Part 2


My previous post introduced the topic of IT Organizational Clarity, discussed common symptoms arising from a lack of Organizational Clarity, and suggested two dimensions through which clarity can be assessed and improved:

  1. Bounding scope by defining “IT Capabilities” at an appropriate level of granularity. (Units of analysis).
  2. Defining meaningful and assessable characteristics for IT Capabilities. (Means of assessing and improving).

Note – the ultimate gauge of IT Organizational Clarity is in the ‘health’ of the IT Organization and the business results to which it contributes.  However, there are all sorts of demand-side complexities in assessing these things, so for now I will focus on the notion of capability maturity as a worthy proxy for and predictor of end results and the ability to continuously improve.

In this and the next couple of posts I will discuss the notion of IT Capabilities and how best to define them.  I will then address the assessable characteristics of IT Capabilities.

What Is an IT Capability?

In order to adequately define an IT Capability, we need to clarify a couple of common terms – Service and Process:

Service

A Service in the context of IT Capabilities is best described as the interface point between a provider and a consumer where value is exchanged.  Services should be defined from the perspective of the consumer.  They need to be ‘discoverable’ and the service interface understood by the consumer.  They need to have clarity on what they do, what they cost, how they are invoked, and how problems are reported and resolved.  The service provider should have a good understanding of the value received by the consumer, as well as the overall quality of the customer experience.  This may comprise both tangible and intangible elements, most of which are ultimately subjective.

Process

A Process is a sequence of interdependent and linked procedures which, at every stage, consume one or more resources (employee time, energy, money) to convert inputs (data, material, etc.) into outputs.  These outputs often serve as inputs for the next stage until a known goal or outcome is reached.

Capability

A Capability can be thought of as everything it takes behind the scenes that makes a service possible.  This will include:

  • One or more Processes.
  • Descriptions of the Roles needed to perform one or more of the procedures within a process (e.g., Project Manager, Business Analyst, Relationship Manager).
  • Descriptions of the Competencies needed to perform a given role (what the person performing the role needs to know, e.g., business knowledge, what skills they need, e.g., facilitation, and what behaviors they should exhibit, e.g., results orientation).
  • An adequate supply of competent human resources filling the given roles.
  • Tools and technologies needed to automate or execute necessary processes or procedures.
  • Management systems necessary to ensure the health and performance of the Capability, including funding, organizational will, personal incentives, and so on.

How Many IT Capabilities Should You Have?

This is a tricky question to answer.  First, of course it depends on the mission to be served by a given capability.  But more importantly, this is a question of granularity.  In the heady days of business process re-engineering, I learned that picking the right granularity for an end-to-end process is crucial, and perhaps as much art as science.

I think this question has more to do with the characteristics of and limitations to the workings of the human mind than anything else.  If you end up with, say, 3 IT capabilities, chances are that you are at too high a level of granularity to be really useful in terms of analytical and management discipline.  On the other hand, if you have 12 or more IT capabilities, you are at too low a level.  From my experience, between 7 and 9 is the right number of IT Capabilities to have in a ‘top-level’ IT Capability model.

How Many Levels of Decomposition Should You Go To?

Yes – you guessed it – it depends!  On the basis that you really don’t understand a Capability unless you can see a level of decomposition below it, I think the answer is at least two levels of decomposition are necessary.  Beyond that, it depends on the Capability you are trying to understand or improve.  Consider, for example, the Process aspect of an IT Capability.  Capabilities that are highly procedural, such as those found in IT Infrastructure and Operations, will typically need more levels of decomposition (i.e., more detailed process definitions).  Coincidentally, this is the domain of ITILv3, so you can effectively ‘buy’ process definitions and a process architecture off-the-shelf.

On the other hand, a Capability such as Opportunity Discovery may be more about analytical skills and the magical space between problem understanding and solution definition.  This space is much more about specially-skilled people and specific business domain knowledge rather than sequential, detailed and rigorously controlled processes (as in Statistical Process Control.)

We will pick this up in the next post and look at three different types of IT Capability  – Value Chain Capabilities, Aligning/Governing Capabilities and Enabling Capabilities – and examine the distinctions between these and why the distinctions are important.

Graphic courtesy of MassBay Organization Development Learning Blog

Enhanced by Zemanta

Selling Enterprise Architecture Through Analogy


I use analogies a lot – in my teaching, consulting, and just about everywhere else!  By no means a panacea, a well chosen analogy can make things “click” for people who might otherwise not “get it.”

“Selling” Enterprise Architecture

I’ve blogged frequently about Enterprise Architecture (and its subset, IT Architecture) because I believe it is a fundamental, literally, foundational discipline for business enablement through IT, and yet is woefully under-served in most organizations.  One reason is – it is tough – balancing competing needs for standardization on the one hand, and innovation on the other.  The other reason is IT architects are often poor  business communicators, and are inept in “selling” the effort necessary to do things in an “architected” way.

Architecture and the New York Subway

My temporary relocation to Manhattan has allowed me to experience the New York subway (and bus) system more fully than ever before – and it makes a great analogy for Enterprise Architecture – or its lack thereof!

New York’s public transport is a gem!  No, it’s not world class (try Singapore’s or the Washington DC Metro system for examples of clean, quiet, fast systems) but it works.  However, I have quickly become aware of many idiosyncrasies of the New York subway.  Certain stations (e.g., 14 Street, 59th Street-Columbus Circle, Borough Hall) where you need to change lines, don’t seem to ‘line up’ properly – you have long underground walks, underground shuttles, or, in some case, have to surface to street level in order to go back down to the different line (these are aptly referred to as “station complexes” and complex they are!)  Some connections between lines that should be simple, aren’t!  It felt to me as if there wasn’t a coherent architecture to the subway system – so I did a little research to find out why.

Three Subway Architectures!

In 1898, the City of Greater New York was formed from several counties and their constituent cities, towns, villages and hamlets.  The City recognized the need for an underground subway system, but also realized that no private company would provide the significant capital required for such an infrastructure.  The City decided to issue rapid transit bonds and contracted with the Interborough Rapid Transit (IRT) to build and run the subways, sharing the profits with the City.  IRT opened the first NY subway in 1904.  Meanwhile, the Brooklyn-Manhattan Transit (BMT) was building and buying up the Brooklyn elevated rail lines.

In 1913, the city embarked on a “Dual Contracts” initiative, engaging the private IRT and BMT to expand their systems.  By the 1930′s, the City realized that the independent IRT and BMT were making handsome profits, so the City of New York created its own third system, the Independent Subway System (IND).  The IND introduced yet a third architecture, so that the IND, IRT and BMT were competing with each other.

The Challenge of Integration

This competition led to overlapping services and different standards (such as carriage width, carriage length, train stop safety mechanisms).  In 1940, the City took over the transportation assets of the BMT and IRT under a program called Unification.  However, to this day, due to different tunnel diameters, curves and clearances and the different rolling stock, asset utilization is sub-optimal, and for passengers, navigating the subway system can be challenging and inefficient.  To eliminate overlapping and redundant services, certain stations and even some tunnels had to be closed.  Also, costly “interfaces” had to be built between the three separate systems in the forms of tunnels, walkways and shuttles.

If New York City Were a Business?

Imagine the City of New York as a business, and the IRT, BMT and IND as separate divisions.  Imagine that each division wants to create its own IT organization and IT capabilities.  Imagine there is no overarching architecture or standards.  Now imagine, as a business you recognize the synergies between your three divisions, and want to integrate and leverage as many shared services as possible.  What do you find?

  1. It’s incredibly costly to achieve integration because your three IT infrastructures are incompatible.
  2. You discover you have excessive redundancy across the three IT infrastructures.
  3. The cost of keeping the IT infrastructures running is eating into your operating margin, and yet the capital cost of rationalizing the infrastructures is prohibitive.
  4. With eCommerce and Enterprise 2.0 possibilities, you need to collaborate more effectively across divisions than you do currently, but none of the three IT infrastructures will support that type of collaboration.
  5. You ask your CIO, “How could you let this happen?” as you look for a replacement!
  6. Your CIO points to the chief IT architect and blames him for doing an inadequate job of convincing the IRT, BMT and IND divisions of the need for an overarching architecture.
  7. Your chief architect commits suicide (by jumping in front of a subway train?)

The Value of Enterprise Architecture

So, what were the costs of the lack of a unifying architecture to the NY Subway system?  Had the IRT, BMT and IND followed an overall architecture and set of standards, how much time and money would have been saved compared with the “each go it alone” approach?  That is the value of architecture.

What analogies can you use that will resonate with your senior business executives to sell them on the value of Enterprise Architecture?

The Downside of Standardizing Too Soon

In all fairness, I must reference the fact that choosing standards too soon can and does stifle innovation.  The beginnings of the New York Subway occurred while there was a fierce competition between Nikola Tesla’s Alternating Current (AC) and Thomas Edison’s Direct Current (DC) systems.  DC won out (for good reasons at the time) but modern solid state technology and advances in electric motor and switching technology mean that AC would have led to a simpler, more flexible and less costly subway system construction.

Image courtesy of Blog Them Out Of The Stone Age

Reblog this post [with Zemanta]

Collaboration – Finding a New IT Order in the Chaos!


fractalIT organizations are complex beasts – both in terms of the number of moving parts with their many subtle relationships and in the more scientific use of the term – as in complex systems theory.

Mastering 3 Fundamentally Different Value Propositions

IT Organizations have to deliver day-in, day-out on three very different value propositions:

  • Operational excellence for IT infrastructure.
  • Customer intimacy for leveraging business unit IT.
  • Product leadership/innovation for exploiting business opportunities and new operating models made possible through emerging technologies.

Leaders of IT organizations are under a punishing spotlight – the costs seem to continually increase, and the value is often hard to see.  60% – 70% of most IT organization’s activities are only visible when something goes wrong.  Much of the time, IT work is invisible.  The underlying technologies are all evolving rapidly, as are the business models through which technology is being delivered, including in-house managed, outsourced, off-shored, Software as a Service and Cloud Computing.

Increasingly, everybody thinks they know more about IT than their IT organization, and wonder why a PC that costs $400 in the local Best Buy and works right out of the box, costs $4,000 at work and usually does not work without the intervention of the Helpdesk!

Fuzzy Organizational Boundaries

As if those complexities were not enough, the boundaries between the work of the IT organization and the businesses it serves are both blurring and shifting.  What used to be the “official source” of all things related to IT is now just one of many sources – including self service, the computer jockey who hangs out in the mail room, the Geek Squad (from the Best Buy that just sold me that $400 PC!) and the World Wide Web – from which I can get free software by the bucketful, cheap hardware, and enough willing support and development resources to tackle just about anything!

And, to make matters worse, many IT organizations are falling behind in terms of what they make generally available and possible for their business partners compared with the state of the art.  It seems that people can accomplish just about anything via the Internet.  However, for many of them, they have to go home to do it!  When in the office, some of the more important and potentially innovative things people want to do are blocked.  Whereas the IT organization’s vision might say something about “enabling the business”, much of the time it feels more like a barrier.

Trying to Control the Uncontrollable

It is not surprising that the natural instinct of any IT leader is to try to control the chaos.  However, I believe that lens of complexity theory provides insights into more productive and less painful ways of controlling the environment than the draconian measures traditionally employed.  In particular, I believe that approaching IT organizations as the Complex Adaptive Systems (CAS) they have indeed become will prove to be a more effective  paradigm for organizing and managing IT capabilities – creating a new order out of the chaos, if you will.

A CAS is a special cases of complex system.  As Wikipedia notes,

They are complex in that they are diverse and made up of multiple interconnected elements and adaptive in that they have the capacity to change and learn from experience.  Examples of CAS include ant colonies, the biosphere and the ecosystem, the brain and the immune system, the cell and the developing embryo, manufacturing businesses and any human social group-based endeavor in a cultural and social system such as political parties or communities. This includes some large-scale on-line systems, such as collaborative tagging or social bookmarking systems.

Features of complex systems

Complex systems have boundaries that are hard to determine, just like IT organizations.  They exhibit “memory” in that prior states may have an influence on present states.  This effect can sometimes be seen as an organization’s tendency to return to its current patterns of behavior, even when disturbed by an intervention such as a reorganization.  CAS exhibit “emergent” behaviors – behaviors that emerge from a complex interaction between CAS components, and can be impossible to predict.  For example, social networks around a particular topic or issue can emerge without any specific effort to create such a network, while attempts to foster a given community quickly might fade away.  Relationships in CAS are non-linear – a small force can have a large impact, and vice-versa – often called the “butterfly effect.”

This CAS lens presents a far more accurate perspective on IT organizational behavior than does the deterministic view that has dominated IT organizational design for the past 50 years or so.  In today’s emerging Web 2.0 world (and beyond) we need to manage IT as an organic capability, rather than through functional organization designs with their “lines and boxes”.

To be continued…

In subsequent posts, we will discuss the implications of considering the IT organization through the lens of Complex Adaptive Systems, and see what new organizational constructs might be more appropriate for a Web 2.0 world.  Please join me on this intriguing journey – tell us how you are seeing the lessons from nature and complex adaptive systems apply to IT management.

Reblog this post [with Zemanta]

How “IT-Savvy” Is Your Company? Why Does That Matter?


weillross_300dpiRegular readers will know that from time to time I refer to research by Peter Weill, Chairman & Senior Research Scientist, Center for Information Systems Research (CISR) at the MIT Sloan School of Management.  I’ve had the privilege of knowing Dr. Weill for many years, and having collaborated with him on several multi-company research initiatives.

Peter and his colleague and co-author Jeanne Ross recently published their latest book called IT Savvy: What Top Executives Must Know to Go from Pain to Gain.

This is an excellent and important book.  It is notably the first book by this duo written for the top executive community, rather than for IT professionals – the target readership for prior Weill/Ross books.  I’m well known for repeating the mantra, “Organizations get the IT they deserve!” This book really reinforces the leadership roles and practices that help converge business and IT.  The ideas are beautifully organized, clearly presented and convincingly illustrated by interesting case studies.

I don’t want to pretend that one book can, by itself, move you along the road to “premium return on IT.”  But it sure is a great resource and, most importantly, a way to educate your key stakeholders what it takes to get on the right road!

Practices that Earn a Premium Return on IT

The authors, building on 15 years of research, describe what they refer to as the “Three Obsessions of the IT-Savvy Firm.”  These are:

  1. Fixing What’s Broken About IT.
  2. Building a Digitized Platform.
  3. Exploiting the Platform for Profitable Growth

Citing several case studies to illustrate their points and help make the practices real, they work through issues of business operating model and the IT implications of operating model choices: IT funding model, digitized platforms, governance, driving value, and leadership.

Read, Share and Discuss!

Read this book with the idea of sharing it with your business partners and stakeholders.  Set up or take advantage of current opportunities to drive dialog around the implications of IT Savvy to your organization.

I believe you will recognize in the IT Savvy book many of the practices, recommendations, and “vignette’s” that surface in this blog from time.  In fact, Peter and Jeanne’s work over the years, and my research experiences with Peter, has greatly influenced my belief system, and with it, my approach to IT management consulting, at least over the last 15 years!

Book Cover Image Courtesy of Harvard Business Press

Reblog this post [with Zemanta]

I Must Have my Head in the Clouds!


Streaky Freaky CloudsI’ve been posting on and off about Cloud Computing since I began this blog a couple of years ago.  But, as one who spends most of his time with IT leaders of large global enterprises, sometimes the promise of the Cloud seems more like a mirage!

I’ve Looked At Clouds From Both Sides Now

Back in August 2008, not being able to resist the title to the wonderful Joni Mitchell and her reference to “cloud illusions I recall”, I posted on the denial I was witnessing among my client base.   I likened it to the denial that was common among CIO’s back in the early 1980′s.  To quote from that post:

(CIO’s) were mostly in denial, even as executive offices just down the corridor from the CIO’s office were beginning to become home to a variety of rogue PC’s – machines such as Apple II’s and Radio Shack TRS 80’s.

Fast forward 25 years or so. Now the press is full of predictions and prognostications about Cloud Computing, several key players are investing heavily in this space (pun intended) but many CIO’s and CTO’s either just don’t believe it, see it as warmed over service bureau computing from the 60’s and 70’s, or believe it’s the greatest threat to enterprise computing sanity since computer viruses first appeared.

Now, nearly 1 year later, I’m still seeing the same denial – Cloud Computing, for the most part, is on the back burner – a technology to watch!  Clearly, there are significant risks with the untried, standards are still evolving, and there’s something intimidating about such a simple concept being able to replace so much enterprise technology and expertise – the “heart and soul” of the typical IT organization.  In fact, for many IT shops, this “heart and soul” is where they’ve invested many of their improvement efforts over the last few years, implementing ITIL and process improvement approaches.  That’s been a hard-won fight, and CIO’s are loathe to admit that there might now be an easier and better way!

In another post earlier this year on The Dangers of Cloudy Thinking, I wrote:

I’m fascinated and bemused by this Cloud Computing phenomenon. Never before have I had such a strong feeling that something really, really important is happening – a fundamental discontinuity, if you will, in the way we leverage IT – and yet most of my clients and those I am interacting with in a couple of multi-company research projects are essentially standing on the sidelines.

Hincliffe’s “8 Ways That Cloud Computing Will Change Business”

Dion hits the nail on the head once more with his excellent June 5 post in which He says:

(Cloud computing offers) benefits that can potentially change the game for many firms that are willing to be very proactive in managing potential downside. These include access to completely different levels of scale and economics… Easier change management of infrastructure including maintenance and upgrades (cloud vendors extensively virtualize and commoditize the underlying components to make them non-disruptive to replace and improve) … Cloud computing also offers an onramp to new computing advances such as non-relational databases, new languages, and frameworks that are designed to encourage scalability and take advantage of new innovations such as modern Web identity, open supply chains, and other advances.

He goes on to show the major pros and cons, and then to cite 8 compelling ways that cloud computing can change business.

Cloud Computing – Ideal for the “Edgy” Opportunities?

Dion refers to the use of cloud computing beyond “edge” computing (which he describes as minor applications and non-critical business systems).  This is the only place where I take issue – I think “edge” computing is where the exciting action is, where the high value and innovative opportunities lie.

Back in July 2008, I posted on “Edginess and Innovation.”  In that post, I differentiated between “core” and “edge”:

Many IT leaders when talking about the “core” are referring to the “legacy” systems…  built over the years and have to maintain.  But in reality, the core goes much deeper than the systems and technologies. Business processes – especially when you include the unautomated practices and workflows that interact with the automated ones, are hard to change. The mindsets that dominate “core” thinking and “edge” thinking are radically different. I’ve noted before that quality guru Joseph Juran distinguished between “preventing bad change” (keeping processes under statistical control” and “creating good change” (innovating processes and products, or creating “breakthrough” performance as Juran put it) and the different management approaches and structures each requires. Most IT leaders have focused for years on management approaches more consistent with preventing bad change than creating good change. This has created a mindset that abhors risk taking.

I believe most of the “core” opportunities have been addressed in the typical global enterprise.  Sure, there’s always more to do (and the trap of saying “yes” to all the business requests to continually tweak and bolt onto core systems) but I believe you can move the business value needle significantly to the right by tackling more of the “edge” opportunities, and that is where, to Dion’s point, the Cloud (and its related technologies) offers real promise – now!

Reblog this post [with Zemanta]