Tag Archives: Architecture

IT Organization Circa 2017 – 5 Year Countdown (Part 2)


countdownIn Part 1 of this post I pointed out why I’d named this blog “IT Organization Circa 2017″ and why I’d picked 2017. I then offered some musings about the nature and shape of the IT Organization Circa 2017.

I set this up by examining the major disruptive forces acting on the IT organization today:

The bottom line is that many IT organizations are at risk of being disintermediated – victims of the inextricable forces mentioned above.

“You cost too much and add too little value!”

is the familiar cry – but one that is more about the IT organization than it is about information technology.

The End of the IT Organization?

My view of the next five years is that in extreme cases, the IT organization as we know it will be gone – supplanted by a constantly shifting landscape of outsource providers, consultants, cloud solutions and “shadow quasi-IT groups” embedded in business units and taking care of local business needs. I can safely predict this because it’s already happened. In fact, when I started my IT career in 1970, working for International Computers Limited, (ICL) one of our major national accounts was British retailer Marks & Spencer. At that time, Marks & Spencer had no computers or IT department, even though they were highly computerized. Founder Michael Marks believed the firm should stick to what it knew – retailing – and hire experts to do the things it needed but did not know how to do. Consistent with that philosophy, ICL ran all Marks and Spencer’s computing. Nowadays, we call that “core competence.” As an aside, contrast that with another great British retailer and food manufacturer, J. Lyons & Co. who in the early 1950s had developed their own computer, the LEO, which eventually became part of my employer, ICL!

Already today, many companies around the globe have slashed the size of their IT organizations – some by 80-90%, taking advantage of global sourcing options and shifting the headache of running an IT shop to one or more outsourcing partners. There has, of course, been some backlash, and a small proportion of these outsourced IT shops bring their work back in house. In some cases, this is part of a long term strategy – pass your IT capabilities over to an outsourcer (or several) for a few years to have them “fix it” then bring those capabilities back in house. But even with the ebb and flow of the outsourcing movement, the trend is clear.  As companies become more networked and try to become more agile, they are less inclined to sustain large internal IT groups.

Similarly, the value proposition for cloud computing and the rapidly growing base of ‘software as a service’ is just too compelling, and the general satisfaction with internal IT capabilities too underwhelming. Why make huge capital investments in core systems, and carry the depreciation, maintenance and operational costs when I can ‘rent’ these and ‘pay by the drink’? Just as application packages have tended to supplant custom software development, software as a service is tending to supplant applications packages. As more computing moves to mobile, costly application packages become relatively inexpensive (or at least, value priced) “apps.” And the key issue with emerging computing models such as cloud and mobile is that they do not necessarily depend upon a permanent, in-house IT department.

The Ebb and Flow of Centralization and Decentralization

Organizational models tend to go through cycles of centralization and decentralization. There is always a tension inherent in finding the proper balance between the efficiency and scale of centralized, shared capability models and the responsiveness and customer-intimacy of decentralized models. This tension is never resolved – it is simply held in some sort of uncomfortable balance until the forces on one side outweigh the forces on the other side. This imbalance is often triggered by changing market conditions or by other disruptive forces such as new technologies.

The Mainframe Era – Centralization Rides High!

We’ve seen this through many cycles of technology shifts and their impact on IT organizational models. Back in the early days of the mainframe computer (early 1960s) virtually all IT professionals either worked for vendors/solution providers or worked in a centralized IT group.  (Back then it was typically called Data Processing.)

The Minicomputer Era – Departmental Computing Catches On!

With the advent of the minicomputer in the mid-1960′s, so-called “department computing” came of age, sometimes with the blessing of central IT groups, but often behind their backs.

Enter the Personal Computer – Departmental Computing Evolves into Decentralization of IT

As minicomputers gave way to personal computers and with IBM‘s launch of the IBM PC in the early 1980′s, the genie was further out of the bottle and the swing to what was euphemistically referred to as “distributed computing” was all but unstoppable. IT was becoming decentralized!

Inevitably, cracks in the distributed computing wall quickly appeared as users tackled issues such as mainframe connectivity and enterprise data management, and wrestled with the practical realities of back-up, security, integrity and privacy.

The Realities and Complexity of Enterprise Computing Surface – Centralization of IT Makes a Comeback – Sort Of!

By the early 1990′s the pendulum had begun to swing back to centralization. It seemed on the face of it that the old guard of the central IT group had returned in force.  But look under the covers, and what you see is not simply a return to the monolithic central IT group.  The new IT operating models had novel features such as:

  • Business-IT governance boards that moved ownership of prioritization and, in the best cases, value realization out to the business.
  • Business relationship managers bridging between the IT organization and business groups.
  • Business and Enterprise Architects focused on Business Operating Models and process management.
  • Sourcing and Vendor Management Groups.
  • Security and Privacy Groups reporting to senior business executives, embracing IT but not limited to it.

In other words, the centralized IT model of the early 1960′s had given way to a hybrid model that sought a more even-handed balance between local and global computing models. With the ascendance of cloud and mobile computing and the rise of global sourcing, I believe we are on our way to a new generation of computing model.

The Emerging IT Operating Model

I think it’s important to think of an IT Operating Model as an enterprise-wide construct – i.e., an IT organization is but one component. Many more IT functions are being distributed and dispersed – witness the so-called rise of Bring Your Own Device (BYOD). Here, functions that were performed by a central IT group are being performed by the business individual.  And this move towards ‘self-service’ and ‘business embedded’ functions will only expand with emerging technology. As such, we can think about IT Operating Model components as comprising centralized, decentralized and hybrid components. These might fall along the following lines:

Centralized Capabilities: Shared IT Services; Value Proposition = Standardization, Operational Excellence

  • Enterprise Architecture
  • Enterprise Shared Infrastructure
  • Enterprise Shared Solutions
  • Security and Privacy
  • Sourcing and Vendor Management

Decentralized Capabilities: Business-dedicated IT Services; Value Proposition = Customer Intimacy, Innovation)

  • Business Architecture
  • Local and Departmental Solutions
  • Business Analytics

Hybrid Capabilities: Networked IT Services, Communities of Practice; Value Proposition = Integration, Shared Learning

  • Business-IT governance/value realization boards
  • Innovation Centers
  • Organizational Development and Change Leadership Centers
  • Business Relationship and Sourcing Management
  • Data Visualization
  • Integration
  • Process Management

Why This Is Good News for the IT Profession

I will explore some of the implications of this shift for the IT profession in a future post, but by and large, given the many ways that I’ve seen IT professionals trapped in the past by their employers, I’d say the changes we are experiencing, while painful, will be beneficial at many levels.

 

Related articles

countdown5 IT Organization Circa 2017 – 5-Year-Countdown – Part 1

Enhanced by Zemanta
About these ads

Design Thinking and Emerging IT Roles


designthinking

This is the third and final part in a multi-part post inspired by Robert Pirsig’s masterwork, Zen and the Art of Motorcycle Maintenance.  In Part 1 (titled “Reflections on ‘Zen and the Art of Motorcycle Maintenance’ 38 Years Later “) I discussed the implications for IT professionals of Pirsig’s musings on ‘classic’ versus ‘romantic’ worldviews, and his struggle to resolve these.

In Part 2, (titled “Zen, Motorcycle Maintenance, Design Thinking and Information Technology”) I teed up my observation that this classic-romantic balanced approach is embodied in the “design thinking” movement, popularized by Tim Brown and Ideo and exemplified by companies as diverse as Apple, Proctor & Gamble, Herman Miller and GE.  I discussed why Design Thinking is becoming increasingly important to the IT profession.  Among the reasons for the rising importance of Design Thinking in IT:

  1. Thanks to the likes of SAP, Oracle, et al, and the growing base of cloud-based ‘applications as a service,’ most of the opportunities to improve or automate transactional business processes have been exploited.  Today, businesses are increasingly searching for product, service and business model innovation.
  2. As we accelerate the move from custom development to personal apps, reuse, and “mash-ups,” much more emphasis is placed on synthesis rather than analysis – leveraging widgets and components rather than coding solutions from scratch.

I will pick up in this final part where I closed Part 2, with a discussion of three roles that are key to instilling Design Thinking in an IT organization.

Key Roles for Design Thinking in IT

Achieving the classic-romantic balance in discovery and solutioning involves many IT roles, but there are three roles that I believe are key:

Roles – Not Necessarily Jobs!

Before we examine these roles and how they work together, I want to emphasize I am talking about roles, as opposed to jobs.   The distinction is important in that the notion of organizing around roles imparts flexibility and variety for a workforce, whereas jobs tend to constrain people in boundaries defined in job descriptions.  An individual typically will hold only one job, but may fill multiple roles.  For example, my job is Principal in a consulting firm.  In some engagements, I am the Engagement Lead.  In others, I might be a Subject Matter Expert.  In still others, I am the Client Relationship Officer.  Beyond engagements, I might be a Research Program Leader or a Research Associate.

Also, these roles are typically instantiated with all sorts of labels – rarely the label I’m using here.  For example, I’ve worked with Business Relationship Managers (BRM’s) who were called Business Partner Director, Account Manager, Client Relationship Manager, IT Business Partner, Business IT Partner, IT Demand and Account Manager, Client Engagement Director, and so on!  And the specific missions, visions and implementations of the BRM role has been as varied as their titles!

Nevertheless, let’s drill into these roles and how they relate to each other and to moving IT to more of a Design Thinking philosophy.

Business Relationship Manager

I’ve posted extensively on this role in the past – it’s the role that sits between the IT organization and its business clients.  As such, it both represents the business clients to IT, and IT to the business clients.  This role has surfaced over the last 10 years or so.  I don’t know what percentage of IT organizations have this role today, but as an indication, LinkedIn hosts 2 groups dedicated to the role.  One group – IT Business Relationship Management - currently boasts over 1,800 members.  The other group, Professional Business Relationship Managers currently has over 2,600 members!  (In the interests of full disclosure, I co-manage the latter group.)

As the bridge between the business and the IT organization(s), the BRM plays a key role in moving above and beyond the traditional “requirements analysis” to an approach to discovery and solutioning that is more:

  • collaborative
  • abductive
  • experimental
  • integrative
  • outside-in
  • human-centric
  • innovation-biased approach

As such, the BRM has to understand Design Thinking, and ensure that the qualities listed above are brought to the table and play together effectively and efficiently.  The BRM herself does not have to be expert in these qualities, but must be an effective “broker” ensuring that people with the needed competencies and incentives are at the table.  These competencies will often be found in the other two emerging roles – those of Enterprise Architect and Product Manager.

Enterprise Architect

As with BRM’s, Enterprise Architects (EA’s) come in all sorts of flavors with a variety of titles.  The major distinction I would make is with what are generally called IT Architects.  Enterprise Architects are clearly focused on the business, business models, major business processes, business-IT platforms and the ecosystem within which the business operates.  IT Architects, by contrast, are focused on the technologies, their standards and how they inter-operate.

Wikipedia defines Enterprise architecture (EA) as:

… the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.

Practitioners of EA call themselves enterprise architects. An enterprise architect is a person responsible for performing this complex analysis of business structure and processes and is often called upon to draw conclusions from the information collected. By producing this understanding, architects are attempting to address the goals of Enterprise Architecture: Effectiveness, Efficiency, Agility, and Durability.

As with BRM’s, the EA role has been growing in prominence over the last 10 years or so.  Typically, it is complementary to the more technical roles of IT Architect, Information Architect, and so on.  Also, as with BRM’s there is little that is ‘standardized’ about the EA role, and by many measures it is something of a stretch to use the term “profession” when talking about EA’s, in spite of the efforts of bodies such as The Open Group Architecture Framework (TOGAF®), and my old friend, John Zachman and his Zachman Framework for Enterprise Architectures.

Again, as with BRM’s, LinkedIn is home to an Enterprise Architecture Network, with an astounding 85,000+ members!  As an example of the passion exhibited by this group, a recent comment that stated, “EA is often left in IT because it can only handle tame problems” garnered 572 comments!

At its best, the EA helps bring to the business-IT discovery and solutioning table some of the competencies from my bulleted list above.

Product Manager

The third role in the triad that can help IT organizations introduce more Design Thinking into their activities is that of Product Manager.  This role is far more scarce in IT organizations than either BRM or EA.  It is, however, universal in product companies, including information technology product companies.  Wikipedia defines Product Management as:

…an organizational lifecycle function within a company dealing with the planning, forecasting, or marketing of a product or products at all stages of the product lifecycle.

The role consists of product development and product marketing, which are different (yet complementary) efforts, with the objective of maximizing sales revenues, market share, and profit margins. The product manager is often responsible for analyzing market conditions and defining features or functions of a product. The role of product management spans many activities from strategic to tactical and varies based on the organizational structure of the company.

While involved with the entire product lifecycle, the product management’s main focus is on driving new product development. According to the Product Development and Management Association (PDMA), superior and differentiated new products — ones that deliver unique benefits and superior value to the customer — is the number one driver of success and product profitability.

Of particular note, Wikipedia goes on to note that:

Product management often serves an inter-disciplinary role, bridging gaps within the company between teams of different expertise, most notably between engineering-oriented teams and commercially oriented teams. For example, product managers often translate business objectives set for a product by Marketing or Sales into engineering requirements. Conversely they may work to explain the capabilities and limitations of the finished product back to Marketing and Sales. (Emphasis added.)

The Design Thinking Triumvirate

So, the keys to getting more Design Thinking into Business-IT solutions lies in the triumvirate of Business Relationship Manager, Enterprise Architect and Product Manager, with the BRM as the broker and orchestrator of these roles.  There are, of course, other roles played – e.g., business analyst, project manager, program manager, and so on, but I wanted here to focus on those roles which are less common but in the ascendancy.

Graphic courtesy of Green Hat Group

Related articles
Enhanced by Zemanta

Reflections on “Zen and the Art of Motorcycle Maintenance” 38 Years Later – Part 1


(Note: This will be the first in a multi-part post).

I took the 25th Anniversary Edition of Zen and the Art of Motorcycle Maintenance (ZAMM), by Robert M. Pirsig, on a recent vacation – courtesy of my Kindle.  I think this was my 4th or 5th reading over the last 36 years or so!  When it was first published in 1974, I picked the book up several times with a view to buying it, usually in airport bookshops (I did a lot more travel back then!) But after flipping through a few pages, I’d put it back on the shelf.  Although I’d heard the positive buzz about the book, it just did not do it for me.  I think I eventually broke down (poor choice of words intentional – Pirsig had a mental breakdown, and poorly maintained motorcycles are prone to physical breakdown!) and bought the book in 1976.

ZAMM was among the few books I’ve ever read that changed my worldview and actually shaped my behaviors.  On the most recent reading, I had the added bonus of Pirsig’s clarifications on the original edition.  With the Kindle edition, I also had the ability to easily bookmark and make my own notes (and to see what other Kindle readers had highlighted).  This series of posts is a result of the latest reading, with the benefits of my bookmarks and highlights.

A Search for the Meaning of Quality

For those that have not read the book, Wikipedia describes ZAMM as follows:

The book describes, in first person, a 17-day journey on his motorcycle from Minnesota to California by the author (though he is not identified in the book) and his son Chris, joined for the first nine days by close friends John and Sylvia Sutherland. The trip is punctuated by numerous philosophical discussions, referred to as Chautauquas by the author, on topics including epistemology, ethical emotivism and the philosophy of science.

Many of these discussions are tied together by the story of the narrator’s own past self, who is referred to in the third person as Phaedrus (after Plato’s dialogue). Phaedrus, a teacher of creative and technical writing at a small college, became engrossed in the question of what defines good writing, and what in general defines good, or “quality”. His philosophical investigations eventually drove him insane, and he was subjected to electroconvulsive therapy which permanently changed his personality.

Towards the end of the book, Phaedrus’s personality begins to re-emerge and the narrator is reconciled with his past.”

Largely autobiographical, ZAMM is by no means great writing and certainly not a great story (though quite readable!)  If you’re looking for an exciting tale of a 17-day motorcycle odyssey, you will be disappointed – the trip is simply a back story to the author’s reflections on quality and philosophy.  Nor is ZAMM only for motorcycle buffs.  But if you’re interested in philosophy, or have struggled with the notion of quality, ZAMM provides a truly profound and illuminating read!

Classic vs. Romantic – Implications for IT Professionals

In ZAMM, among many other philosophical issues, Pirsig addresses the concepts of “classic” and “romantic” worldviews.  As a University Professor, it was his struggle to reconcile these competing perspectives that literally drove him insane.

Pirsig describes a classic approach as rational, analytical and ordered – one which attempts to be objective rather than subjective. He describes the romantic approach as focused on feelings, emotions, and sensations -  a view that is subjective and personal rather than objective.

From my experience from 40 years in IT, people who gravitate towards the IT profession tend towards a “classic” attitude to the world around them.  Meanwhile, extracting value from the use of IT demands an approach that balances the classic and romantic – what John Naisbitt, author of the #1 New York Times bestseller Megatrends referred to as “high tech/high touch.”

Given that so few of us are equally adept with both classic and romantic approaches, we have to ensure that both disciplines are brought to the table.  This can be achieved either through exceptional talent that naturally brings this balance (rare indeed!) or more typically through cross-functional (or more importantly, cross-discipline) teams.  This is, I believe, why roles such as business relationship manager are so crucial to the business-IT interface.  This role, in its own way, emphasizes the romantic view, and represents an important counterbalance to the classic disciplines needed to run and maintain computer systems.  I think this romantic bias common to business relationship managers also sheds light on why people in this role often feel like outsiders in their own IT organizations.

ZAMM and ‘Design Thinking’

I’d also observe that this classic-romantic balanced approach is embodied in the “design thinking” movement, popularized by Tim Brown and Ideo and exemplified by companies as diverse as Apple, Proctor & Gamble, Herman Miller and GE.

I will pick up the connections between ZAMM and Design Thinking in a subsequent post.

Enhanced by Zemanta

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

Account Teams and Business-IT Relationship Management


I’ve posted quite frequently on this blog about the role of the Business-IT Relationship Manager. It’s a key role – crucial, in fact, at mid-levels of Business-IT maturity.  It’s a role that typically does not work well at lower maturity, yet is essential to reaching higher maturity. It’s also a role that is hard to get right!  But went you get it right, it can contribute significantly to business value realization from IT assets and investments.

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

Enhanced by Zemanta

IT Organizational Implications of Cloud Computing


First off, let me make myself clear.  I firmly believe that Cloud Computing, in its various forms, is real, absolutely inevitable and will completely revolutionize the form and role of the IT Organization.  Some readers will look at that sentence and laugh – it’s like saying “day will pass into night.”  Obvious, beyond dispute, devoid of insight.  Others will also laugh at my opening proclamation – only in their case, because my assertion is completely ridiculous to them – beyond belief.  Of course, to many businesses, especially smaller and medium sized, Cloud Computing is already real, and has been for some time.  So, feel free to debate me (comments and opposing views highly welcome!) but I will stick with my beliefs on this.

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?

Enhanced by Zemanta

IT Leadership – Caught between Two Realities?


It’s always been tough being an IT leader.  The “Career Is Over” distortion of the CIO acronym is humorous because of the real world challenges associated with the CIO job.  I think that today is an especially challenging time for IT leaders.  I say that because these jobs are typically caught somewhere between two very different realities – realities we might refer to as “1.0″ and “2.0″.

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?

Image courtesy of Rumple at Flickr

Reblog this post [with Zemanta]

Design Thinking 2.0: Enabling Innovation with Web 2.0 – Part 2


In my first post in this series, “Design Thinking 2.0: How Web 2.0 Might Foster and Enable an Innovation Revolution” I summarized the concepts of Design Thinking and raised the question of how Web 2.0 might enable increased innovation.  (For an interesting perspective on Design Thinking by Business Week’s Bruce Nussbaum, see his excellent essay based on his 2007 speech to the Royal College of Art in London.)

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

Reblog this post [with Zemanta]

Exploring an IT Operating Model for Enterprise 2.0 – Part 4: IT Governance


In Part 1 of this series, I suggested that the implications of Enterprise 2.0 for the IT organization are dramatic.  I also suggested that the ways of designing and executing an IT Operating Model in a Web 2.0 context are quite different from traditional approaches.  In Part 2, I outlined the major elements of an IT Operating Model as being:

  • 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

Reblog this post [with Zemanta]

The Challenge of Sustainable Software


Just about everyone has become attuned over the last few years to the concept of sustainability.  Except, it seems, when it comes to software practices.  In most IT environments, by far the largest chunk of costs associated with a given piece of software, surface after it is initially delivered.  That is true of purchased packages, as well as for custom code.  And yet most organizations don’t properly budget for the total lifecycle costs for a piece of software.  More importantly, neither do they plan and build software for sustainability.  And very few actually plan and budget for the costs of decommissioning a system that is no longer sustainable (either technically or economically) or is no longer needed – until that decommissioning is long overdue!

“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

Reblog this post [with Zemanta]