1. An architect’s job – “to create a technical solution that solves the business problem while complementing the company’s overall technology strategy”.
2. Architecture Principal #1 – “The architect is the conduit between the business problem and the technical solution”.
The above two statements give a clear summary of what an architect’s job is. So, how does that relate to the practice of developing against SharePoint? In my opinion, there shouldn’t be any difference between an architect on a custom application development project and a SharePoint development solution.
Recently I spoke at a SharePoint conference in the Washington D.C area and in between my sessions there was an open forum on the state of the SharePoint job market. During this open forum they discussed an issue in the SharePoint market today. The issue is recruiters, and general business owners, seem to think they can use someone that “knows” SharePoint to configure and develop their systems. However, this “jack of all trades” rarely exists in the SharePoint world. Thus, it is becoming best practice to break SharePoint gurus up into two categories: 1. Operations/Administration 2. Development. During this conference they also promoted the idea of the “Power User” in SharePoint. This is a person that does not know the administration/operations side of SharePoint and does not know the development side. However, this person knows how to configure and manipulate the SharePoint site from the UI.
After leaving this session at the conference I was confused how the SharePoint architect was never mentioned. I understand that this role was grouped into the development category. However, I see this oversight a lot in the SharePoint world. So, why is the SharePoint architect overlooked?
There are probably multiple reasons for why the SharePoint architect is overlooked. I think it is because SharePoint is a framework that works out of the box, so people who don’t understand it fully think it is “easy” to customize. Then, once they start the customization/development effort, they realize they might be in over their heads.
The issue with the above mentality is that a complicated framework needs an architect as much, if not more, than a custom application development project. The SharePoint architect not only needs to understand all the best practice and architectural decisions in .net, but they also need to have a full understanding of the SharePoint framework. Plus, the SharePoint architect needs to create a delicate balance between the custom development effort and the SharePoint framework.
The SharePoint framework can be a complicated framework when customizations need to be done to it. The reason for this is because SharePoint does a lot. When you have a framework that does so much it is hard to develop against it because you must understand the nuances of all aspects of the framework. I have heard the argument that other frameworks are easier to work with than SharePoint. While this might be true, it is a hard statement to evaluate. Most other frameworks concentrate on one aspect (Content Management for example). Thus, if you learn how to work with that one aspect of the other framework, then you have learned how to work with the entire framework. SharePoint’s overall scope of features force the developer to learn to work with many aspects, thus making it seem harder to develop against.
The SharePoint architect should be a developer who can:
Understand almost all aspects of how to work with the SharePoint framework.
Develop a structure to make it easier for other developers to work with the SharePoint framework.
Make the decision on whether a SharePoint feature can help solve the business problem or if a custom development task within SharePoint needs to be done.
Abide to the same architectural principals of an architect on a custom application development project.
In summary:
We need SharePoint Architects! You can’t just get someone who knows how to configure and/or develop the product and put them in charge. All the architectural considerations need to be taken into consideration: scalability, fault tolerance, maintainability, repeatability, deployment etc. It may seem like you just install SharePoint and all that is magically taken care of but, it’s not.
We need SharePoint Architects who are Architects! An architect is an architect. Just because you put SharePoint (or BizTalk, SOA or whatever) in front of that title, it doesn’t mean the game changes. Everything you know to be correct still applies: patterns, picking best practices, testability, etc. You’ve just added a new (incredibly complex) layer to deal with.
2. Architecture Principal #1 – “The architect is the conduit between the business problem and the technical solution”.
The above two statements give a clear summary of what an architect’s job is. So, how does that relate to the practice of developing against SharePoint? In my opinion, there shouldn’t be any difference between an architect on a custom application development project and a SharePoint development solution.
Recently I spoke at a SharePoint conference in the Washington D.C area and in between my sessions there was an open forum on the state of the SharePoint job market. During this open forum they discussed an issue in the SharePoint market today. The issue is recruiters, and general business owners, seem to think they can use someone that “knows” SharePoint to configure and develop their systems. However, this “jack of all trades” rarely exists in the SharePoint world. Thus, it is becoming best practice to break SharePoint gurus up into two categories: 1. Operations/Administration 2. Development. During this conference they also promoted the idea of the “Power User” in SharePoint. This is a person that does not know the administration/operations side of SharePoint and does not know the development side. However, this person knows how to configure and manipulate the SharePoint site from the UI.
After leaving this session at the conference I was confused how the SharePoint architect was never mentioned. I understand that this role was grouped into the development category. However, I see this oversight a lot in the SharePoint world. So, why is the SharePoint architect overlooked?
There are probably multiple reasons for why the SharePoint architect is overlooked. I think it is because SharePoint is a framework that works out of the box, so people who don’t understand it fully think it is “easy” to customize. Then, once they start the customization/development effort, they realize they might be in over their heads.
The issue with the above mentality is that a complicated framework needs an architect as much, if not more, than a custom application development project. The SharePoint architect not only needs to understand all the best practice and architectural decisions in .net, but they also need to have a full understanding of the SharePoint framework. Plus, the SharePoint architect needs to create a delicate balance between the custom development effort and the SharePoint framework.
The SharePoint framework can be a complicated framework when customizations need to be done to it. The reason for this is because SharePoint does a lot. When you have a framework that does so much it is hard to develop against it because you must understand the nuances of all aspects of the framework. I have heard the argument that other frameworks are easier to work with than SharePoint. While this might be true, it is a hard statement to evaluate. Most other frameworks concentrate on one aspect (Content Management for example). Thus, if you learn how to work with that one aspect of the other framework, then you have learned how to work with the entire framework. SharePoint’s overall scope of features force the developer to learn to work with many aspects, thus making it seem harder to develop against.
The SharePoint architect should be a developer who can:
Understand almost all aspects of how to work with the SharePoint framework.
Develop a structure to make it easier for other developers to work with the SharePoint framework.
Make the decision on whether a SharePoint feature can help solve the business problem or if a custom development task within SharePoint needs to be done.
Abide to the same architectural principals of an architect on a custom application development project.
In summary:
We need SharePoint Architects! You can’t just get someone who knows how to configure and/or develop the product and put them in charge. All the architectural considerations need to be taken into consideration: scalability, fault tolerance, maintainability, repeatability, deployment etc. It may seem like you just install SharePoint and all that is magically taken care of but, it’s not.
We need SharePoint Architects who are Architects! An architect is an architect. Just because you put SharePoint (or BizTalk, SOA or whatever) in front of that title, it doesn’t mean the game changes. Everything you know to be correct still applies: patterns, picking best practices, testability, etc. You’ve just added a new (incredibly complex) layer to deal with.
Comments
Post a Comment