One of the most misunderstood career paths in SharePoint is that of the architect. These roles retain some of their mystery because people do not understand them well but perhaps also because the title “Architect” in other fields is often considered a higher status profession.
The confusion seems to stem from many developers or administrators looking to ‘advance’ into becoming an architect. This idea seems silly to me; in fact, I’ve previously argued that going from being a technical performer to an architect is a disadvantage.
In truth, however, an IT architect is just like any other profession and you advance in your career as you do in any other job. You start from scratch, you learn, and you become a better architect.
In this series, called Becoming a SharePoint Professional (read the other articles at the bottom of this article), I’m trying to enlighten you on what it means to become and be a SharePoint professional. In this article, I’ll be focusing on the SharePoint architect and what becoming an architect entails.
The Role of an Architect
In SharePoint an architect is not necessarily a technical role at all. Many of the greatest architects I’ve known have little or no hands-on technical experience at all. Rather than knowing how to do something, what they know is what is possible and what makes sense.
For this reason, an architect is a horizontal role in that their greatest strength comes from breadth of knowledge rather than depth of expertise. An architect needs to weigh countless options against each other and pick the ones that best solve the requirements.
Architects work on finding out what to do rather than how to do it. They work from a set of requirements or goals and then pick the components required to reach that goal. They work in close company with soft-skill professionals like business analysts, project managers, and so on, but also with technical performers like pure developers and administrators. Once an architect has completed their work, they hand over a design or architecture to technical performers who them implement that design.
An architect needs to be able to construct massively complex grids of capabilities. Every selected feature has both opportunities and challenges, and these need to match, not just to the requirements, but to all other selected features as well. Knowing all the capabilities of all available features and components is in itself a huge challenge, but being able to put them all together to solve the requirements without causing too many side effects is the task of a master.
Note: My argument against going from a technical role to an architect role is in short that a technical role is a role that focuses on few or one area in depth, which is exactly the opposite of what an architect should do. A previously technical-role architect will likely tend to prefer the methods and options with which they are familiar, making them bad architects.
IT architects come in many flavors, even in SharePoint. Saying you’re a SharePoint architect means about as much as saying you’re a SharePoint developer. Sure, I know you design or architect things, but do you architect solutions, infrastructure, security, information, or what?
Although you’ll find architects that work in multiple disciplines, keep in mind that, as with all professions, if you split your profession over multiple disciplines you will not be able to go as deep into each area.
For example, a SharePoint solutions architect specializes in knowing as much as possible about capabilities of various features and components in SharePoint and even other platforms like Office, Exchange, Lync, and so on. This is a massive undertaking, and to be good at it, or for it to yield an actual return on investment for the training you need, you need to focus.
If in addition you start to work as an information architect, where your tasks will be to understand the business taxonomies and architect information management system to support those, you’ll find a completely new discipline that will take attention away from your solutions architecture practice. You won’t excel in all disciplines, or even many. Like developers or administrator, if you want to become an expert, you need to focus.
In short, however, think of architects not as advanced developers or administrators, but rather as breadth-first practitioners within those disciplines, who know a massive amount of topics to only a small extent. This means that there are ‘developer’ discipline architects that essentially architect building and development, and there are ‘administrator’ discipline architects that essentially architect management and operations.
Finally, keep in mind that we are only talking about SharePoint architects so far. However, there are many architect roles that are not SharePoint specific but are still relevant to SharePoint professionals. For example, a solutions architect (not to be confused with a SharePoint solutions architect) focuses on solutions in general, where SharePoint is just one option. These solution architects pick SharePoint as a tool, but doesn’t necessarily know SharePoint features or components in detail. They then hand over the architecture and requirements to a SharePoint architect who can then pick the required features and components.
Note: This all comes down to another problem with IT, the ambiguity of titles, but I’ll leave that for a separate post.
The Path of Becoming an Architect
I sometimes hear SharePoint professionals say that you cannot have junior architects, because all architects are in senior roles. This may be correct, but probably not in the way you think. Many current architects have extensive experience. They move into their new career after having spent years doing other disciplines, such as development, infrastructure, security, or similar technical professions. However, there’s nothing preventing you from starting out in a career as an architect from scratch.
When moving into a new career, experience may be a good thing because it usually means you are older and have been exposed to more situations from which you can learn. This isn’t unique to architects; for an experienced administrator to move into development, for example, their life experience means they will have a head start on many of their younger and less experienced colleagues.
You become and architect just like any other profession. You start with the architect’s version of your first “Hello World” solution, and from that point on, you are an architect, albeit not more than a developer would be a developer after creating their first “Hello World” application, or an administrator would be an administrator after doing their first spouse-mode install (and adds a “Hello World” web part to their wizard-created site).
Architects, like developers and administrators, start out by doing simple tasks to build their experience and confidence. Perhaps setting up a site for your department, or even just designing the document structure for a single library. Perhaps you’re onto the infrastructure path so you figure out what hardware you need to run a single department SharePoint solution.
These tasks are simple, but expose you to some of the considerations you need to make in your future career. From these simple tasks, and don’t feel ashamed to repeat them for experience or make failure to get a few burned fingers, you advance to more advanced scenarios.
Advancing Your Architecture Skills
If your time and job description allows, don’t waste time after a project, but immediately start to think about the next steps in a more complex scenario, even if you know for a fact that a more complex scenario will never happen for this project. What would your solution look like if it were scaled to five times its current size? What if you had three times the number of document types? What if there was a need for external user access? What if you had to support a rapid restore after a critical breakdown?
As an architect, your skill set includes thinking two or three stages ahead of your current project, so after you’ve completed your first and simpler projects, start practicing on the thought pattern. By doing so, even if the project never moves ahead, you will see your simpler project in a new light. Perhaps you didn’t take into account that when you add three new departments to your solution, your chosen solution isn’t scalable enough. Good! You’ve just gained experience that will help you in your next project. Perhaps you didn’t consider changing document requirements in your taxonomy solution. Great! You’ll not make the same mistake again.
Next time you are asked to create a new department site or a document taxonomy, you’ll have these new and imaginary experiences to help you along, and you’ll architect a solution that is better than your first one.
Congratulations, you’ve improved.
Eventually, you’ll start working on larger projects, for example if your organization is satisfied with the work you did for your department and want to do a larger SharePoint deployment. By the time you get to this point, you should have architected several smaller installations already, you’ll have joined the SharePoint community to have a peer network from which to learn, and you’ll have confidence in your own abilities.
The point here, though, is there in no part of the path is there a stop that say “now, go be a SharePoint developer for a few years” or “now, manage your servers for a couple of years to build experience”. You don’t build experience as an architect by working as a developer or administrator, no more than you build experience as a chef by eating a lot or selling food at a convenience store. Granted, these are related tasks, but if you want to be a better chef, you need to cook, and if you want to be a better architect, you need to architect.
Similarly, there’s no ‘exit’ path after you’ve reached a certain skill level. You don’t naturally ‘advance’ from being the world’s greatest food eater to be a great chef, nor from being a chef to a grocery store manager, even if all of these are related to food. Great developers don’t become great solutions architects by advancement; a developer who wants to become an architect starts from the bottom, just like anyone else. You don’t become a business analyst as a natural progression from an architect role; if you want to become a business analyst, you start from the bottom, just like anyone else.
Your path of advancement in your career is usually within that discipline, so your advancement path as an architect is to become a great architect, and the advancement path as a developer is to become a great developer.
I Have No Projects!
If you work for a single organization and as an architect primarily for that organization, you might end up with spare time where you don’t get to practice your skills.
Here’s an exercise I did in my early days as an aspiring SharePoint infrastructure architect (and if you didn’t know, I originally started out on the path towards SharePoint administration). Look through case studies posted for SharePoint solutions, and focus on the areas of requirements. In fact, stop reading after finding and understanding the requirements. That’s where you’ll spend most of your architect time in any case.
Then, based on the usually limited requirement information you find in those case studies, start architecting the solution. If you are stuck in one area, for example the scale of servers, read requirements again, and see if there are other factors you can address. These may reveal clues that can help you solve your original problem of scale.
After a while, you’ll be stuck for good, and you won’t be able to go further. That’s OK, at this point, you have a ton of questions you need to ask and get answered to move on. You also have, and this is why you’ll want to use a case study, the solution so that you can verify your own suggestions and learn from what the organization in the case study chose.
In addition, the questions you have are important because you’ll find the same problems in other real-life situations. By knowing in advance what questions you need answered, you also know more about what you need for your next project.
Well, we’re still not done yet, at least not with the series. I still have many questions for you to ask.
Before I end this article, however, I’d like to send out a special thanks to Paul Culmsee for helping me with this article. I often reach out to Paul when I need feedback on topics and articles, and he always brings valuable insight to the table. I highly recommend checking out his book Heretic’s Guide to Best Practices (he made me say that).
Don’t forget: if you have questions you want answered about becoming a SharePoint professional, the comment field below is your place to ask. The series is still under development and I’ll be happy to answer questions if they’re appropriate.
Of course, you can also check out the articles in the series navigation below (or, if reading this elsewhere, view the entire Becoming a SharePoint Professional series here)
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!