Twitterview About Developing in SharePoint’s Middle Tier with the SPTechCon Folks Today

SharePoint Technology Conference | Boston | June 1-3, 2011

I’m still not sure I’m sold on the whole Twitterview concept, but it seems to be an idea that is catching on out there, as I’ve seen two others going on in the last few days. What I *can* say is that it’s always fun to interact with the good folks at BZ Media who are behind the SharePoint Technology Conferences (SPTechCon). Thanks especially to Katie Serignese (@BZK80) for putting the Twitterview together today. You can read the transcript over at the SPTechWeb site, or right here. I’ve bolded Katie’s questions below.

SPTechWeb “Twitterview” with Marc Anderson

By Katie Serignese

April 29, 2011 —  Marc Anderson, a SharePoint MVP, discusses his experience with SharePoint and “middle tier” development. He will be presenting on the topic at SPTechCon Boston June 1–3.

Hey, @sympmarc..ready?

@SPTechCon You betcha!

@SPTechCon is now going to try to keep me to 140 chars. Should be interesting!

.@sympmarc Although most people here know you, please tell us a little about yourself and your experience with #SharePoint. #SPTechCon

I’m one of those people who claim linkage to SP going back to Tahoe et al. You can real my bio here. #sptechcon

To me, SharePoint is the platform we have been trying to build since at least the mid-90s for KM and collaboration. Bees knees. #SPTechCon

Because of that fabulousness, I’ve dedicated myself to working w/ #SharePoint for the last 5 years or so. #SPTechCon

Ok, so @sympmarc you’re teaching about the “Middle Tier” at #SPTechCon, what exactly is this concept about?

Best way to understand what I mean is to read my Manifesto. #SPTechCon Basically the working place b/w the UI and VS.

It’s an alternative way to develop powerful solutions within SharePoint. Not always the answer, but often it is. #SPTechCon

Your unique governance model should dictate how it fits into your own development portfolio. Governance understanding is key. #SPTechCon

The Middle Tier tools are SharePoint Designer, DVWPs, XSL, jQuery/JavaScript, CSS, and SPD-based Workflows. #SPTechCon

.@sympmarc We understand that you’ve had some pushback on this, why do you think that is? #SharePoint #SPTechCon

I think pushback comes for several reasons. 1st is that “middle tier” can mean other things. (So does “customization”.) #SPTechCon

2nd reason for pushback is that it’s not the “Microsoft way”. It’s non-traditional development to a .NET developer. #SPTechCon

3rd is specific reasons it may not make sense from a deployment perspective. Did I mention governance? #SPTechCon

The good thing is that these techniques have won many converts since I wrote the Manifesto. #SPTechCon They just plain work well.

When people hear me talk about the Middle Tier at #SPTechCon, they see that it makes sense as prt of their development portfolio. #SPTechCon

Governance of the process, @sympmarc? #SharePoint #SPTechCon

Governance as applied to development and content mgmt. In the Middle Tier, code is content, too. #SPTechCon

When I talk about governance w/my clients, it encompasses everything about the way people interact w/SharePoint. All people. #SPTechCon

Have I mentioned yet that if you register for #SPTechCon with the code ANDERSON, you can save an extra $200? :-)

You stole my line, @sympmarc! I was going to ask if you knew of a discount code!

If more people use the code ANDERSON than any other, I win a Motorola XOOM, which I’ll raffle off to someone who uses the code! #SPTechCon

So, @sympmarc what new things about #SharePoint and middle tier tools can be learned at #SPTechCon?

Since the Middle Tier has gotten some street cred, I’m not the only one talking about it at #SPTechCon. Many others will be talking abt it 2

Great minds like @jbhoward and @mrackley will also be talking about doing things in the Middle Tier. #SPTechCon It’s great venue to learn.

I’ll be doing my session “Developing in SharePoint’s Middle Tier” and I’ll be at #SPTechCon the whole time. Too valuable to miss any of it!

(If you know me, you know that I’m not blowing smoke. #SPTechCon rocks.)

Well, awesome and thank you, @sympmarc. Can’t wait to see you in Boston @ #SPTechCon! :o)

Learn more about the Middle Tier at #SPTechCon. Reg now with code ANDERSON for $200 off & a chance to win a XOOM Tablet


IT’s Relationship with SharePoint Users: Search and Destroy vs. Nurture

In my conversations with IT departments about how SharePoint is used in their organizations, the topic of old and/or dormant sites almost always comes up. The IT way to think about this is to immediately bring up ideas like “archive” or “delete”. We can get that disk space back! Our job will get easier!

I would turn that around. Rather than looking for sites to delete (Unfortunately, too often I’d say a *HUGE* percentage would go depending on the criteria you decide to use.), we should be asking questions like:

  • What made you decide to use SharePoint in the first place? (Were you forced? Did you see great promise?)
  • What was your early experience with SharePoint like? (Did you have enough support? Did it make sense to you?)
  • What did you try to use SharePoint for?
  • How long did you actively use it?
  • What made you stop using it? (Was it too hard to use? Did it not support your business needs? Could you not get the help that you needed?)
  • What could we change to make SharePoint useful for you?

I’ll bet you $1,000,000 (that’s one million US dollars) that almost none of the answers to that last question will be on the list of the IT organization’s goals for 2011. And I’ll also bet that "Upgrade to SharePoint 2010" isn’t on that list. What SharePoint 2010 offers by way of *functionality* may be represented on the list, but the product itself probably won’t come up.

If you don’t know your users and their needs very well, they’ll find other ways to get their jobs done.  There are lots of options out there, and they will find them whether they are allowed by your governance model or not. (Yeah, you have a governance model, right? Not a written down one, an *understood* one.)

Nurture your users. Be collaborative with them to help them get their jobs done. Stop deleting their stuff.

Choosing the Right Development Tools for Your Organization

At one of my clients, there’s a debate going on about whether to control which development tools people use or not. In my mind, that’s a no-brainer; absolutely!

I say "Never let the inmates run the asylum." What I mean by this is that if you ask N developers what tools you should use, you’ll probably get N^2 answers. Developers usually shouldn’t make these decisions on their own. (I say this as a developer. I’d love to use Pascal or FORTRAN or assembler or FOCUS again, but would it make any sense???)

When I was 23 or 26 I always wanted to play with the cool new stuff, just like the 23 or 26 year olds today. What I didn’t have then was perspective on what works well over a long period of time. Now that I do, I know that the Wild West approach may seem like a good idea to some, but it’ll cause tears sooner rather than later.

Almost every organization I’ve worked with has an architect role or office that screens new tools and makes suggestions or edicts. How tightly the organization is tied to those suggestions or edicts depends on what type of organization it is. If a bank said "Let’s use whatever we want in our ATMs.", that would be a real problem. On the other hand, in an R&D environment, considerable leeway may actually make sense.

The academic model says "Let’s try anything and see what works."; the corporate model is usually more like "Let’s look at our overall strategy [the business strategy, not the IT strategy, at least first] and determine which tools will be the most productive and cost effective."

Cost effectiveness takes many forms: can we produce high-value solutions quickly and reliably, can we scale up our staff rapidly if we need to, can we keep up with new software versions reliably, can we build good institutional memory for maintainability, can we support our solutions, can we train our users fast, etc.

Now I’ve seen most large organizations totally blow it on this. The controls end up being the goal rather than the effectiveness and cost management. This usually leads to skunk works, or some other form of "cheating" to get things done. Letting the pendulum swing to far that way can actually cost *more* than the Wild West approach.

All organizations should have some sort of guidelines at least, and in most cases, stringent rules. As with SharePoint governance, there’s always a lot of "it depends", but there will be a right set of answers for every organization, and some sort of control is what is going to make the organization succeed in the long run.