A student at USPJ Academy asked what to start reading to become a SharePoint architect. What skills are required and what roles should an architect fill?
Here’s my response:
I speak mostly from a solution architect perspective, since that’s what I do, but I’m certain that other architects may contribute more. Pending other people responding, allow me to share my view of the question.
The role of a solution architect is primarily selecting the methods and features in a solution. That means essentially that you look at the requirements of the solution and map those requirements to the appropriate SharePoint feature.
There are other types of architects, however. For example, an infrastructure architect would not work on feature selection for a solution but rather on topology design, selecting the right topology, server types, networking infrastructure, and so on. A business architect would look more at the soft skill requirements, mapping business processes to the right process management tools, finding the right information architecture, and so on.
Common to all these architect types is their skill and knowledge of capabilities. You need to know a whole lot about what features (literal features, not SharePoint features) are available and what the capabilities of these features are.
That does not mean that you need deep knowledge in any particular field, but it does mean you need breadth of knowledge; a vast breadth.
Let me take one example of this. When a client or project asks you to find the best way to surface employee skills and experience, you need to know all available options and which options offer what features so you can map those features to the specific requirements. Perhaps the user profile service would be good, but you may get away with a user information list, a CV document database, or you may have to develop a custom solution or even add features to extend current services.
If the skills and experience data already exists, you need to know if connecting to any existing data store is possible and feasible, meaning you need to know a whole lot about what the connectivity services can offer.
Perhaps all data is stored in Word documents today, but the client wants it searchable and filterable by field, meaning you need to know about the capabilities of customizing search and indexing.
Note that knowing about the capabilities does not necessarily mean you’ll need to know the specific details about how to perform these tasks. That is the task of specialists such as various developers in this particular example. Many architects have no technical skill at all, they merely know very well what the capabilities of the platform is and can select the features they need and hire the specialists to do those tasks.
That said, most architects come for a specialist background. For developers, I think that this is an ego problem, because we see all the power we get when we know how to create something, and that power goes to our heads. Not my head, of course, I’ve had this ego since I was a child.
Does that mean that good architects come from specialist backgrounds? No, quite the contrary. In fact, I find myself severely limited by my developers passion and background because I tend to know in code what I want accomplished rather than which feature may provide most of the functionality out-of-the-box. As may be evident from the recent debates around out-of-the-box features in SharePoint, I often spend less time writing something from scratch than I do understanding available features and utilizing those.
My ‘quick way out’ is to develop from scratch. An architect with no technical skill would not have that option and would thus be forced to adhere more to the ‘correct’ definition of an architect, one that select features and not necessarily develop them.
I hope this gives you some insight, although it may not give you a shopping list of books to read