While at the Microsoft SharePoint Conference in November, Dux placed a microphone in my face and asked what I’d be doing if I wasn’t doing SharePoint. My answer is probably more than a bit confusing. I said “The same thing I’m doing now, refereeing developer-it pro cage matches.” (Or something similar, I had quite literally just arrived.)
That sounds sort of odd on a couple of levels so I wanted to tear it apart.
What If There Were No SharePoint
I’ve made quite a bit of my professional career in SharePoint. I’ve had plenty of room in SharePoint to do infrastructure, development, end user adoption, workflow, governance, and tons of other things. Certainly if there were no SharePoint my world would be very different, however, at its core, I see SharePoint as a platform for solving business problems. If I wasn’t doing SharePoint I’d still be doing something to help businesses recognize value out of technology. My guess is that I would have ended up at some large organization as an enterprise architect, putting together pieces to minimize problems – and make it easier for the organization to recover.
I’m a high challenge person as nearly everyone who knows me will attest. That doesn’t necessarily mean that I’m challenging – it means that I will seek out challenges and try to conquer them. That’s another way that SharePoint has been fertile ground for me. In the beginning we were facing technical challenges that hadn’t been seen before. (SharePoint 2001 would continuously respond with HTTP 100 Continue messages – confounding most of the monitoring tools of the day.) We’ve been faced with scalability problems. I could go on about the technical challenges that we’ve conquered as a community over the years.
I believe that SharePoint is one of the most challenging applications to sell an organization because it’s not an application. It’s a platform. It’s infrastructure. Back in 1991 when I was first working with email, we didn’t have a defined need for email. We didn’t have a specific business purpose. It was just something people were playing with. I was lucky enough to be a part of Woods Industries at the time and with the overseas sourcing we did find a specific need and over time we began to develop an awareness of the benefits – but even with the spark of an initial need it was still a struggle.
In many organizations today it’s difficult to explain how SharePoint can be helpful – even to those who already have it and need only learn to use it. The fact that there’s not one thing that the tool does makes it hard to explain. It’s a desert topping and a floor wax – and it will always be that way.
Why Can’t We All Just Get Along
Why I describe what I do as refereeing a cage match is another mystery. The short is because I often act as a translator between developers and IT Pros that just don’t speak the same language. I am not surprised by the conflict that exists between infrastructure and development – and you shouldn’t be either. Infrastructure is goaled on keeping systems stable. Development is goaled on delivering new solutions for the business. New solutions mean change and change means instability.
It’s no surprise that the conflict that’s created with the opposed goals spills into other areas and the finger-pointing game begins. Developers believe that the performance is bad because of bad infrastructure. The infrastructure team believes that the performance is bad because the developers are writing bad code. I don’t believe I remember an organization where development and infrastructure really got along.
The cage match bit is that developers and IT Pros can’t get away from each other. In a regular match you can go away. However, if you’re in an organization the idea that you can get away from the conflict isn’t realistic.
Whether I’m doing SharePoint or not, I’m looking forward to bridging the gaps, improving understanding, and making the developer-IT Pro relationship feel a lot less like a cage match.