The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint
For some time now, I’ve felt the need to set down my thoughts on the power of development in the Middle Tier for SharePoint. Today, I’m publishing the first edition of my white paper The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint. I say ‘first edition’ because the days of spending a lot of money to print a white paper and distribute it widely are long gone. I expect to and want to develop these ideas over time based on input from you, the SharePoint community.
In this white paper, I lay out the methods and rationale for preferring to develop for SharePoint using SharePoint Designer and a combination of the Data View Web Part, scripting, and CSS over managed code. For quite a long time this is where I’ve focused my development efforts for clients and was part of the genesis for the jQuery Library for SharePoint Web Services (SPServices). I find that developing in the Middle Tier using SharePoint Designer can be faster, more reliable, and cheaper than the managed code approach.
I expect that some of you may well disagree with this premise and I know that others will absolutely agree with it; I welcome the debate. Take a read of the white paper and let me know what you think.
Thanks to Michael Greene (@webdes03) and Jim Bob Howard (@jbhoward) for their input on early drafts.
Back in January there were some heated debates about the use of jQuery and whether it had any place in a solution provider’s toolkit. I wrote an article about SharePoint Dev and Customization Paths (http://nextconnect.blogspot.com/2010/01/sharepoint-dev-and-customization-paths.html) and I think it applies very well to this discussion. I believe in having options and applying the correct path for a given problem. Not every problem should be built with managed code, and in some cases or environments ad-hoc customizations are not appropriate. More than anything the architect needs to be educated in the decision points and needs to work to help educate the decision makers.
I have been in a few environments where there was a strict rule that there can be no server solutions. To me that is just as wrong as an environment that promotes a strict rule of no SharePoint Designer customizations.
Understand the problem, and select an appropriate solution. Don’t let your preferred approach dictate a solution.
Hi Mark,
David in Japan here. (aka the bank you did work for). Been offline for a while as had another battle with cancer. Won this time as well. Have been catching up on all your work. Love the Middle Tier Manifesto as it addresses a number of good points with SharePoint that large orgs can have.
Can wait to get my teeth into your jquery library and give it a spin. cheers
d
David:
Good to hear from you and that you are back in the saddle! I’ll be interested in your experience and take on SPServices. My experiences with “the bank” have informed my opinions in the Middle Tier Manifesto, for sure.
M.
Mark,
First thanks for taking the time to author such a paper for the community. I agree with nearly all of the article content. I agree with Todd that to Developers the term Middle Tier has a very specific meaning that may be confusing when applying term to SPD based customizations
After reading the white paper and the comments posted so far I feel that your concept is sound.
My feeling is that the Scripting Tier should be considered much more often than it is by businesses and consultants trying to provide solutions. The power of this layer of tools is often overlooked when development plans are being constructed.
Scripting is a development tool, and I categorize JavaScript, jQuery, XML, XSLT, CAML, etc. as scripting languages. Scripting is a valuable tool in the SharePoint environment, that is the bottom line, no matter what you call it.
Although I was sent a link to the manifesto a few weeks ago, I have not had an opportunity to read it yet. However, given some of the comments I’ve seen here, I felt it necessary to give some insight into my “development” world.
First, let me preface by saying that I have 7 years of strong java web app/Oracle db experience. My last project involved a ton of XSLT. In short, there is no question that my background is solid development.
I work for one of the largest defense contractors in the US. The point there is, we have over 46,000 employees and a very large corporate IT department. We are further divided into business units and divisions – each with a few IT employees for corporate work and many others for various contracts throughout the world. All corporate systems are developed/maintained by corporate IT – purpose being consolidation saves money. However, customization is necessary as reporting and management requirements vary across the corporate map.
The nature of our business is contract support – mostly government contracts. As contracts vary, reporting requirements to the customer vary as do the management structure, communication methods, IT processes, etc. Over the years, this has lead to the creation of many different systems that essentially perform the same function, but have enough differences that consolidation efforts get really ugly. People get angry when their custom functionality or reports are omitted. Other people jump the chain to make sure their requirements are coded ahead of other requirements. You get the picture.
Such is the world in which I live. I have 2 corporate-developed SharePoint “tools” that were created out of this mess of similar applications and since these tools are corporate standards, it is my job to customize them to meet the individual needs of various PMOs, contracts and proposals throughout the company. Given that these tools are corporate-developed but I am not a corporate developer, but a business unit technology resource, I am not allowed server access. The best I can get is Site Admin rights. I cannot access log files, create deployments, install features or additional webparts or write any customized code. I am not even given a development or test site.
When I was doing government contract work, we were not allowed to use the terms “application” or “development” as those efforts were supposed to be done by newly, base-wide, consolidated development teams that did not have any ties to the branch or mission which used the systems. These teams would rack and stack all development requirements across all consolidated systems, both bug fixes and enhancements, and vote on them in committee. What’s more, “development” dollars were not in the same bucket as “maintenance and support” dollars, so any enhancements requested were at the mercy of the overall IT budget, not the individual budgets for each mission.
I think you can see where I’m going with all of this but I’ll just summarize in case it’s not clear. There are a lot of enviroments out there that, for one reason or another, absolutely will not allow compiled code solutions (deployments,etc.). In these places, it is imperative to have people who are resourceful enough to find solutions they can customize without expensive tools, formal IT intervention and bureaucratic processes. Otherwise, nothing would ever get done because it would never be approved, resulting in lost contracts and other business opportunities, as well as safety incidents for our warfighters.
This is the strength of SharePoint, in my opinion. Yes, you can build full-blown, complex, custom apps if necessary – but I believe that a lot of projects can be successfully created by customizing what SharePoint provides OOTB. Sure, some of those solutions won’t be as efficient or may take longer to complete, but they still have a place in environments that are crippling to the application development process.