Part 10 - Enemies are often invisible – like Romulans, they can be cloaked.

(This is part 10 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

In Star Trek there was a defensive technology called a “Romulan Cloaking Device” that made their ships invisible to their enemies, much like Harry Potter’s invisibility cloak. From an IT perspective, you need to be aware that your enemies are often invisible. Like Romulans, they can be cloaked.

Viruses, spam, and malware are similar to Romulans. They can be cloaked, yet they can be defeated. But you can’t defeat them with just technology. Admittedly, you need great technology, but you also need to fight the battle on multiple fronts. The interesting lesson from Star Trek is that it is not just a technology game. There are three non-technical soft tools that can dramatically enhance your defensive posture: policy, communications, and coordination.

Let me explain what I mean by policy. You need an organization-wide level security policy giving you the right to enforce IT security (I’ve talked a little about this in Part 3 - Keep your phaser set on stun). To get the mandate to do something like this can be tough. My experience is to ask for an external security audit. You might think that is a bad idea because we all know how potentially vulnerable any infrastructure can be to determined security threats. Such a study might be embarrassing. But my advice is let the auditors be as negative as possible because it gives you, the IT leader, the ammunition necessary to request greater security authority through policy measures.

The second soft skill is communication. For example, prevent phishing attacks through education about never giving out passwords. I tell folks not to tell anybody their password. IT already knows your password, so why would we ask for it? You can’t over communicate this point. Phishing attacks are daily and they are increasingly sophisticated and focused. Spammers are taking the time to learn more about your environment and make the phishing messages more realistic all the time – including using your own logos and timing the attack to coincide with planned system outages. So I advocate communicating relentlessly about security issues.

The third soft skill is coordination. Integrate closely with your non-central IT folks to work together to fight campus threats. At my organization we had a team of folks from central IT and otherwise that worked together as an extended security team coordinated by our central IT security manager.

Most importantly, in many of my favourite Star Trek episodes, Captain Kirk didn’t win battles with superior technology. Quite often he ran into aliens with far superior technology. But he won his battles by outwitting them.

As a matter of fact, Star Trek isn’t an enduring TV show and movie franchise because it is cool science fiction. It is a success because it focused on our humanity and not on technology. The technology was often a gimmick to facilitate the human story. For example, the transporter beam was invented by the writers to conveniently switch scenes as part of a story telling technique. So keep your wits about you and do not let a cloaking device or any other advanced technology fool you.

~

Part 9 - Tribbles hate Klingons (and Klingons hate Tribbles).

(This is part 9 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

Tribbles are fictional creatures in Star Trek. They are small, soft, and gentle, and producing a soothing purring sound. These traits are said to endear them to all who encounter them, with the notable exception of Klingons, who consider Tribbles to be "mortal enemies" of the Klingon Empire.

Roughly translated, if you don’t like someone, odds are, they don’t like you too. So don’t go around making enemies across your organization. Work on building friends and constantly improving relationships. At my university the Information Systems department used to be called “Computing and Systems Services,” so “CASS” was the acronym. But everyone across campus called the department “Fortress CASS” or “Fort CASS.” Needless to say, it wasn’t a popular department. My job has been to knock down the walls and build bridges over the moat to the rest of the campus.

You do that by “opening the kimono” and being transparent (no secrets). We became transparent by actively engaging the campus in information systems decision-making through a broad governance process. Asking clients what they want, and making it happen as promised. Do what you said you would do and get it done. It's not rocket science.

We have had our governance process in place for five years. Business decisions are made by our clients and we simply facilitate the process. We are like Switzerland. We are neutral about the business decisions as long they have fit, utility, and balance. Fit means the decision is aligned with strategic plan of the institution. Utility means the quantitative and qualitative benefits outweigh the costs and risks. Balance means you treat your IT projects like an investment portfolio that is appropriately weighted across the institution.

Combining this governance model with a robust project management culture has been key in building bridges and developing trust across campus. Building trust takes time, but eventually even Klingons and Tribbles can learn to trust each other.

~

Part 8 - Infinite diversity in infinite combinations.

(This is part 8 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

Star Trek's Vulcan world believed in the need to celebrate and support the the vast array of cultures and variables in existence throughout the universe. They summarized this belief in the phrase "infinite diversity in infinite combinations." To an IT department infinite diversity in infinite combinations means “one size fits none.” Specifically, I’m thinking of vendor written ERP systems. They are a particular challenge. 

In the old days we used to handcraft systems. They were built from the ground up and custom tailored to fit every process and client nuance in the organization. We programmed every unique activity and process into the system. So, of course our legacy systems met our needs perfectly.

Today we can’t afford that approach. I’ve heard estimates that to build a new student information system from scratch would cost about $45,000,000. It would be perfectly customized to meet the demands of every nook and cranny in the organization's existing processes. But it would bankrupt the organization. 

Instead of building our own unique systems, we buy industry specific solutions like ERPs. The problem with vendor written ERPs is that vendors build them to meet generic organizational needs. They end up not meeting anyone’s needs completely. They try to be one size fits all, but the reality is that one size fits none. 

This situation creates a new problem. You may have saved money by building instead of buying. But now you have a decision. Do you massively customize the product, or implement it off-the-shelf and change your existing processes? The answer typically lies somewhere in between and every organization's solution will be different. 

Whatever degree of customization your organization decides to choose, the role of IT changes. New leadership in IT means we must emphasize integration, not building from scratch. The days of handcrafting systems are over, but the complexity of “one size fits none” requires new skills. As IT leaders, integration skills are needed to manage infinite diversity in infinite in infinite combinations. That’s a tall order, but no one said the job was easy.

~

Part 7 - Having is not so pleasing a thing as wanting; it is not logical but it is often true.

(This is part 7 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

"Having is not so pleasing a thing as wanting; it is not logical but it is often true." This advice came from Spock when he was giving away a valued possession to someone who desperately longed for it.

From an IT perspective, it is easier to dream about a new system than actually build it. As I mentioned in an earlier post, my university was a mixture of Windows, Mac, and Linux. Nearly every desktop image was unique. I liked to say we supported desktop multiculturalism.

But I had a dream – the “anyplace desktop.” In this dream we would deliver a standard virtual desktop productivity environment to any personal computing device, whether it be a laptop, desktop, smartphone, or whatever. Therefore making it much easier for us to rollout enterprise applications. We would use server-based terminal services to deliver the environment.

It was a great dream. We piloted it in a few places across campus. Reality was a lot harder work than the dream. Complexity in the backend server implementation forced us to re-think our approach. Ideas are easy; implementation is hard. So we moved to a different strategy in the short term based on managed desktops.

We admitted we failed with the anyplace desktop idea, but we did not spend much time on it and we did not dwell on it. We learned a lot and moved on. We may come back to it sometime in the future when the technology is ready for us.

Although we didn’t succeed with our dream, we learned from it. High ambition brought us farther and faster than if we had taken the low road. We can say we tried and the technology was not ready yet. Desire is useful. It helps us to aim high.

Even if we miss, we still grow. Another example is the vision we set for ourselves at my university: we will be the best Canadian University information systems department. We set the bar high and it always gave us something to shoot for. Wanting is good: dream big or go home!



~

Part 6 - Live long and prosper.

(This is part 6 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

To me, application of the Star Trek rule of "Live Long and Prosper" (Spock's typical greeting) to IT means look for long term quality solutions, not quick & dirty ones.

For example, sometimes it is amazing how long a piece of software code can remain in production. I wrote the code for a really large logistics system in the 1980’s for a natural resources company. That company was purchased by two competitors who both took copies of the code. For better or worse, I found out just a couple of years ago that both companies were still running heavily modified versions of my code in production. My basic code has lived long and prospered. It wasn’t brilliant or creative programming and it wasn’t going to win any awards for innovation. It was just painstakingly tested, with excruciatingly simplified logic. And it still works. I’m kind of proud of that.

I think the lesson here for IT is that we need to focus more on the long term and on the quality of what we do, not on getting the quick hit and moving on. It is not about the latest technology. It is about doing it right. Let’s face it, we do tend to be trend-hoppers in IT. Constantly moving to the latest next best thing. That doesn’t do our clients any favours.

I’m a big fan of mitigating unnecessary risks. I used to work for a CIO who said “pioneers have arrows in their backs.” What he meant by that was let someone else the chances. We’ll learn from them and build things using reliable methods and processes done with high quality. That’s the best way for your systems to live long and prosper.

It is also the best way to keep your job. I’ve seen too many IT leaders get caught up in a vendor’s exciting sales pitch about the latest and newest technology. They try implementing something new so they can be the first. They end up being the first to get fired because the kinks have not been worked out of the technology yet. Focus on the long-term quality and you will live long and prosper.

~

Part 5 - There's no such thing as a Vulcan death grip.

(This is part 5 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

For folks not familiar with obscure Star Trek episodes, Spock used the so-called "Vulcan death grip" on Captain Kirk as a means to fool the Romulans into believing Kirk was dead, so they could escape without causing suspicion. Afterwards when informed of the incident, the ship’s nurse exclaimed "But there's no such thing as a Vulcan death grip." Kirk replied that the Romulans did not know that.

The Vulcan Death grip was a very effective deception. My experience with this particular Star Trek rule is that you can only use a trick like this one once before folks are on to you. Not telling the truth can be effective, but only temporarily. As soon as someone discovers you’ve been hiding something, you’ll be in worse trouble.

If we were to translate this Star Trek lesson to IT, I would urge caution. I’ve seen an incredible number of IT folks try to baffle non-technical clients with technical jargon. Nobody likes being talked down to. Nobody likes having to bow to the high priest of technology. So don’t pretend IT can perform magic like a Vulcan death grip. Always try to give your clients plain English explanations.

For example, when I interview technical people my favourite question is how would you explain a compiler to your grandmother? The best people I’ve ever hired are the ones who can answer that question in plain terms. If you can’t answer a question like that, you shouldn’t be in a client facing IT department (and in my opinion, we all have clients). In case you were wondering, the best answer I ever heard to this interview question was “it takes words we understand and translates them into words a computer can understand.”

Another example, with a not very happy ending, occurred when I was working at an insurance company. We had an infrastructure department that tried to use the Vulcan death grip approach on their clients. They acted like the high priests of technology. They used their knowledge as power in the organization. Instead of working with their clients to develop solutions, they used it to dictate solutions to their clients. I would characterize their behaviour as using their power for evil rather than good. And here is the thanks they got: they annoyed the organization so badly they were completely outsourced – lock, stock, & barrel. Be wary about using a Vulcan death grip in the real world.

~

Part 4 - Humans are highly illogical.

(This is part 4 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

Mr. Spock, the Starship Enterprise's First Officer, was a Vulcan. He came from a culture that prized pure rationality. He was a logician who found human emotions sometimes amusing and always perplexing. Since humans may not always be logical, they are an interesting management challenge.

As Spock would say, humans are highly illogical. That characteristic is what makes managing them and designing systems for them so very interesting. People are more complex than computers and managing people is particularly challenging in an IT shop.

Several years ago I did a Myers-Briggs personality assessment of a software development team. I had recently assumed responsibility for managing an organization with a lot of interpersonal conflict and it had become dysfunctional. I hired an external facilitator and brought a roomful of 30 IT people together to spend a day going through the assessment process. I came in at the end of the session to ask them about their experiences during the day and what they thought about the results.

Standing in front of the whole room I asked them for their opinion. No one said a word ... not a peep! So I flipped over the chart that mapped out the personality types of everyone in the room to get the conversation going. Myers-Briggs has 16 classes of personality. But this entire software development department, and I mean everyone, was classified as “INTJ.” Basically they were introverted, shy, risk-adverse perfectionists. So of course no one was willing to publicly volunteer an opinion.

The key point to the story is that the kind of people attracted to IT jobs tends to be similar. There is a tendency for introverts to migrate towards IT careers. That makes them a different management challenge from a marketing department. You need to be creative about how you motivate and encourage them to get out of their offices and comfort zones and go talk to their customers. 

Your job as a leader is to mentor and coach them on relationship building, bridge building, and open continuous communications. Look for opportunities to pry your introverts away from their computers and help them see the value in socializing with their clients. In IT, leadership means managing humans' highly illogical nature. 

~

Part 3 - Keep your phaser set on stun.

(This is part 3 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

For those not familiar with Star Trek, “phasers” are the weapon of choice in the future. IT departments can wield a certain amount of control and influence in organizations and the application of this influence should be governed by rules similar to how phasers are employed in Star Trek.

IT's power needs to be used wisely. Like a phaser on Star Trek, you really should keep it set on stun. In many distributed organizations, such as a university culture, there are very few rules about what computing you can and cannot use. But there needs to be some policy around things like standards and security. My advice is to play nice, but don’t tolerate complaints caused when someone consciously chooses not to follow your standards.

For example, at my university we implemented an imaging and workflow project. The big problem was that desktop computers on campus were as unique as snowflakes. The rough breakdown was 30% Mac, 60% Windows, and 10% “other.” To make matters more interesting, most machines had a unique software image, so even Windows PCs weren’t “standard.”

When we rolled out the new imaging and workflow software, Macs didn’t work, many PC’s had problems, and Linux was completely unmanageable. We had huge implementation problems for this project because each desktop was unique. Software and hardware variety across campus made it nearly impossible to deploy enterprise software quickly and efficiently. Serious concerns were raised about the project and the software quality.

Instead of reacting in a knee-jerk manner to the issues, we stepped back and looked at the big picture. In culture such as an university environment, there is a key equation:

Freedom of Choice + Academic Independence = High Cost + Loss of Functionality 

We decided to use this to our advantage. We said if folks across campus want to make their own choices about desktops, then the issues with the imaging and workflow software are the price to pay. If clients don’t want this to happen again the future, we need organization-wide desktop and laptop standards. This clarity of choice gave us the ammunition necessary to make a change. We used these results to help justify a desktop standardization program across campus with the support of administrative and academic leaders.

We set our phasers on stun and turned a nasty problem into an opportunity. We leveraged a problem into an opportunity to convince folks that we need better standards across campus.

Another example of this Star Trek rule is how to enforce IT security. Traditional passive policies where you only take action after a security issue occurs are too dangerous to the network. Pro-active polices where you take action as soon as you realize a security issue may exist are necessary. The danger is that a proactive policy is very powerful. Like a phaser set on kill, if you use it indiscriminately you will do more harm than good. If you shut someone's computer access down arbitrarily without warning, you will destroy any future potential relationship with that person. My advice is to apply pro-active policies only as the last resort. They can be used as a threat of shutdown in order to convince someone that they should upgrade or fix their potential security issue. You can have the policy in your back pocket, but don’t use it unless you must. In other words, try to keep your phasers on stun wherever you go on campus.

Of course there are times when you can consider breaking the rules. Sometimes you need to set your phaser on something more potent. Several years ago I had been working closely with a department to develop a business case to implement a multi-million dollar system. Everything seemed to be going well until the client told me they would hire their own people to perform the ongoing support and maintenance of the system and manage it independently of the rest of IT. That’s when I set my phaser on kill. I stopped the project dead. They backed down and we were all a happy family again.

There are always exceptions to every rule.

~

Part 2 - Seek out new life and new civilizations.

(This is part 2 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

For IT folks, the Star Trek rule "seek out new life and new civilizations" means there are always new technologies available, so experiment, play, and learn from them.

A great example of this rule was the “Click-to-Call” project at my university. One of our Network leaders, Diane, came to me one day with what appeared to be a crazy idea. The concept was a web-page hyper-link enabling anyone, anywhere to phone anybody at the university for free from a web-attached computer. We struggled a lot with the idea because it seemed to be kind of far-fetched at the time. But we liked to foster a culture of innovation, so we piloted it, tested it extensively, talked to our clients about its potential uses, and 6 months later we became the first university in the world to implement Diane’s crazy idea.

What made this new idea so interesting was its impact on four areas of our business:

1. We were able to put an instant phone link on our Admissions web page. Foreign students and parents could call the university for free to get information. So this tool can help grow enrolment.
2. Researchers could telephone their colleagues at our university for no cost. So this tool supported the University in its strategic mission to become a research-intensive institution
3. Looking up phone numbers on our Directory web page led to click-to-call instead of reading, jotting down the number then dialling ... then realizing you made an error and dialling again! The new capability simply improved the efficiency of our institution.
4. Email tag lines made it easier to return messages with a quick person-to-person call. I had this link to my phone embedded in my email signature. I quite often got calls through this mechanism from folks who were travelling and didn't want to use a hotel phone or incur cell phone roaming charges.

At my university we learned a lot from this Star Trek rule. Our primary discovery was that there is huge business value in seeking out new life and new civilizations; or in other words, always be on the lookout for new opportunities and nothing is crazy if it saves money and works.

Now I have to admit, I’ve noticed one drawback to this system. I had one caller who tried to phone me without a microphone and speaker on their computer. Nothing is perfect and never ignore the human element!

~

Part 1 - Non-interference is the Prime Directive.

(This is part 1 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

In Star Trek the Prime Directive dictates that there can be no interference with the internal development of civilizations. To me, that means support and allow multiple computing cultures to grow on campus. In most university environments there is a central IT group and many smaller distributed IT shops.

My advice to the folks in leadership roles in the central IT organization is to compete in your core competencies, and cooperate everywhere else. So what is a core competency? It is a service that you can perform more efficiently than anyone else on campus. Therefore, you focus on what you’re good at and the institution benefits from optimal use of its resources.

As a central group part of your role should be to enable distributed IT organizations to perform localized specialization more efficiently. For example, we introduced a single email, calendaring, and collaboration tool to our campus. This enabled many distributed IT groups to shutdown their standalone independent email systems and move to the central system. Nobody actually reduced headcount. What we did was enable those distributed IT folks to stop worrying about administering email and begin to focus on IT services that directly improved their functional areas. We helped them move up the food chain while at the same time the University benefitted from greater economies of scale and scope of a centralized service.

To help with these types of initiatives we created something called the Campus Systems Council. We hosted a monthly meeting of leading folks from the distributed IT groups across campus where we shared an update on everything the central IT group did. The meeting was a great opportunity to inform them of technology changes. Similarly, they shared their updates with the group too. The meeting becomes a great forum for communication and it helped build trust amongst the various IT tribes across campus.

If you work for a central IT department, don’t interfere with other good IT work on campus. If you want to get involved, look for ways to nurture and support the distributed folks. Non-interference should be your prime directive in areas outside of your core competencies.

~

Everything I Need to Know about IT Management I Learned from Star Trek - Introduction

When I was the Chief Information Officer at a large university I found myself in front of many different types of audiences. The audiences I always enjoyed the most were students. I once explained to a roomful of students what a CIO, or Chief Information Officer, did at the university. After I patiently explained the job, one of the students exclaimed, “Oh I get it – you’re the head geek!”

That gave me the idea to link everyone’s favourite geek TV show, Star Trek, to some leadership lessons for the real world. These basic leadership lessons have universal applicability, particularly for I.T.

Now I have to admit, I am a huge Trekkie. To prove it, I own a poster with one of my favourite rule lists, “Everything I needed to know about life I learned from Star Trek.” (I told you I was a geek.). The rules are as follows:

1. Non-interference is the Prime Directive. 
2. Seek out new life and new civilizations. 
3. Keep your phaser set on stun. 
4. Humans are highly illogical. 
5. There's no such thing as a Vulcan death grip. 
6. Live long and prosper. 
7. Having is not so pleasing a thing as wanting; it is not logical but it is often true. 
8. Infinite diversity in infinite combinations (IDIC). 
9. Tribbles hate Klingons (and Klingons hate Tribbles). 
10. Enemies are often invisible – like Romulans, they can be cloaked. 
11. Don't put all your ranking officers in one shuttlecraft. 
12. When your logic fails, trust a hunch. 
13. Insufficient data does not compute. 
14. If it can't be fixed, just ask Scotty. 
15. Even in our own world, sometimes we are aliens. 
16. When going out into the Universe, remember: "Boldly go where no man has gone before!" 

The longer this poster stayed on my wall, the more I wondered: how do these rules apply to creating digital information systems solutions at a university? I originally developed some interesting answers to this question in a presentation I gave a number of times. I decided it would be useful to write a series of 16 blog posts to answer the question in more detail.

My plan is to walk through each of these rules in a separate blog post and connect them to IT leadership challenges in higher education. Each rule will have a separate post, and I will update this posting to contain an index of links to each rule as I write them. Each rule in the list above will become a link to the related blog post.

~

Is Klout Evil?

Klout is embarrassing. I feel guilty when I check my score. Is it just about ego affirmation?

Klout is a roller coaster. I wrote the best blog post of my life and my score went down. I re-posted someone else's funny picture on Facebook and my score soared.

Klout is depressing. I thought I was a reasonably popular guy in the real world. In the time-space continuum of the Internet according to Klout I ain't so cool. Ouch.

Klout is a Harry Potter sorting hat. On Twitter I've automated Klout scores to appear beside every post. Now I only read posts by high scorers - the Gryffindors of the Internet.

Klout is omnipotent. It knows all about you even if you aren't a member. It publishes your score even if you haven't joined. Oh well, thats what you get for living life in the public space of the Internet. Too bad.

But is Klout evil? Hardly.

~

Library Magic

One late evening of the early fall of 1977 I suddenly understood the concept of marginal utility. In an island of quiet surrounded by a sea of fiction I figured it out. In retrospect the discovery was not that complicated. But my days had been filled with running to classes, meeting new friends, and recovering from frosh week. No time for reflective thought. It is amazing what a lonely study carrel can teach you.

This actually wasn't the start of my love affair with libraries. That started many years before. My elementary school library taught me all the things I needed to know about life that Mrs. McKnight, my grade 4 teacher, couldn't teach me. Like why the Cuban missile crisis almost destroyed the world. And why chemistry really led to better living. And why 18th century British infantry wore red. Random stuff. But I was learning to learn. The school library gave me the opportunity to learn what the structured curriculum was never going to teach anybody. It was a portal into new universes.

As I got older I started to do formal research in the library. By high school learning demands were broader. The school's library wasn't big enough. The lure of the downtown mega-library pulled me into its time distortion field. Hours spent wandering through stacks of unplanned knowledge. A small project on polar bears turned into a journey of discovery. Pulling out unrelated volumes on polar exploration and Polish cinema sent my mind into unexpected worlds.

Apparently the library that gave birth to my understanding of marginal utility is changing. I've seen more computers and more team space and more teaching functions come into the library. I've seen new additions to buildings. I've sat on library steering committees and watched money get moved from books to online journals. And best of all, I've seen Starbucks occupy some musty unused corners.

But lets think about those changes. More information. More opportunity for reflective thought. Just not so lonely anymore. Seems like the new things are good and the important things are still there. Yeah. Now it's time for a latte and that new book on Polish cinema. And while I'm doing that I can browse the films on my iPad using the library's wireless. Knowledge, technology, and good coffee. Perfect.

~

BYOC ... Bring Your Own Computer!

I've seen a lot of news recently about Bring Your Own Computer (BYOC) to work. Driven by an abundance of reasonably priced options for smartphones, tablets, and laptops, folks want to bring their access devices from home to work. Given the freedom of choice, most people tend to buy something that meets their personal needs. The problem for the central IT department is that we get comfortable with them. Then we want to bring them to work.

BYOC is more of a cultural problem than a technical problem for central IT. Historically, end-user computer access devices were dumb terminals. No data belonging to the organization was permanently resident on these devices. No functionality to manipulate the data was built into the device. All corporate data was controlled behind the end-user access point. The illusion of control was absolute. Central IT had complete authority over the data everywhere.

Evolution kicks in and processing power comes to the terminal. We replace terminals with PC's. The PC can collect corporate proprietary knowledge, download it, and save it on portable media. Suddenly everything is at risk. Corporate IT departments respond by locking down personal computers. Standardized hardware and software is enforced. External access is limited and monitored. Control is necessary and accepted because the stakes are high.

But today that paradigm is being shattered. The latest stage of evolution is BYOC. Users are demanding choice. Yet if IT can't enforce standard devices, is corporate security doomed? I doubt it. I think we can we learn from history. What succeeded in the day of dumb terminals? It wasn't control, it was trustworthy information. What succeeded in the day of PC's? Greater user functionality and service.

Central IT should worry about protecting proprietary knowledge, intellectual property, and personal privacy. If you build information services with security in mind from the ground up, none of that data should reside on end user devices anyway. Architect your systems to give users the service they deserve on the devices they want.

Absolute control of end user devices was an ephemeral luxury for central IT groups. That luxury is fading into the sunset. Client service is not about the device, but the information systems available. That might be a lot harder to achieve without locked down standard devices. But it sure means your clients are going to be happier. Boxing up a standard, plain vanilla device is easy. Providing real service to your clients is hard. But worth it.

~

Why I Love Google ... and Apple ... and Microsoft

I woke up this morning and realized nearly all my core web services are Google products. Email, calendar, web sites hosting, chat, blog, portal, and yes, even search, are all Google. What astounds me is that almost none of them are best of breed. WordPress is a better blog tool, Outlook has more email and calendar features, and there are many more sophisticated web site hosting environments. Almost all of these non-Google tools have better individual features. But Google wins every time because of integration. Their tools work well together. I login once and have access to everything.

They succeed because they have created an architecture of simplicity. Google has managed to make my online life simple. I reward them for that act of clarity through loyalty. Almost by default I will choose a Google web service over a competing product because they make my life easier. I don't have to do any of the integration work. They do it all for me. I can focus on getting the things done that I want to do. I don't have to fuss with the disparate technologies and jump through hoops to make them work together.

Same goes for Apple. Entertainment in my life could have become incredibly complex. But iTunes on all our family computing devices works seamlessly. We can share our library, add to it, back it up, and so on without thinking about it. Apple seems to know what we want before we want it. No complexity on my part. My Mac is the computer equivalent of a finely tuned Porsche. It works perfectly. Any Apple hardware works with it in perfect harmony. Simple, easy to use integration allows me the luxury of not having to worry about hardware problems.

The difference between Apple and Google: Apple products are best of breed. But you pay a substantial premium for them. Integration comes at a price with Apple. Their hardware may be the best, and you need to be willing to make the investment. I'm willing to spend more on Apple to mitigate the risk of hardware failure. I'm willing to accept weaknesses in Google products because the cost of learning and integrating multiple web services is too steep for me.

I even love Microsoft for much the same reason. Microsoft Office is beautifully integrated. Elegantly consistent across the core Office product lines, the folks from Redmond make my life easy. Without giving a thought to the underlying complexity of the task I can write a detailed Word document with integrated Excel spreadsheets and PowerPoint diagrams. The end result looks perfect. Not a single flaw indicating the contents were built using three very specialized and unique software tools. Microsoft is the original master of embedded integration.

The consistent secret to success for Google, Apple, and Microsoft is integrated architecture. Individual features are easily copied and transcended by competitors. Well-designed, principle-based architectures are unbeatable because they are seamlessly integrated. Now if could just get Gmail to embed my iTunes podcast with a PowerPoint slide show ...

~