This is the first in a multi-part post on what I’m referring to as “IT Renewal.”  Some people call this “IT Transformation” or “IT Transition”. Others don’t name it – they just do it as a natural part of how they run and continuously improve the ‘business of IT.’

The Convergence of Consumer IT and Business IT

Information and technology are becoming ever more central to what a company (or government, or any organization) does and how it does it. IT for the consumer world (think iPhones, iPads, Kindles, Facebook, eBay, and so on) and IT for the business world are converging. After all, business people are consumers, their customers are consumers, and how we navigate our personal lives spills over into our business lives and vice versa. And as the new workers join the workforce, they do so with an IT literacy and a set of expectations about how they will work, collaborate and communicate.

These consumer devices and services not only allow us to do our work in different ways (think mobile, for example), they also allow us to do different types of work (think sentiment analysis – what are our customers, prospects, competitors, et al saying about us? Or location-based marketing. Or participating in communities of interest or practice.)

The Changing Roles of the Corporate IT Organization

The convergence of business and consumer worlds is beginning to have a dramatic impact on corporate IT. Imagine the following scenario.

Mary, a sales and marketing Vice President, approaches her IT organization with a request to implement a CRM solution. “Yes – we can do that. It will take about 2 years to do, but we can’t get to it until next year. And it will cost about $20 Million, give or take 30%.”  Mary then sees an ad for ‘CRM in the cloud’ and calls the vendor. “Yes, we can get you started today. It’s probably best to start with a pilot group, which we can do for $40 per user per month. We can then bring the cost per user down as you scale up the number of users. And you get a 30-day free trial to make sure our solution fits your needs.”

So, what’s Mary going to do? She’s been charged with driving up sales and she’s convinced that a CRM solution is a key tool to do so. Easy choice, right? She goes ahead with the cloud solution. Variations on this scenario are playing out every day. The more visionary IT leaders are partnering with the Mary’s in their companies, and helping them chose the right vendor and deal with issues such as privacy, security, data ownership and so on. The less visionary leaders are in denial – the cloud is a passing fad. Mary’s going ahead with the Cloud solution anyway. The only question is, does she do it behind Corporate IT’s back, or with their blessing, help and guidance?

The Need for IT Renewal

In the previous paragraph, I used the labels ‘more visionary’ and ‘less visionary’. I could have use the terms ‘renewed’ and ‘un-renewed.’ Or, ‘transformed’ and ‘un-transformed’. Progressive IT leadership is working at repositioning the IT organization as a business enabler – no matter how and where IT capabilities are sourced. In many respects, the core IT roles are shifting towards Enterprise Architect and Integrator, rather than manager of data centers and server farms, developers of systems and software and managers of projects. This shift is what I’m referring to as ‘IT Renewal.’

The Cloud is Both a Driver – and an Enabler of IT Renewal

So, the key roles of an IT organization are being changed by the inevitable emergence of the Cloud as an option in the delivery of IT services. Can the IT organization also leverage the Cloud to enable and drive IT Renewal?

The answer is, I believe, a resounding, ‘yes’. And doing so is essential for getting ahead of the curve for all the Mary’s in our companies. When Mary comes to us, the first answer should be, “Yes, Mary – we can help you deploy a CRM solution. We’ve been investigating Cloud solutions for this type of need, and I think there are some very attractive options we can get you started with almost immediately and without massive capital outlays.” Even better, we approached Mary before she approached us, and told her about the potential for a low cost, relatively easy way to boost sales with a CRM capability.

Leverage the Cloud for Things You Can’t Do

I’ve been participating in a series of CIO Forums across the US, sponsored by Microsoft Windows Azure. It’s been a fascinating experience!  Much of the discussion in our panel Q&A’s has been around the challenge of moving legacy systems to the Cloud. While this might be an interesting cost reduction play, the best cases I’m seeing out there are about using the Cloud for things you can’t easily do today (such as helping Mary lift sales with a Cloud-based CRM!) And that is where I believe the path to IT renewal can begin, or, for those who are already on that path, can be accelerated. More in the next post in this series.

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

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.

An Account Teaming Approach to Relationship Management

I’ve found myself re-immersed in the Relationship Management (RM) domain lately.  I’m working on a significant RM development program with one current client, and helping another client fine tune their IT Operating Model.

With the first client, I got involved in a benchmarking exercise, going back to two former clients where I had led extensive RM training a few years back.  The purpose of the benchmarking was to find out how their RM approach had evolved, what was working well, and where they still had challenges.  In both cases, the clients had converged on an Account Management Teaming approach – essentially, a set of business unit-facing account teams comprising a very senior Relationship Manager (rarely called that, by the way), a Solutions Manager and an Enterprise Architect.

In the client where we are fine tuning the IT Operating Model, one such account team had formed fairly naturally.  Nobody told them to organize that way.  One of the RM’s met with a business architect and a solution manager and decided they needed to set time aside to meet and talk and strategize in order to present a cleaner, simpler face to the business client.  They wanted to be more deliberate and proactive in shaping business demand rather than simply respond to it.  They saw the formation of the account team as a sort of experiment.  They did not ask permission – just went ahead and tried it.  (I’d describe this as a fairly sophisticated client in an information intensive industry, with an exceptional quality of IT leadership and management.)

This Seems to be Working – Let’s Generalize It!

I met recently with the account team and other architects, RM’s and solution managers to talk about how to generalize the model and duplicate it for the other business units and their RM’s.  We analyzed what had changed as a result of the account team approach – both from the perspective of the individual IT roles, and from the business client’s perspective.  It was an impressive story with impressive results.

So, how to ‘codify’ the approach and generalize it?  The responses from the account team members were surprising and distressing on the one hand, yet obvious and comforting on the other.  Their counsel was, “Don’t try to codify this too much.  It won’t work!”  and, “Remember, we formed into a team because we wanted to, not because we were told to!”

Not So Fast, Tonto!

The business-IT interface is an extremely complex space.  The Account Teaming approach works because it is organic, and was emergent.  It works because the team members have mutual trust and respect.  It is the role of the team that is important and brings the magic, not the roles of the team members.  They talk about “having each others backs covered.”  About the fact that the client executives know that they can talk to any of the team and reach the whole team at the same time.  About the fact that any business-IT conversation quickly and automatically gains the perspectives of enterprise architecture, solution delivery and relationship management.  The business executives don’t need to be concerned about who to call for what.  Nor do they have to sit down with five IT folk to get anything done!

The Power of Self-Organization

Ralph D. Stacey, in his great book, “The Chaos Frontier” defines Self-Organization as:

A process in which the components of a system in effect spontaneously communicate with each other and abruptly cooperate in coordinated and concerted common behavior.”

I believe that viewing organizational spaces such as the business-IT interface as a complex system, operating at the ‘edge of chaos’ (scientifically speaking) reveals the insights that:

1. Variety, randomness, paradox, information, and interconnection are sources of creativity.
2. Organization is a natural, spontaneous act – to force otherwise is not sustainable or effective.
3. Systems have a capacity to self-organize to great effect – given the opportunity to do so.

The danger feared by the Account Team was that as an organizational consultant, I would take the model and create organizational charters, role descriptions, competency models, and so on, and in so doing squeeze the life out of the account team concept.  And I use the word “life” deliberately.  Everything we know about complex emergent behavior tells us that for life forms such as this type of account team to really work, they have to behave like living organisms – with porous boundaries, guided by a common sense of mission and purpose, a ‘genetic code’ if you will, not sealed off from their world by hard boundaries and deterministic rules.

Image courtesy of The Savvy CIO

For IT Leaders, the Cloud Changes Everything!

For me, the big question is, what does the migration to Cloud Computing mean for today’s IT organization?  What structural changes are necessary to successfully leverage Cloud Computing capabilities?  How quickly should you be moving IT services to the Cloud?  How does the Cloud impact the IT Service Portfolio and the capabilities needed to deliver those services?  What are the implications for IT competencies?  How does business-IT governance change in a Cloud Computing world?

I think these are important questions whose answers are not yet totally clear.  As I reflect back on the shift from mainframe to client-server computing, many IT organizations were less than stellar at anticipating needed changes.  As a result, they experienced more bumps and potholes in that journey than was necessary.  For example, for all that had been learned about back-up and recovery in a mainframe world, the onset of client-server computing created gaping holes in the IT organization’s ability to cope with data protection and loss at the Personal Computer level.  The same was true for the evolution from client-server to the web – many of the controls put in place for client-server computing were ineffective (and some even counter-productive) as more work moved to the Internet.

Which Aspects of Cloud Computing Could Bite Your IT Organization?

In the next few posts I will explore some of IT organizational implications of Cloud Computing.  Aspects we will examine will include:

• Mobility implications – both for the business user and the IT professional charged with enabling that user.
• The distinctions between Infrastructure as a Service, Applications as a Service, Platform as a Service, Development as a Service and Business Process Services and how these impact IT organizations.
• The distinctions between Public, Private and Community Clouds and their implications for IT.
• Accounting implications, including funding and budgeting.
• Implications for Business-IT Governance.
• Security and Privacy.
• Implications for the work teams and flow of work involved in requirements analysis to solutioning.
• Impact on Enterprise Architecture.
• Implications for IT Services and Service Management.

Please weigh in – let us know your experiences, issues and concerns about the shift to the Cloud.  Do you agree with my assessment that this shift is inevitable?  How fast do you see it happening?  What does it mean for you personally, and for your career?

IT Reality 1.0

Reality 1.0 holds that IT must be managed.  It is difficult and complex – fraught with crucial technical details.  Mastering these details requires teams of technical experts, following rigorous processes and procedures.  Issues that mere mortals don’t often think about – things such as back up and recovery, security and privacy, regulatory compliance, business continuity – must be planned for and managed by IT specialists who have been properly trained and certified in these disciplines.

Reality 1.0 holds that IT should be owned, and certainly, must be controlled internally.  It holds that business users must be protected – both from themselves and from the raft of vendors and consultants, all trying to sell them stuff that could cost them money (at the very least) and might even get them in trouble.

Reality 1.0 holds that qualified IT resources are scarce and costly.  They take time to develop and cannot be ramped up or down quickly.  Therefore, long term planning and concerns about scaling are constantly on the IT professional’s mind.

Reality 1.0 is obsessed with risk avoidance.  Constantly aware of many of the horror stories that are told around the IT campfires (and sometimes involved in either perpetrating or recovering from such horrors), IT leaders work to prevent the many risks associated with IT.

Given resource and risk issues with IT, Reality 1.0 deploys sophisticated tools and governance processes to filter the many opportunities for IT-enablement and weed out all but the key initiatives that justify the the investment and risks.

Reality 1.0 perceives the world of IT as relatively closed and proprietary.  Therefore, it is obsessed with IT architectures and standards – with figuring out how to weave together point solutions into capabilities that meet enterprise needs.

Reality 1.0 is about large projects and solutions – multi-month, sometimes multi-year initiatives designed to last for years.

Reality 1.0 separates the world into ‘development’ and ‘production.’  The move from one to the other is like the move through an airlock – from a dangerous and polluted free-for-all into the safe, secure and sterile data center.

IT Reality 2.0

Reality 2.0, by contrast, holds that IT is simple, ubiquitous and inherently safe.  Almost anyone can be creative and productive with IT – all they need is an Internet connection and a device equipped with a web browser.  If the user knows nothing, they can simply leverage what is already on the web – and learn as they do so.  If they know a little, and are adventurous, they can do much more than passively leverage what is already there – they can “mash up” new capabilities from existing ones to solve new problems.  They can learn as they go, become even more adventurous and creative – perhaps even commercialize what they have created.  Over time they will become even more skilled – creating more sophisticated solutions – or leveraging ‘crowdsourcing‘ to engage others to help them create the solutions they need.

Reality 2.0 does not care about IT ownership or control – they care about results.

Reality 2.0 sees the world as a sea of opportunities and solutions to be tried and exploited.

Reality 2.0 sees IT resources as ubiquitous – found with a click of the mouse, engaged with a few more clicks, and paid only when they’ve delivered.  Resources are paid for as they are needed – no long term commitments or overhead payments to worry about or justify.

Reality 2.0 is about risk management – moving incrementally and organically, managing risks as they are recognized.

Reality 2.0 has no time for bureaucratic processes such as governance committees and cost justification rigmaroles.  It sees any opportunity as worthy of a quick experiment to see if its real – it believes that in the time it takes to create a business case or wait for the next governance committee meeting, the idea can be tested and validated or eliminated – let the proof of the pudding be in the eating, so to speak, not in the political machinations of investment review bodies.

Reality 2.0 perceives the world of IT as essentially open.  Things in its world naturally fit together.  Therefore, things can be built in small incremental steps – evolving in the light of experience and changing needs.  Things can also be built as discrete point solutions – and yet still can be fitted together if need be.

Reality 2.0 is about small projects and solutions – created in days or weeks and designed for just as long as they are effective.

Reality 2.0 sees development and production as living side-by-side in some virtual place in the sky – while I’m working on its creation, it’s in development.  Once it’s working, I declare it ‘production’ and it is so.

The Best of Times, The Worst of Times…

If IT Reality 1.0 accurately reflected today’s world – as it did for most of the last 50 years or so – life would be ok for IT leaders.  Both they and their business consumers would understand their respective roles and would work together for the mutual good.  If Reality 2.0 accurately reflected the world – as it might do in the next 50 years or so, life would ok for IT leaders.  While their roles and those of their business consumers would be very different from those typical today, again they’d be on common ground.

The really big challenge today is that the reality today is neither 1.0 or 2.0 – it is in transition.  And in the immortal words of William Gibson, “The future is already here, it’s just unevenly distributed.”  This ‘uneven distribution’ of IT Realities 1.0 and 2.0 is going to represent both a curse and an opportunity to IT leaders.  For the progressives, it’s a wonderful opportunity to shift IT into overdrive.  For the laggards, I fear that it’s going to make their lives more and more miserable!

Do you live in this dichotomy?  How quickly is reality 1.0 being replaced by reality 2.0?  Are these realities coexisting?  What are you doing to accelerate or impede the shift?

In my next post I will  drill down and suggest ways to use Web 2.0 technologies and approaches to increase innovativeness and business success, but for now I want to examine the Core/Edge distinction in order to focus us clearly on Edge capabilities, where innovation tends to surface – without being encumbered by the Core.

“Core” and “Edge” Capabilities

Identifying the best ways to leverage collaborative technologies for innovation require an appreciation of the distinction between “Core” and “Edge” business capabilities.  The notions of “Core” and “Edge” I think were first articulated in June 2005 by John Hagel III, a former McKinsey consultant, and John Seely Brown, former chief scientist of Xerox in a Wharton Summary interview titled “Can Your Firm Develop a Sustainable Edge?“  In that interview, Hagel noted:

The… edge… has to do with the notion of competitive advantage, but it also has to do with the view that the ability to develop capabilities involves operating at the edge. Of course, “edge” has multiple meanings as well. It means the edge of the enterprise, the edge of business processes, geographic edges in terms of emerging economies, demographic edges in terms of younger generations coming in with different mindsets – it’s a whole set of edges that create the opportunity for accelerating capability building.”

Seely Brown noted in the same interview:

… being able to listen deeply and participate on the edge, you can pick up things before anybody else picks them up, and you can use that to accelerate your own capability building… This puts a new spin on why distributed collaboration around the world might be critical in creating this sustainable edge.”

My colleagues and I picked up this theme in our multi-company research at nGenera and I covered it in some depth starting in March 2008 with my “Surfing and IT Innovation” post, followed in July 2008 with my “Edginess and IT Innovation” post.

The reason this Core/Edge distinction is so important for IT professionals in the corporate environment is that the Core exerts enormous gravitational pull – innovation activities such as business experiments at the edge tend to get pulled into the core where standards and rigid processes rule.  The Core typically consumes 70% to 90% of IT resources, starving edge activities of the resources and focus they need to flourish.

Requirements of Core Capabilities

Core Capabilities exist to support exploitation of existing business opportunities.  As such they tend to be ‘locked down’, complex and hard to change – in fact, they are designed to prevent ‘bad change.’  Core processes are intended to be highly stable and predictable, typically built on proprietary and relatively fixed architectures.

Requirements of Edge Capabilities

By contrast, Edge Capabilities exist to stimulate and support the exploration of new business opportunities. As such they must be open, agile, transparent and adaptive.  While Core capabilities must ‘prevent bad change’, Edge capabilities are designed to stimulate ‘good change.’  They leverage open, emergent architecture and open sourcing. This, of course, is the realm of Web 2.0 – social media, open source, open innovation, cloud computing, etc.

Balancing Core and Edge Capabilities

The table below further highlights the differences between Core and Edge capabilities and shows example of each type.  My point here is that most IT organizations have many years of experience in perfecting Core capabilities but have relatively little experience with Edge capabilities.  The IT leaders’ natural preference is to control rather than facilitate, to direct rather than stimulate.

In Part 3 of this series, we will look at a generic Design Thinking process and see how each step can be enabled by Web 2.0 “Edge” capabilities.

Image courtesy of Larval Subjects

• Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools.
• Governance – how we make and sustain important decisions about IT.
• Sourcing – how we select and manage the sourcing of our IT products and services.
• Services – our portfolio of IT products and services.
• Measurement – how we measure and monitor our performance.
• Organization – how we structure and organize our IT capabilities.

In Part 3 we looked at how Web 2.0 approaches could transform the way IT processes are defined and managed.  I now want to look at IT governance, and the implications of Web 2.0 for this ever important aspect of IT operating models.  Due to the depth of this topic, I will discuss the facets and domains of IT governance in this post, then deal with the Web 2.0 implications in a subsequent post.

Facets of IT Governance

There are many definitions and descriptions of IT Governance, and frameworks such as COBIT that attempt to bring ‘best practices and processes’ to the domain.   The two definitions I have landed on in my years of research and consulting in this space, are:

1. A framework of decision rights and accountabilities to encourage desired behavior to realize maximum value from information technology.
2. Aligning IT decision-making with enterprise governance and business unit objectives through an interrelated set of processes, policies and decision-making structures with clear goals, roles and functions, sponsored by the CEO, with clear consequences for compliance or lack thereof.

I like the first definition for its simplicity, getting to the heart of both ‘decision rights’ and ‘accountabilities’ through the lens of ‘behaviors’ all focused on maximizing the value realized through IT.  This is pragmatic – you can define the types of behaviors you would like to see (e.g., business takes ownership for the business outcomes to be enabled by IT initiatives), or behaviors you are seeing but would like to eliminate (e.g., people see IT as a ‘free’ resource, and therefore use it with little or no regard as to its cost or value.)

I like the second definition in contrast for its recognition that IT governance is an extension of enterprise governance, and for its reference to ‘processes’, ‘policies’, and ‘decision-making structures.’  I also like the emphasis on CEO sponsorship and consequence management – i.e., governance with ‘teeth’.

I’ve come to view IT governance as a means to achieve balance between the competing forces of innovation versus standardization and business unit autonomy versus collaboration.  I also see IT governance as a way to manage IT investments and assets as a  resource that is shared by the enterprise.  Finally, good IT governance provides a “transmission chain” for the highest level enterprise strategy, from senior executives on down through the organization. As such, IT governance is a critical alignment mechanism.

IT Governance Domains

Peter Weill and Jeanne W. Ross, in their excellent book, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, call out five decision domains of IT governance:

• IT Principles (strategic choices between competing perspectives.  For example, ‘We will optimize IT investments for the enterprise rather than for individual business units.’)
• IT Architecture (“the organizing logic for data, applications, and infrastructure captured in a set of policies, relationships and technical choices.”)
• IT Infrastructure (“Centrally coordinated, shared IT services that provide the foundation for the enterprise’s IT capability.”)
• IT Investments and Prioritization (“How much and where to invest in IT, including project approvals and justification techniques.”)
• Business Application Needs (“Specifying the business need for purchased or internally developed IT applications.”)

While these domains may each be handled by different processes, policies and decision-making structures, all of these domains must be covered in ways that support a coherent strategy and set of beliefs about IT.

IT Governance, In Other Words…

IT governance deals with how the business makes decisions about the deployment and delivery of IT.  When sound IT Governance is in place, senior executives not only know their organization’s IT plans and policies, they also know how they are made.  IT governance is about the specification of decision rights and responsibilities required to ensure effective and efficient use of IT.  As such, it deals with organizational power and influence, and therefore  must be approached with care!

IT Governance 2.0

The implications of Web 2.0 on IT Governance are dramatic and far reaching!  On the one hand, with ‘transparency’ a watchword of good governance, 2.0 capabilities offer several important mechanisms to bring transparency both to the design of effective IT governance processes and structures, and to their ongoing execution and management.  On the other hand, dealing with decision rights and accountabilities in the types of highly diverse, distributed and fluid information environment enabled by social networking tools can become quite complex.  We will dig deeper into the implications of Web 2.0 for IT governance in a subsequent post.

Image courtesy of The ERM Current

“We Support the Future!”

This is not a new problem.  Many years ago I was involved with an organization known as the Software Maintenance Association (SMA).  Prior to the so-called Y2k thing a decade ago, the SMA struggled to garner the respect it deserved.  As Y2k loomed, the SMA became a valuable focal point for software remediation practices and tools.  Post Y2k, I have not kept up with the fortunes of the SMA, but I will always remember their slogan – “We Support the Future!” That always struck me as a fresh and compelling way to think about the disciplines and activities associated with keeping software doing what it needs to do.  It also reminds me that much of today’s software practices are focused on the here and now, with relatively little regard for future sustainability.

How to Make Software Sustainable?

Given the complexity behind the issue and in an attempt to increase the value of this blog to its readers, I’m going to approach the topic of software sustainability as an experiment in collaboration.  I will create a series of posts over the next month or so, incorporating as much dialog and discussion as I can surface.  I welcome, as ever, any and all commentary on this blog.  But I will also leverage other means (e.g., social media, personal network) to discover the state of the art and surface leading or promising practices.

I am hopeful that we can generate useful commentary, experiences and shed some helpful light on the topic.  As a starting point, I propose three major categories or ‘lenses’ through which to explore sustainable software practices:

1. Technical
2. People
3. Financial

To help get things kicked off, here’s my initial thinking on these issues.

Sustainable Technical Practices

There is no doubt in my mind that Enterprise Architecture is key here.   My colleague and friend Roy Youngman describes this appropriately as “a means to reduce the cost of change.”

There’s been some very good news here over the last few years.  Standards have emerged that while not being panaceas, can help in bringing a more ‘architected’ approach to software – more ‘plug and play’ as it were.  Service Oriented Architecture (SOA) and derivatives such as Web Oriented Architecture (WOA) have shown significant benefits.  Unfortunately, much of the evidence is anecdotal due to a lack of good software management practices – in particular, good metrics, uniform terminology, enlightened costing models (e.g., activity based costing) and good baseline data.

Ironically, the lack of good  data exacerbates the challenge of building a business case sufficiently robust to drive real change in software practices.  As such, in spite of their promise, these standards are still not commonplace, their adoption impeded by forces such as organizational inertia, lack of an architecture infrastructure with sufficient ‘teeth’ to shape behaviors, and by all the packaged software that organizations increasingly rely on.  These bring their own architectural idiosyncrasies (or lack of architecture!), leading many organizations to have effectively outsourced their architecture – often unwittingly, and almost always, unwisely!

There is other good news in contemporary development methods such as Agile and its Scrum derivative.  Being based on iterative refinement, these inherently create and, to a degree, enforce sustainability into their products – each iteration must, in some respects, ‘anticipate the next iteration.’  Furthermore, Scrum roles such as Product Owner, if well implemented and connected with broader Product Management roles (responsible for total lifecycle costs and value) can bring a great deal to sustainability.

Sustainable People Practices

The challenge here, especially with agile development models, is that the teams run at a relentless pace.  The question is, can people sustain this pace day in, day out?  Does Scrum become a euphemism for ‘heroic efforts’ that leave people sick or with broken families?

I believe the last couple of recessionary years have left IT staff’s depleted, less than fully engaged and with deteriorated organizational talent management practices.  While the pace of technological change continues to increase, most organizations have actually decreased their investment in training and competency development over the last couple of years.

Sustainable Funding

I’ve joked before that a consultant can often score a cheap point by telling a CIO, “Your IT funding model is broken!”  It always is!  Funding models typically evolve over many years, without sufficient consideration as to the desired behaviors they should lead towards.  On top of this built-in dysfunctionality, IT project teams, by way of either reducing “sticker shock” or simply because they’ve not done the analysis, don’t plan and manage in terms of full lifecycle costs.

Let the Sustainable Software Discussion Begin!

So, with those few initial thoughts:

• How do you see the issues of sustainable software at your organization?
• What priority does software sustainability have in your organization today?
• What priority should it have?
• What successes have you had addressing sustainability of software?

Please comment here, or Tweet me, email me, or whatever!  Let’s figure this out!

Image courtesy of BLDG Blog

“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