Too Many Nodes, and Your Workflow Explodes!


Recently I had some issues with an SPD workflow I was making. I had 5 Start Approval Processes, and everything worked well. Then I had a requirement to break out one of the 5 processes into 2, so that made 6 approval processes altogether. And everyone knows that an SPD workflow can only handle 7000 nodes, right? I mean, who doesn’t know that?!? And you know that every Start Approval Process brings 1176 nodes with it, right? So simple math tells us that alone is 7056 nodes! About that same time the 2 step approval process got cut back to just one, so I was tried to cull parts of the processes that I THOUGHT WERE UNECESSARY. Turns out they were necessary and I had deleted the portion of the processes that actually created the tasks and emails! So I scrambled about for a day or so trying to figure out where the create task/email section was. Three hours before a status meeting about the workflow I decided to scrap the original and rebuild it using Collect Feedback processes. Collect Feedback processes have 1010 nodes each. Not lightweight, but lighter than the approval processes. Even with these lighter processes I had to cut back some of the other nodes in the workflow I myself had created. In any case, the moral of the story is that generally speaking the limit for Start Approval Processes in a workflow is 5, and 6 for Collect Feedback Processes.

Advertisements

Microsoft is Dead?!?


Seems every day I read about the death of SharePoint, should Microsoft kill SharePoint, etc. I’m not concerned. Remember the mainframe computer (or at least reading about them in Intro to Computers)? They were declared obsolete and a thing of the past over 20 years ago. Yet they are still churning away, reliably processing a gazillion records per second with nary a reboot and less than 5 seconds downtime per year! As far as computing has come, and as amazing as the devices we have now there hasn’t been a machine developed that can compete against the mainframe with the balance of power and reliability. And…mountains and mountains of legacy data are housed in the mainframe system. How does this relate to SharePoint, you ask? It runs on the Windows platform, which is as fragile as a snowflake is a forest fire. Companies have invested quite a lot of their IT infrastructure into Windows products, and they all integrate seamlessly with each other (just ask the marketing department). Plus, the Microsoft Office Suite. People can’t live without Word and Excel, and it’s a proven fact that executives crave the PowerPoint. While a Microsoft shop is not as deeply entrenched as the mainframe guys, the principle holds true. Change is difficult, and migrating all that data to something new is in most cases a bridge too far. Predicitng the end of this product or that company is nothing new. Consider this “Microsoft is Dead” article circa 2007.

http://www.paulgraham.com/microsoft.html

Is SharePoint as Difficult as Driving an F1 Car?


  After reading Joel Olesen’s article (http://www.collabshow.com/2013/09/26/do-consultants-really-matter-to-sharepoint-success-infographic-2/) about SharePoint deployment success I was reminded of an episode of Top Gear UK. In it Richard Hammond (a skilled performance car driver) was to drive a Formula One race car on a track. “How hard could it be?” he boasted. Apparently it is very hard. Take the steering wheel for instance (costs about $50k, and you thought SharePoint was expensive!) which has over 20 controls. As well, when entering a corner you must be traveling at a high rate of speed. The car must be going fast so that the front and rear wings can generate enough downforce coupled with the grip of warm tires, or the ($2.6M) car will go hurtling into the haybales! Check out that clip here: www.youtube.com/watch?v=9773pisjCSw

  My point is that many IT departments approach their SharePoint deployments in the same manner. How hard could it be, right? Just install the software, and send the URL to the companywide distro list. Piece of cake, we’ll be outta here by 7. Much like the Hamster’s F1 experience, the reality for most implementing SharePoint is that you need a good (pit) crew and experienced professionals to drive development, user adoption, security, governance, branding, etc. Anyone can roll the car out of the garage, but it takes a good crew to get it up to speed in the real world and keep it there. Spend the time to build a good team and think about all aspects of deployment, or risk crashing your deployment.

First Look at SharePoint 2013


I have built a SharePoint 2013 instance in the cloud using tutorial from Keith Mayer http://bit.ly/1888fj0. I’m very excited to get going with this thing, and see what 2013 can do out of the box! I just accepted a job offer, and the company will be migrating to SP2013 ASAP. Let me know in the comments below if you’ve found a great quick overview/tutorial to get me started. I’ll be poking around in it for the next few weeks.

A New Chapter!


It looks like I will be leaving my current job of almost 4 years. It’s been a good run, but it’s time to move on. It would be interesting to explore something in the private sector, but in any case I look forward to the next chapter of my career. I’m open to pretty much anything, but would prefer a job between Virginia and Central Florida on the east coast. I’ve got a lot of leads, just a matter of finding the right fit! Wish me luck!

Is SharePoint Right For My Organization?


I believe that the SharePoint platform is a good one, and can be a great benefit for many companies and organizations. SharePoint can do some things very well, and out of the box at that. However, it seems to me that the customer is rarely satisfied with the out of the box configuration or look and feel. And if that is the case, eventually I must ask why the customer chose SharePoint in the first place. Is it because the MS Office suite is firmly entrenched in your company? Were you inspired with the Microsoft’s latest ad campaign? My point is why did you buy a product when what you really desire looks nothing like that product? It’s sort of like a construction company buying a dump truck, then spending lots of time and money to make it go quickly round a racetrack.

 

Am I Getting Behind?


I’m still working with SharePoint 2010 because that is what my customer just migrated to. Am I getting too far behind in SharePoint land? I feel somewhat stressed because all the SP frontrunners are all talking about 2013, and one even mentioned SPNext! This is all overwhelming and I wonder if I’m hurting my career by not getting up to speed with 2013. Since my customer just went to 2010, I am still learning some things about that. Do I need to brush up on some 2013 courseware to stay abreast of the technology? Does anyone else feel like they are having a hard time staying afloat with SharePoint?

Degree in SharePoint?


The other day I was contacted by a recruiter for a SharePoint position. She was telling my about the job, and the mentioned that it required a 4 year degree. So in my reply email I asked what college taught SharePoint. She replied back that it was a learned skill. Exactly, I said! I realize that it’s desirable for IT people to have a wide range of knowledge, but isn’t there enough to learn and know about SharePoint that a degree should not be a hard requirement? Thoughts on this?

How Many SharePoint Pros do I Need?


What is the bare minimum staff that is needed to stand up and maintain a SharePoint instance? I know the answer to this question varies based on farm configuration, and what the organization intends to DO with SharePoint. Whether they want to use purely out of the box (does anyone really settle for that anymore?), or go heavy custom development with custom branding. But let’s assume that a company wants to implement SharePoint 2010 as chiefly an intranet collaboration platform for say 5000-10000 users. A 3-4 server farm with 5-10 site collections. They are pretty much ok with the look and feel, and will use the UI and SPD to perform any changes to it. No heaving branding needed, but maybe some color and font changes. What sort of staff is required to configure and run SharePoint given those circumstances?