A Good SharePoint Architect/Developer & Fantasy Football GM Are Much Alike

If you’re like me, you're really looking forward to the playoffs starting in your fantasy football league(s) in the next week or two. 

Last year I was lucky enough to win my work league, and this year I’m going to be in the playoffs again.  I can’t wait! 

In my other league I’m not doing so hot, but we won’t focus on that league today.

I know what you’re thinking: Huh? What does that have to do with SharePoint development/architecture? 

Read on--I think you will find there are a lot of similarities between a good SharePoint architect/developer and a competitive fantasy football general manager (GM).

Do Your Homework

A good SharePoint architect/developer understands the technologies available to implement a given SharePoint solution and researches these technologies until he or she finds the appropriate architecture to implement. 

For example, let’s say you need to implement a LOB application in a SharePoint web site that allows your users to interact with data in an Oracle database, and you need to facilitate standard CRUD operations on data that has many-to-many relationships defined in the database. 

If you do your homework, you’ll find that an External List is not an ideal solution because the out-of-the-box forms that come with External Lists don’t facilitate every aspect of CRUD.  Furthermore, the External Content Type Picker controls don't work on every form with data that has many-to-many relationships.

At that point, you’ll dig deeper into how to architect the system to overcome these limitations. Eventually you’ll come to understand that the BCS APIs you will use to work around the example I described above differ to some degree. 

You'll also discover that some BCS APIs might work great in a given context, while others do not.  For example, CSOM APIs work in a SharePoint app, while the BCS Runtime API isn’t available in a SharePoint app and only works in a Full Trust Solution.

This is just like draft day in fantasy football!  For example, if you are in a Points-Per-Reception (PPR) league, and Alfred Morris and Darren Sproles are the best running backs available, and you need to fill a running-back slot on your roster, it’s an easy decision to go with Sproles. 

Why?  Because he catches way more passes out of the backfield than Alfred Morris does, due to the pass-heavy offense Sean Payton runs and Drew Brees so adeptly executes.

No matter which angle you look at this from, your understanding the environment, the options you have available, and the rules that govern a given scenario are going to make you successful or cause you to fail. 

That being said, allocate time in your project plans to properly research and investigate the solution you architect. 

Sometimes this might include developing a small Proof Of Concept (POC) to confirm your research lines up with reality.  I’ve seen more than one SharePoint deployment go poorly when inaccurate assumptions were made regarding how a given set of functionality or API in SharePoint behaves.

These incorrect assumptions could have been easily corrected with a small POC before the project started in earnest and would have saved a substantial amount of time and money in the long run.

Plan For and Adapt to a Changing Environment

Let’s face it, requirements and technology sometimes change during the course of a project--it’s the nature of an agile and fast-paced workplace and how quickly technology changes. 

How you design your SharePoint solutions can mitigate the impact of changing requirements and technology.

For example, let's say you are in a scenario where you currently build all of your on-premises SharePoint solutions with Full Trust code, and you’ve heard rumblings in your organization that folks are considering moving to Office 365. It’s probably in your best interest to learn how to make SharePoint apps that use the Cloud App Model (CAM).

Sure, this might require you to learn a new skillset that you might not be intimately familiar with yet. 

But in the long run, the amount of time it takes you to learn the CAM and develop with it going forward will dwarf the amount of time it takes you to rewrite all of your SharePoint solutions if your organization transitions to Office 365.

Another example of this in the SharePoint world is choosing to use ASMX web services to implement a solution, versus REST or CSOM. 

Sure, you might be comfortable working with ASMX web services now, but Microsoft has made it clear it's investing in the CSOM and REST APIs that support the CAM going forward--while not much has been said about the future of SharePoint ASMX web services.

A good fantasy football GM thinks ahead and plans accordingly as well.  For example, in one of my fantasy football leagues this year, a GM in my league had all three of his starting wide receivers on a bye in week 9. 

Roster restrictions only allowed him to have five wide-outs on his roster at a given time.  His options were to drop one of his starters from his roster (where that player could potentially be picked up on waivers by another team) or play a week-9 roster with one of his receivers on a bye week (where the wide receiver would be guaranteed to score zero points).

Both options were ugly from a fantasy GM perspective. 

He explained the situation to the league and petitioned all the GMs to refrain from picking up his starting receiver from the waiver wire.  The overall consensus from the GMs in the league was “part of managing a team is planning ahead for bye weeks."

I think you get the picture. 

Not only should you plan and research your SharePoint architecture for the present, but you should definitely consider the future as well! 

Call An Audible

Sometimes your requirements change on the fly during a project.  When that happens, survey the requirements change(s) and understand all the options you have to implement the change, instead of hastily reacting to the change and just coding around it as fast as possible--or worse, doing nothing.  

This can have big ramifications down the road.  

This is the same thing Peyton Manning does when he gets to the line of scrimmage - except in Peyton's case he's got plus-300-pound guys trying to crush him.  

So right off the bat, you know you've got that going for you.  

While you might decide to use a different API due to a requirements change, it's not much different than Peyton adjusting his blocking scheme and pass routes to ensure he doesn't get pancaked and can deliver another strike for a touchdown pass on a seam route in the red zone.  

I admit, this one doesn't have anything to do with being a fantasy GM, but I'm having too much fun to stop with the football analogies at this point.

Play the Matchups

Many times you will find there is more than one way to implement a SharePoint solution. And the pros and cons associated with each possible implementation pattern don’t make one approach a clear choice over the other. 

How many times have you heard the phrase “It Depends” when someone is discussing which way to build something in SharePoint? 

In such scenarios, you should obviously consider the factors I already discussed in this article.

However, you might need to go with your gut instinct and past experiences to make a decision.  A good example is choosing the REST API vs. the CSOM API.

If you poke around on the Internet, you’ll find differing opinions regarding whether you should you use the SharePoint REST API or the CSOM API.  If you are faced with such a decision, you might need to go with your gut instinct and also evaluate past experiences to choose one or another.

For example, if your development team has a lot of experience using CSOM, and it has worked well to develop applications that support your business, you might choose to go with CSOM over REST. That's because, for your team, it might require less transition for your developers and allow you to reuse helper libraries you have built around the CSOM API.

There’s a perfect fantasy-football parallel to this scenario--and his name is Jerome Bettis.  Many times over the years, all the fantasy experts would predict Jerome Bettis would score the same amount of points as another running back for a given week.  However, they always seemed to forget to draw on their past experiences when Bettis was playing my favorite team, the Cincinnati Bengals.

I know this story oh so well, and eventually, even though it pained me to do it, I would draft Bettis and make sure he was in my lineup every time he played my Bengals.  That guaranteed me at least two wins each season. 

This year, I’ve employed the same strategy by starting the defense who is playing the Jacksonville Jaguars each week.  Although it hasn’t proved to be as effective as Bettis vs. the Bengals from ’98-’02, it’s paid dividends.

At the end of the day, keep in mind the experience, libraries, and skillsets you and your team have as SharePoint developers. Go with the approaches that have worked for you time and again, provided they make sense for the future.

It Seems So Obvious…

Whether you're doing SharePoint development/architecture, or living the dream of a fantasy football GM, the main tenants of this article might seem like common sense, and I believe they truly are. 

However, over the years I’ve seen SharePoint implementations that have failed, and fantasy football teams that have underperformed, simply because folks didn’t take the time to think about these things up front or during the project/season.

Remember these things--do your homework, plan for and adapt to a changing environment, play the matchup--and you'll be successful in either endeavor.  Good luck with your SharePoint and fantasy football efforts now, and in the seasons to come.

Who-Dey!