Confessions of a SharePoint architect: when do you stop and think?

Few years ago, I had a chance to build software for a startup.

Their service basically called for document management, some personalization, profile management, and few other things. It needed to launch fast ... duh. We chose SharePoint as a platform since it solved majority of our initial use cases ... fast.

That’s what we knew at the time so we build the architecture and started coding!

Meanwhile, the startup folks were figuring out their customer model, profit model, and key features. All these "little" changes trickled down to how the end software was to function.

Meanwhile, Microsoft planned ambitious turn for SharePoint. To become multi-tenant, somewhat locked down, stable, single purpose product - SharePoint Online. Not what we needed it to be!

It’s not what you KNOW, it’s what you DON’T

There was a gap of what we needed SharePoint to be and where it was going. There was a gap of knowing what our product should actually do and how will it evolve.

I wish this was the only project that went this way. Few more cases included even well established, large companies. In some cases we got blindsided by people factor, in others, technology factor. It all worked out, but those were some stressful projects and left a sour taste in, probably, everyones mouth.

So what did I learn from these?

Listen very carefully. We often listen for keywords and stitch the meaning together. This is great to make sense of lots of new information. However, we miss keywords we’re not trained to listen to. For example, a technologist might miss domain specific keywords which could be integral to your project success. Try to ask questions. Bring an expert to a meeting: Designer, Strategist, integration expert, BI expert, infrastructure resource etc etc.

Get to know more about the business. Some times, to keep the scope contained, I try to draw the line of how much information I’m letting in: “I don’t need to know that, that’s not in scope”. Some times, that line puts in a shadow things that are of a huge significance. Getting to know more about the business will help you evaluate priorities, biggest pain points, even if they’re not part of your scope. You might learn future direction of the project/product or how it fits in a big picture. Maybe it's not appropriate to delve into side discussions right away, but have a follow up one-on-one - "hey, you say something that caught my attention during the meeting...".

Be ready for a change. Don’t paint yourself into a corner, especially if you’re working with third party platforms and services. Try to leave yourself some room when describing the implementation or functionality. If you can, try as much as possible to negotiate flexibility of how certain bits and pieces will be implemented.

Have plan B … and Plan C. We use third party platforms, services, and frameworks all the time. Owners of those services, however, have the right to pull the rug under us at any time. Whether authentication methods change for one of the services in midst development or bits of API become deprecated – it’s a reality and you need plan B. Not having plan B is basically like driving without checking mirrors.

People first, Solution after. No matter how great the solution is, if people don’t like it, something got lost in translation. The best way to recover is not by defense, instead, see what people have to say, be their ally, see if you can make it happen.

Have fun! Try make genuinely the best experience for your team and results will surpass your expectations

 

 Yaroslav Pentsarskyy

Yaroslav Pentsarskyy is Microsoft MVP since 2009 and speaker at many local and worldwide tech events. Several of Yaroslav's books include: Rapid SharePoint 2013 development, Top 60 custom solutions built on SharePoint 2010, SharePoint 2010 branding in practice, and SharePoint and PowerShell Expert Cookbook.

@spentsarsky