| |
I can't tell you how many resumes I've read and interviews I've performed in the name of finding a quality SharePoint developer. After seeing my customer painstakingly struggle thru this same process, I finally decided to put together a couple short blurbs to cover what it is to be a SharePoint designer and a SharePoint developer.
I lump administration and design/customization together because I honestly believe you can't have one without the other -- at least to some extent -- but I'm obviously looking more for the latter than the former. Let me just say that, if I was building up a team to build SharePoint solutions, I'd want at least one of each of these types. Obviously, you'll want someone more focused on administration, if you're also doing operations work, but I'm more focused on building solutions than hostings.
SharePoint Administrator/Designer
Experienced SharePoint administrator with a strong emphasis on customization. Extensive experience with SharePoint Designer and InfoPath are a must, as is a moderate ability to create customized web parts using a mixture of HTML, CSS, JavaScript, and XSL (i.e. using a Data View Web Part). Should at least have an understanding of:
- IIS/SharePoint troubleshooting (i.e. event and ULS logs)
- How to customize branding
- SharePoint Designer workflows
- InfoPath forms
- Applicability and use of content types
- SharePoint web service interfaces
- Feature deployment
- Standard features (i.e. search/indexing, content management, and Shared Service Providers (SSPs))
- Enterprise features (i.e. Forms Server, Excel Calculation Services, and Business Data Catalog (BDC))
- Reporting and business intelligence (BI)
- Security concerns and audience targeting
Experience with PowerShell and ASP.NET development are a huge plus.
SharePoint Developer
Strong ASP.NET (C#) developer with experience building and deploying fully-automated SharePoint solutions. Must have an understanding of at least:
- Standard ASP.NET (including membership providers and their applicability to SharePoint)
- SharePoint object model and web service interfaces
- SharePoint feature packaging and deployment
- Web parts and web part connections
- SharePoint branding components
- Applicability and use of content types
- SharePoint-hosted workflows
- Standard features (i.e. search/indexing, content management, and Shared Service Providers (SSPs))
- Enterprise features (i.e. Forms Server, Excel Calculation Services, and Business Data Catalog (BDC))
- Reporting and business intelligence (BI)
Above all, developers are expected to "live" in Visual Studio, yet be ablet o identify when SharePoint Designer and/or InfoPath would be more pragmatic -- and follow through with such a solution.
Senior developers and software architects must have broad, hands-on experience across the entire software development lifecycle with formal engineering processes. Experience with defining and documenting an applicable taxonomy and governance plan is a must.
If you're interested in building SharePoint solutions, I highly recommend you find where you fit within these two descriptions. There's plenty of room to grow, but they cover the foundations I -- and many others -- look for when building out SharePoint teams.
Good luck and happy job hunting!
Working with the SharePoint object model can sometimes be a pain. Specifically, when you need to get a lot of information from multiple sources, it can become a very painful experience when you have to write pages of code to do something that takes entirely too long. I've heard of one case that took hours to accomplish in the object model, but querying the database directly brought that down to minutes. The question here is, what's supported. The typical dogma is that SharePoint databases are completely off limits. I have to admit this is something I wanted a bit more proof of. It reminds me of the unfounded rumors people sometimes spread without realizing it.
Adam Ruderman pointed me to SharePoint Database Access on MSDN that states, "Direct modification of the SharePoint database or its data is not recommended because it puts the environment in an unsupported state." I was hoping for something within the license, but this is good enough for me. Now, I know I can treat a SharePoint database as a read-only data source. Of course, I'd strongly recommend people avoid such a practice. I simply wanted to know for those odd-ball scenarios where the object model just doesn't cut it performance-wise.
If you're looking for something that covers supportability of changes to the database, you can also check out Support for changes to the databases that are used by Office server products and by Windows SharePoint Services, which talks about the supportability aspects we're actually concerned with.
It's been entirely too long. I've had a new project take over my life for the past few months. I'm trying to get back into things and catch up with the blogs I read, but it's sometimes hard. This is my first big SharePoint-based project and I have to say it's been "an experience." If you're a developer and you haven't heard about how much SharePoint has been taking over, you've probably been living/working in a cave. It's amazing. I've learned a lot, with respect to SharePoint, and I can sum it all up with this: SharePoint is the new VB. I don't say this from the drag-n-drop point of view that made VB so easy to use, but from the ease in which you can get something done. To put it another way, SharePoint is to hobbyist web "developers" what VB was to hobbyist client-side "developers." I say "developers" for a reason. I've been very clear about my thoughts on hobbyists, so I'm not going to get into that.
Perhaps the best way to put it is to liken SharePoint "development" to the creation of a Rube Goldberg device. And, if you want to throw in AJAX features and a standard user experience that looks/feels nothing like SharePoint... well, let's just say you have your work cut out for you. As if portal development wasn't odd enough with respect to deployment. All I can deduce is that SharePoint was built for tech savvy users (not even power users) and not developers... definitely not developers.
As most who know me already know, I've been a fan of DotNetNuke (DNN) for quite a while and even worked on the dev team for a few of the modules. I feel lucky to have gone thru that because DNN gave me a nice perspective to some key issues around portal development. It's also let me experience the difference between portals built for developers instead of for users. This is the key difference between SharePoint and DNN. I know there's been a lot of talk in the past about differences, but it all comes down to that. SharePoint has the polish necessary to make your portal much more user-friendly and feature-complete, but DNN has the dev backing to make it a breeze. I'm really hard-pressed to pick a favorite, that's for sure. I've been in talks with a few key people within the DNN and Microsoft teams to get more involved with DNN in an official capacity, but I think I'm going to back off of that. Between the two portals, I see SharePoint having the most promise for the future. DNN is fantastic and I'll continue to recommend it where it makes sense, but SharePoint is much more powerful. The big hole in SharePoint is the developer experience. I see this as a huge opportunity.
More and more, I hear about how we need to focus on specific technologies. I'm not the type to whole-heartedly dig in to a single technology from top-to-bottom, but I do see value in filling this gap. The training I continue to see around SharePoint is all about small-time hacks. We need an enterprise solution. Some true patterns and practices for enterprise SharePoint development. Given the Rube-Goldberg-ian nature of SharePoint, this may be hard, but someone has to do it. Of course, this is all going to depend on the project opportunities I have. For now, it's just a bag of thoughts I've thrown together, but I'm hoping I'll have a chance to sort them out and pull it all together in the future.
There's so much more I could say about SharePoint, DNN, and the other things I've mentioned here, but I've babbled on long enough.
|
|
|
|