Charles A. Araujo, Jr.

Creating the "Wise" IT Organization

I was recently contemplating the nature of wisdom and what it really meant.  Was it something that had relevance to an organization? Could you create a "wise" IT organization?  And if so, what did that mean?

I think wisdom really has three elements:

• Knowing what is right
• Knowing how to apply that knowledge to the situation (what's right for me)
• Knowing when and how to take action on that knowledge (and when not to)

Isn't that what wisdom really is - applied knowledge for the greater good?  But does that have meaning to an IT organization as a whole?  I think it does.

In ITIL v3, this is actually addressed somewhat in the context of a Service Knowledge Management Systems (SKMS). Within it, it lays out a structure of Data-to-Information-to-Knowledge-to-Wisdom.  It basically describes the process in which discrete pieces of data are provided context to become information, which is then analyzed and associated to become knowledge.  Wisdom, then is the judgment and discernment to apply that knowledge in a meaningful way.

I think that this is the essence of organizational wisdom and frankly, a missing element in most IT organizations.  Most IT organizations are awash in data - particularly the technical kind.  But what happens with that data?  The entire context of ITIL's SKMS is to lay out the need to do something more - to add context and analysis so that the data transcends into something useful and meaningful and actionable. 

I think that this is what it might mean to become a "wise" IT organization and I think it should be a stated goal of any IT leadership team. Every IT organization should strive to create a "wise" culture that seeks to do three things:

• To know what is right.  To know the needs of the customer. To understand the true goals and objectives for the organization. To truly understand their reason for being.
• Create Understanding and Knowledge.  To gather data and apply the context of customer needs.  To analyze it in the context of business impact and so convert that data into information and then knowledge.  To transform the relationship between the data and the customer to go from a disconnected, dissociative relationship to an intimate one that applies to everything IT does.
• Seize the Moment.  To leverage this knowledge and understanding and take the prudent action - or inaction - to meet the present and future needs of the business.  Through this knowledge, to seize opportunities that leverage technology in ways that may be new and innovative.  To see the coming changes in the business and create flexible, adaptable business approaches that enable the IT organization to react quickly to the changing business needs.

If you could create an IT organization that operated like this - holistically and baked into its culture - would you call it a "wise" IT organization?  Whatever you'd call it, it would be a highly effective organization that was driven and bound by a "higher purpose." It would be an organization that wasn't merely providing technology or even IT services, but one that was fully connected with its customer and able to provide true, lasting and meaningful value through its application of knowledge for the greater good of the business. That sounds like an IT organization I'd love to be a part of.

Roadblocks to Innovation: Knowing What Your Customers Want

Ok, so this isn't really about technology, but Malcolm Gladwell gave a talk at a TED conference in 2004 that talked about something that I think often perplexes IT leaders - understanding what your customer wants.

We know the basics.  We know that our customer needs us to deliver ERP and financial systems.  That we need to deliver and support an infrastructure to enable these, etc.  But when we have reached a level of maturity and are looking to take that next big step forward - to move beyond the stale strategic planning process and really begin to bring new, innovative ideas to the table - we are often stumped at the starting gates with the simple question - what does my customer really need and want?

It's a question we need to be able to answer if we are to cross the divide and become true IT innovators.  I know it's a stretch to make a connection between IT and spaghetti sauce (you'll see), but take a look and see if it doesn't stir up some ideas.  If nothing else, it's very entertaining.  Enjoy!

The Rise of the Lifeguard CIO (It's not what you think)

Fortune Magazine recently (well, November!) published an article entitled, "Meet Your New Leader."  It described an apparent transition that is underway in CEOs of large, publicly traded firms from the "Visionary", charismatic, autocratic CEO to a new form of leadership that the article likened to the make-up of a Lifeguard. 

But this isn't about racing to the rescue. Rather, the article pointed out some key characteristics of this new type of leader:

• Calm in the face of crisis
• Comfortable not knowing what's going to happen
• Ability to scan the horizon and anticipate coming shifts
• Ability to work with a team and with rules set by others

And while this article was about CEOs, I couldn't help but feel that it applied equally to CIOs as well. 

I largely "grew up" in the era of the technically-focused, autocratic CIO.  Vision and strategy would be set at some high up level and passed down to us minions to go implement.  It basically worked - but let's face it, technology was a lot simpler then.

The combination of the sheer business criticality of technology and customer visibility to it, coupled with exponentially increasing complexity makes this approach woefully outmoded and frankly, fraught with risk.  So, like the new vision of the CEO, the CIO of the future is going to have to have a very different approach to building and managing the technology landscape.

If you'll indulge my interpretation, I believe that the modern "lifeguard" CIO is going to have to look at their role very differently.  They will need to focus more on:

• Building adaptable and agile organizations - rather than architectures
• Identifying where technology may impact their business - rather than on how the business may impact their technology
• Integrating technology into business strategies - rather than aligning IT to business decisions
• Harnessing the creative innovation within their teams - rather than capturing only organizational efficiencies

Admitedly, most IT organizations are nowhere near this state of maturity - and in fact many of the "rather" statements are stepping stones along the maturity path.  Still, I think it's important that we always be mindful of where we are going so that we can constantly evaluate if we are on the right path. 

It seems clear to me that as technology architectures continue to increase in complexity, and while the impact of technology on the business becomes more and more mission critical, the demands on IT leadership are going to change and grow.  The leadership required will look a lot less like the "in command" General most common today and much more like the Lifeguard.  It's probably the only way that IT will finally get to where it needs to go.  So the question is, as you go through your career, which skills will you work at developing?  Sunblock anyone?

Note: You can read the article by clicking here.

Checklist for Change

A client recently sent me this article about the utilization of checklists as we were going through some discussions on the implementation of a new ITIL-derived change management process. 

What I love about it is that it has nothing to do with IT.  It's about operating rooms.  Yet the lessons still apply - and my client was wise enough to see the correlation.  At the end of the day, most of what we do, well, isn't surgery.  It can be complex and can be incredibly important and risky for the business, but most of the time it's not life or death.  So where we can find lessons from people or organizations who are playing where the stakes are that high, we should look at them carefully and ask ourselves how we might learn something from their challenges and solutions.

My client did just that.  If you read the article, though, there is an extremely important piece of information that is easy to miss.  The checklist is important - but the real value comes from verbally going through the checklist as a group.  It is this interactive and interrogative process that creates the true power of the checklist - and when that step is skipped, the checklist loses its effectiveness.

I think that this is a perfect corollary to the Change Advisory Board (CAB).  There has been a lot of push recently to this concept of a "Virtual CAB" - a change authority body that doesn't actually meet, but reviews and approves changes based on a review of the RFC by using some automation tool.  Don't get me wrong - I'm a fan of the "Virtual CAB" for minor, low-risk changes.  But I believe that their use is becoming too prevalent and organizations, in their zeal for automation, often miss the true point of the CAB - to discuss and evaluate the risk of the change with all stakeholders to ensure that the risk has been adequately quantified, mitigated and accepted.  It's tough to do that with a click of a button.

So perhaps there is a lesson to be learned here.  We should use a checklist to help the CAB ensure that risk has been mitigated and that RFC approval requirements have been met.  But to really make it effective, we must require that the CAB does it verbally.  Maybe by doing so, we will get that dialogue that supposed to occur and perhaps we will begin to get a more complete understanding of the true impact and risk of proposed changes.  And maybe, just maybe, the process will work a little bit better.

Read the article by clicking here and see how you think you might apply it yourself.

How to fix the innovation gap: A conversation with Judy Estrin

McKinsey has recently posted a video interview with Judy Estrin on the state of innovation and how companies need to be looking at driving greater innovation.  There are definite lessons to be learned for CIOs and IT organizations.  Check it out here.

Back in the Saddle...Again!

Well, I have no real excuse. Yes, I've been extremely busy, but In truth I just got out of the habit of writing. The funny thing is that I miss it. But with everything going on it was easy to just skip it.

The good news is that I've been busy.  It's been a wild six months and it has been rough on everyone.  I've been fortunate to be working on a number of exciting projects and am looking forward to a productive 2009.  But despite the fact that I've been busy and haven't taken the time to write anything down, it doesn't mean that there hasn't been a ton of stuff swirling around in my head. 

Well, we're coming up on a new year and it's time I got back to it. So here we go.  My goal is to get back to this with some regularity - I find that it really helps keep me focused and centered.  I've also been giving a lot of thought lately to what it really takes to move an IT organization.  A couple of my recent projects have been fascinating studies on the role of culture in an IT organization and has crystallized for me how much of what we do is really about people more than anything else. 

I've also become much more focused on the role of innovation in IT.  I've written in the past about subjects that flirt at the edges of this concept, but I hope to spend much more time exploring this subject in the next few months.  I think that it's easy to fall into the process and efficiency trap and am very interested in how we connect to the other side of the value equation much more rapidly.

So in case anyone is still out there, stay tuned.  Some good stuff (hopefully!) is coming!

The Fuss and Hype over CMDBs (aka "myCMDB")

We may have finally reached the pinnacle of CMDB hype with Managed Objects' release of their new product, myCMDB.  While I have been somewhat of a fan of Managed Objects, this one just has me completely baffled.  The press release hype is talking about bringing 'Web 2.0' to the CMDB.  Huh?

It seems to me that this is indicative of a general trend to make the CMDB so much more than it was ever meant to be...and in so doing make it more and more difficult to actually make it work.  Managed Objects is certainly not alone.  It seems as though there is a virtual land rush out there to see who can cram the most different types of data into the CMDB.

Call me a simpleton, but here's my take on effective CMDB implementations:

1. Keep It Simple - CMDBs (and really the Configuration Management System (CMS) - so we can avoid this whole discussion of one really big CMDB!) should be a relational representation of the core and critical assets that IT utilizes to deliver services.  Each organization needs to determine how deep that needs to go to be effective, but there is a definite balance point that must be found.  The more detailed the data, the harder it will be to keep it accurate.  So, the key point is to get the level of detail just "good enough."  IT people are sometimes their own worst enemy here - once we get a hold of this, we want to put everything under the sun in this wonderful, magical database.  Remember that we can provide access to additional detail and related information through the federation model, but when we are talking about what should be considered a CI there must be relentless restraint to keep the data model as simple as possible while still delivering data relevant to the delivery of service - just good enough.
2. Relationship Trumps Granularity - I always find it fascinating that so much effort is put into defining CIs to an excruciating level of detail, but little effort is put into mapping the relationships between CIs.  The truth is that it is in understanding the relationships that the true value of a CMDB/CMS will be found.  I believe that a CMDB/CMS that defines CIs at only a very, very high level, but maps their relationships effectively will provide significantly more value to an organization than one that contains infinite levels of detail about each CI and its various changes in state over its useful lifetime, but which cannot describe the relationship between each CI and others in the delivery of service.  Get this one right and everything else will fall into place.
3. Process is Still Key - ITIL is all about process (well, v2 anyway).  But when it comes to the CMDB/CMS, it seems that we throw process out the window.  Yes, I'm a big believer in discovery tools and application mapping applications.  But when it comes to maintaining the CMDB, nothing will take the place of a rigorous process.  Anywhere that there is a change to a CI, process should dictate how the CI data is updated in the CMDB.  This should be a key process activity tied to Change and Release Management.  It should also be incorporated into the Standard Change process that might be executed as a function of Incident Management.  The key point, though, is that if your CMDB is falling out of sync, it's a process failure.  Can tools help?  Sure, but nothing can take the place of a well executed, well managed process.

In the end, IT and the many wonderful ITSM vendors must resist the temptation to turn the CMDB/CMS into something that is delivered in and for itself.  It's not.  The CMDB is nothing more than a tool that provides appropriate and relevant data during the execution of a process, in the delivery of a service so that those responsible for the execution and delivery can do so effectively and efficiently.  A well implemented CMDB/CMS is one that becomes virtually transparent.  The data you need is available when and where you need it to get the job done.  If you're having to interact with your CMDB data directly - "Web 2.0" or not - well, you're kind of missing the point.

Changing Perspectives: Pena Pachamama, The Upside Down Map and the Meaning of ITIL

I spent Memorial Day weekend in San Francisco and got some much needed mental rest.  Over the course of the weekend, I had a couple of experiences that made me think about the meaning of ITIL, but it might surprise you what they were.

First, I stumbled into a fair trade shop in Healdsburg and came across a map with the fun title, "What's up? South!"  An image is below.  It was simply a map of the world printed "upside down" but with the name of each country, ocean, etc. printed "correctly."  The result is an entirely new view of the world.  If you step back and look at this with "fresh" eyes and don't let your mind automatically flip it around for you, you will realize how an arbitrary decision (who decided that north was "up"?) can inform our perspective to the point that we don't challenge it.  I must have spent 10 minutes just taking it in.

Later in the weekend, we were wandering down (or was it up?) to North Beach for some good Italian and rather than cutting over on Green as we had intended, we continued down Powell....and stumbled across this little restaurant called Pena Pachamama - an amazing Bolivian restaurant in the middle of Little Italy.  They had a Bolivian band playing which was followed by a Middle Eastern band - complete with belly dancers! 

It was quite an experience.  There were a number of locals who were obviously of Bolivian descent and they were interacting and dancing traditional dances to the band.  My wife and I felt like we had almost crashed a family party.  What I found most interesting was that while there were a number of similarities to my Mexican culture, there were also some very strong differences.  It was an experience that opened my eyes to a way of life that was both familiar and unfamiliar and challenged my perspective of what I would find in "Little Italy."

So what does all of this have to do with ITIL?  Well, maybe I'm turning into too much of an ITIL-geek these days, but these two experiences exemplify two of the greatest challenges that we encounter while trying to adopt ITIL within an IT organization:

• Recognizing that it is less that what we are doing is new and more that we are challenged to look at what we do and who we are in a different and new way
• Understanding that while all IT organizations come from a similar place, every organization has its own unique cultural elements that must be understood and accounted for in order to make an ITIL adoption successful

ITIL IS NOT NEW
One of the greatest challenges that we have to overcome is the recognition that, for the most part, ITIL is not new.  Most IT organizations are already doing large parts of ITIL in some way - you almost have to if you're going to function as an IT organization.  But like the map, ITIL is about changing how you look at what is already there and challenging some of the preconceived notions of how IT should operate.  Yet, when an organization embarks on an ITIL adoption effort, what's the first thing that they start with?  Process development.  There is always this significant effort involved with tearing everything down and "developing the new XXX process."

In reality, however, I have typically found that most organizations have a lot of the building blocks already in place.  It doesn't necessarily require that everything be thrown out.  What is really needed is a deliberate review of what's there, what's working and what isn't - and the conceptualization of the behaviors that will drive change.   It's all about organizational change - and that means changing perspectives and changing the assumed way of doing things so that new, more effective and efficient ways of operating can be envisioned.

THE CULTURAL QUOTIENT
Culture is a powerful thing.  Even when cultures come from a similar history and share many common elements small, subtle differences can have a profound effect.  My brief experience with Bolivian culture, contrasted with my Mexican upbringing brought that into sharp relief.  And so it goes with IT organizations.  Over the years, I have probably been on the "inside" of 30-40 IT organizations and no two are ever alike.  Sure, almost all IT organizations operate using a lot of the same elements.  There are only so many ways to structure an organization and most IT groups are responsible for broadly the same types of services, but the subtleties of how those services are delivered and how interactions take place between management and staff (among other elements of culture) make all the difference. 

So remembering that adopting ITIL is really about driving cultural and organizational change, you must understand the cultural nuances of your organization before you can set out to change it.  That's why an initial, singular focus on "process development" or any other type of process-focused work is often misguided.  The focus must always be on understanding and quantifying those outcomes that will support the goals of the business and then undertaking those tasks that will change operating behaviors in a way that will result in the desired outcomes.  Will the redevelopment of processes be required?  Probably, but as those process changes are rolled out, it must be done in the context of the unique and subtle elements of the organizational culture. 

That's why when it comes to ITIL, one size does not fit all.  Any attempt to adopt ITIL "out of the box" without applying the filter of your organizational culture and unique perspectives will find limited success, at best.  The contrast, however, is also true.  You can drive significant value for your organization, making IT more effective, more efficient and more business focused if you begin by embracing the role that your organizational culture plays in both your successes and your failures and by recognizing that you must change the perspective of how both of these are viewed to truly affect change.

The Telectroscope

Ok, this isn't exactly about IT, but I think that most IT "geeks" will enjoy this as much as I do.  I don't want to spoil anything, just check it out: The Telectroscope. 

Our Most Urgent Problem

I believe that the most urgent problem facing IT and, in truth, the future of US competitiveness is the state of our educational system.  Like healthcare, this is one of those issues that we can all agree on the issue, but it's the solutions that get us tangled.

I don't know what the answers are, but I do believe that the students that we are turning out are woefully ill prepared to participate in the global market that we now live in.  Something must be done and done fast.

I came across an article in Fast Company from September of last year that discusses a range of corporate-public partnerships in education.  It's entitled, "Microsoft's Class Action" and as the title suggests, focuses on Microsoft's deep involvement in one such partnership with the Philadelphia school system.

I am not a big Microsoft fan necessarily, but the article is nothing if not thought provoking.  My wife and I were just discussing the fact that our schools seem ill equipped to teach our children even the basics of dealing with the world that she and I inhabit every day.  I don't know that this is the answer, but frankly, anything is better than what we have today.  I hope to circle back to this article as time permits and see how I might help our local schools apply some of these same ideas.  It's a bigger problem than anything I can tackle by myself, I know that.  But I believe that it is something that all of us in IT need to be very aware of and that we must begin to look at what actions we can take to help drive change before it's too late.