Business-to-Infrastructure Engagement Part 2: An Enterprise Infrastructure View

I recently wrote a post on Business-to-Infrastructure Engagement focusing on CIT Infrastructure. In Summary I propose there are two types of Infrastructure within the organization. The first being based on the traditional responsibilities which I’ll call CIT (Communications & Information Technology) Infrastructure. The second being based on the new responsibilities (messaging, collaboration, search, &c) which I’ll call Enterprise Infrastructure. I also propose that each type engage the business in different ways.

In the last post I proposed that for CIT Infrastructure, the customer (meaning external to the CIT function) contact is generally indirect, working through other solution delivery teams that have regular and direct contact with the customer. I also proposed that as part of the CIT Infrastructure function, the technology towers should work with solution delivery teams in six additional areas to improve over all Business Engagement.

So, know that we talked about CIT Infrastructure, how should Enterprise Infrastructure engage the Business?

Identifying the customer for Enterprise Infrastructure

The first difficulty for Enterprise Infrastructure is finding that elusive customer. In most organizations, it is everyone. (Everyone has e-mail right?) But, that generally means that there is no solution owner from a business point of view. It’s easy to identify the primary users of an HR system, they are in the HR department! So, how do you engage everyone; at least the part of everyone that can influence what you do? I propose that Enterprise Infrastructure build a representative set of communities to engage. I have come up with three type of communities - product, service, and local communities.

1. Product Communities are build around specific end-user technologies. These end-user technologies my be part of a greater ecosystem, but the users really care about the particular product. Examples might be communities of users interested in the use of BlackBerry or iPhones, Chrome OS or MS Outlook.
2. Service Communities are built around a specific service that Enterprise Infrastructure delivers. These services may not have lines of folks willing to give their thoughts, but they are by nature of the system critical for business activity. Examples might include messaging, collaboration, blogging, client computing &c. If you can, you should try to have executive sponsorship of these service communities.
3. Local Communities are built to address local needs. The scientist in Mexico probably will have different phone needs that the accountant in Maine. These may be the hardest to engage since there is such a variety of definitions of “location.” In my mind, I have two types of “location.” First by actually physical location. Second by where their function takes them. So for the scientist in Mexico, you may have to work both through local support staff in Mexico and/or thought the Science function perhaps through other service delivery teams.

How you go about engaging each of these communities will be a discussion for a future post.

Measuring customer engagement will be different for Enterprise Infrastructure, and I’ll be covering that in a future post.

Did I miss anything?

Related posts:

• Business-to-Infrastructure Engagement Part1: CIT Infrastructure

Book Review: The Mauritius Command

The Mauritius Command by Patrick O'Brian

What has been your primary question?

I’ve just started reading Who’s Got Your Back by Keith Ferrezzi (author of Best seller Never Eat Alone). He asks a very important question, and then uses his own answer to build on for a chapter (Mind-set #1: Generosity). The question is “What has been your primary question?” He got the idea from a retreat with Tony Robbins. The premise is that everyone has a dominate question that is “always in the background, filtering our conscious and unconscious thinking.” Some examples might include “What have I done to deserve this?” “When does life get better?” and “What do they think of me?” Ferrezzi’s answer is “Am I safe?” I’ll let you read the book to learn how that it tied to generosity, but it is.

My primary question is “What do I want to do?” Yes, I’ve have been one of those people that have looked forward to what’s next, what’s different. Some might call this flighty, flakey or whatever. So might say I have broad interests or experiences.

I suspect that this was more or less instilled in me as a child. Growing up on a farm, I knew that that I was going to be a farm. Then the in the early 80s, family farm started disappearing. Hollywood released Country, and Willie Nelson put a face on the American farmer with Farm Aid. Our farm didn’t disappear, but it was taken away as a career choice. So, at the age of 13, I had to start thinking of answers to that question, “What do you want to be when you grow up?” long after most boys had decided.

I also saw the good in many things. There wasn’t one thing that caught and kept my attention. A novel or history book wasn’t good enough, I like the Encyclopedia. I could page through ‘M’ and learn about the Moon, or Maine, or Mary, Queen of Scots. To me, there was magic is knowing a lot about different topics – especially the intersection of ideas, or places, or people.

Two people that had great influence on me as a kid also exhibited this same tendency – my Mom and Sister. I saw them involved – or try – many things on, only to discard them. I suspect, from the stories I have heard, that my maternal Grandfather was also involved in many things. I wonder though if they every asked themselves “What do I want to do?”

The impact on my life is that I’m always trying something new – to learn to play a respectable game of chess, to learn to speak a foreign language, &c. A lot of them end up on the shelf, a few strike a keen interest, and few stay around. Perhaps, I just cast a wide net and pick only the best.  Perhaps it’s in finding intersection that I find the joy.

“What has been your primary question?”

Business-to-Infrastructure Engagement Part 1: A CIT Infrastructure View

We recently went through a process to evaluate the level of engagement with our customer. The evaluation was conducted via web survey to a fairly wide array of customers. Although the results were very good, one area that wasn’t covered, was Infrastructure. Infrastructure has a very pliable definition depending on the organization. Historically, the Infrastructure organization has focused on core systems technologies – servers, desktop standards, storage – and communication – voice and data. The customers for these services are generally other IT professionals and solutions delivery teams (with the exception of voice).  More recently, Infrastructure has been given responsibility for tools that enable the enterprise on a broad, if you will, enterprise-wide basis. The customer for these services is the proverbial everyone.

So, there are now two types of Infrastructure within the organization. The first being based on the traditional responsibilities which I’ll call CIT (Communications & Information Technology) Infrastructure. The second being based on the new responsibilities which I’ll call Enterprise Infrastructure.

So the questions are: should Infrastructure seek to engage the customer, and if yes how? For us, the answer is yes, and in very specific ways.

CIT Infrastructure

CIT Infrastructure covers the historical technology-focused domain. Often, the teams are distributed into traditional technology towers (silos) such as Data Center, Network, Security, Servers, Databases, Desktop, Storage and Telecom. Although teams may work across technology towers, their focus is on the technology within their own towers.

Customer (meaning external to the CIT function) contact is generally indirect, working through other solution delivery teams that have regular and direct contact with the customer. On occasion, direct contact between technology towers and customers may occur by request to work on a detailed need which the solution delivery team cannot solve.

As part of the CIT Infrastructure function, the technology towers should work with solution delivery team in six additional areas to improve over all Business Engagement. These activates are targeted to making the solution deliver team more effective at engaging the customer.

1. Architecture Planning – Often times, technical architecture is a rallying cry to a religious war. Too quickly we take sides, fortifying our position with our opinions. The earlier we start talking about architecture, the less likely that we’ll have a battle. In a previous post, I talked about a process for managing the technology life-cycle.
2. Performance Testing – Like beauty, performance is in the eye of the beholder. Service delivery teams need to discuss with the customers their expectations regarding system performance. (This might be a case where direct consultation is needed.) Technology tower staff will most likely be better equipped than their service delivery staff to define performance needs, and develop plans to address expectations. The technology teams should take a very active roll in teaching service delivery staff the skills needed to plan, design and test for performance. 
3. Capacity Planning – “How much data is kept?” “How big is a row?” “The network is slow.” Customers and many solution delivery people though comments around that reflect a clear misunderstanding about the underlying technology. The network is fast enough, depending on how small that elephant is. The solution delivery staff should be able to translate the amount of data moving across a network into performance expectations – most can’t. Just like performance testing, technology teams should take an active roll in teaching service delivery staff the skills needed to plan and design to meet capacity needs.
4. Disaster Recovery/Business Continuance – After 9/11, DR/BC has taken on new meaning. But like everything else, we’re starting to slip on the real meaning of Disaster in the DR/BC context. This is also a place where you need to ask the hard questions. “What will happen if the data center is no longer here?” “What happens if we have no tech stuff to stand up a new data center?” Ugly questions. But, it will help everyone understand a disaster, and what the business needs to do to make sure it can continue to operate – and how much it’s going to cost. Just like above, technology teams should take an active roll in teaching service delivery staff the skills needed to plan and design to meet DR/BC.
5. System Costs – Everyone is trying to drive down CIT costs, especially it today’s economy. Nearly free disk space is great when you’re talking a commercial USB drive, it’s different when you’re talking about one inside an server array or SAN. Understanding cost impacts to functional requirements is key to keeping costs manageable. Is having 8GB e-mail quotas worth the extra $100 per user per year in storage costs? Is allowing the use of Pandora.com worth the extra $50 per user per month in bandwidth costs? It’s a decision that everyone has to be part of.
6. Operational Level Agreement – Most service delivery organizations have a service level agreement with their customers. Too often, they are only focused on what they can do. To make the SLAs meaningful, they need to include the CIT Infrastructure to. So, the service delivery team needs to have an operational level agreement with the IT infrastructure team. If it takes 2 hours for an IT infrastructure team to respond to an outage, it should be factored into the overall SLA with the customer.

There are many functions that the technology towers do to support service deliver teams. For example, Security. Security needs to be designed into the solutions, developed and then tested. Often times, it’s the technology tower – Security – that is most knowledgeable. Security needs to work with the solution delivery team to pass their skills on. I didn’t include that (and a few other instances) in the list above because I was focusing on those items that will affect the service delivery teams ability to positively engage their customers.

Managing CIT’s engagement may be different, but I’ll cover that in a future post on Governance.

Measuring customer engagement will be different for CIT infrastructure, and I’ll be covering that in a future post.

Did I miss anything?

Related posts:

• Technology Life-cycle Management - Part 4: Process

Book Review: Lincoln's Melancholy

Lincoln's Melancholy: How Depression Challenged a President and Fueled His Greatness by Joshua Wolf Shenk

Change and the organization: Fast and flexible?

I have often scratched my head in frustration when it comes to figuring out why the change I want to have happen just doesn’t happen. Faster, slower, faster; left-hand, right-hand, who’s in charge? Why can’t everyone just do (or stop doing) that? It’s never that easy with a single person, with an organization, it’s even harder.

How fast or slow, how flexible or rigid an organization is will affect how you manage change. You can’t – at least I can’t – just snap my fingers to get things done. You need to under stand how your organization changes, who makes decisions, and how fast they get made. You need to go beyond the surface on this one too. There is always a superficial view, and then their is reality. You maybe in a consensus decision making organization, but there are usually a few individuals that drive the consensus - you need to know that. You may think your organization changes fast, but only in certain areas - you need to know that. You need to understand what the organization is like in your particular context.

Organizations generally fall into four categories, static, sprawling, rapid-niche, or perpetual motion. Each of the four types has very specific behaviors when it comes to digesting change.

• Static: Slow and rigid. Often seen a bureaucratic and generally has a fixed market that it delivers goods and services to. Think IRS. Change is episodic, infrequent, discontinuous and is intentional. Change is generally very well planned out and has broad support. The organization is mostly driven by inertia.
• Sprawling: Slow and flexible. Often has a broad view of what business they are in. Change may appear fast simply to the large number of initiatives going on simultaneously. Think GE. Change is generally very targeted and spurred by opportunity and necessity. Change occurs at the OU level, and may look differently.
• Rapid-niche: Fast and rigid. Hyper-focus on their market. Think McDonalds. Incremental change which is defined, focused, tested, agreed upon and occurs continuously. Change is a way of life.
• Perpetual motion: Fast and flexible. Can make the organization seem out of control, not knowing what business they are in, especially to outsiders. Think Google. (Has anyone figured out what business they are in?) Change is ongoing, evolving and cumulative. Change is never imposed but generated and enthusiastically supported.

Organizations aren’t always easy to put into the above box. In the case of GE, it might be a Sprawling organization, by the OU that manufactures GE consumer appliances might be Rapid-niche. Even further down the organization, if the change you want to make affects only a department, or workgroup, it too might yet be different in speed and flexibility.

There are also times in which you just wont know. You may be trying to make a change at your local school where you have no experience or exposure. Just have to ask the question “How does change happen around here?” Once, twice or several times to understand how the organizational culture might impact your agenda.

Now that you have that diagnosed, you can look at changing you agenda to help the organization change, and make you successful.

Related posts:

• Twelve traits of a proactive thinker
• Change and the organization: Ebb and Flow
• Change and the organization: Dealing with uncertainty

Book Review: The Selected Poetry of Rainer Maria Rilke

The Selected Poetry of Rainer Maria Rilke by Rainer Maria Rilke