Become a SharePoint Professional – Understanding The Architect Role

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.

Finally!

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)

.b

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!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

17 thoughts on “Become a SharePoint Professional – Understanding The Architect Role”

  1. The case study idea is a great suggestion. Coming up with project ideas for practice is always difficult.

  2. I got my start with SharePoint in a mid sized business where I was THE sharepoint guy. I took a week course on sharepoint development to get started and over a year and a half I created a multi-tenant document sharing/project management portal.

    This post seems to take the “large corporation” perspective where you have “sharepoint developers”, “sharepoint administrators”, “sharepoint architects”, and so on. In my limited experience I play all of those roles and I think it makes me better at the individual tasks. By necessity I focus more on breadth of knowledge and when I need specific development knowledge I read the documentation, blog posts, and on occasion a book to get familiar with it.

    However, I’ve found some disadvantages to this approach. I haven’t used any of the “Enterprise” features of SharePoint and have always worked with the “free” version features. I’ve never had to design a set of content types since my project requirements haven’t really needed them.

    My question is: What’s the best way to learn? In a large corporation where you can get “really good” at a few features of SharePoint, or take the “Jack of all trades, master of [one|two]” approach.

    1. Jim,

      Great question! Learning is a great passion of mine and I’ve spent a large amout of time figuring out how to best learn and teach SharePoint. I think I’ll actually do a separate post on “how to learn” towards the end of the series. You’re not the first to ask.

      However, keep in mind that the path you take for learning greatly depends on which role you play. The approach may greatly vary between a developer who needs hands-on technical experience, and an architect who needs exposure to different scenarios with varying requirements.

      A list of links or “just go read this book” isn’t helpful at all (not to say you shouldn’t buy my books, though 🙂 ) because people learn in different ways. Reading books may work great for some, while others need videos or hands-on experience. Availability of material is also a limiting factor.

      As such, I think I’ll focus more on understanding the ways people learn rather than giving a list of links to read. Understanding your own preference makes it more likely that you’ll find the resources that gives you the best return on your learning investment.

      What do you think of that approach?

  3. Very good post! But where do I find good case studies to learn from that go beyond rewriting of documentation and “Hello World” examples but cover complex real world scenarios?

  4. This is one of my favorite articles you’ve ever written, Bjørn. Your points and definitions are spot on, and I second your thanks to Paul Culmsee. He is truly a visionary in this area!

  5. This is a great post, I was going to post a question on SPYam site about what people thought about the title SharePoint Architect and this answers my question exactly and confirmed what I thought.

    One thing, your link to the “Heretic’s Guide to Best Practices” just takes you to a “parking” page. His site must be down.

      1. Thanks Bjorn for the mention (bloody typical the domain expired the day this was published). Thanks Erica for the support.

        There were a couple of points that Bjorn and I talked about that didn’t make this article, and I don’t want to spoil it if Bjorn is planning to use them in the next post. But one I will mention here that is important.

        I’ve moved into strategic planning at exec level – its a byproduct of the sensemaking techniques I use. naturally this experience has helped form my current perspective. With that in mind, its really important “breadth of skills” is not just taken for granted. Bjorn hinted at this in an above reply when he spoke of a post about how to learn.

        Breadth of skills doesn’t cut the mustard for me. You can have breadth of skills but still be an analytical thinker who breaks a problem up into bits and then tried to optimise the bits. What an architect needs to do is to be able to picture the whole, as well as the parts, and be a synthetic thinker (and for the nerds, google “systems thinking” or “design thinking”).

        Why is this important? Check out this post on 2020 workforce skills.. These is your SharePoint architect job description right therr!

        http://www.iftf.org/system/files/deliverable/IFTF_FutureWorkSkillsSummary.gif

        My personal fav’s are:

        Greatly increased sense-making, because that’s what smart machines and systems have left for you…One of the few things they can’t do for you.

        Cognitive load management, which is another way of saying that you have to take 100% ownership of all the overload and chaos coming at you — and constantly cut through clutter and crap to find the meaningful stuff.

        Novel and adaptive thinking will need to be led by a design mindset because each new adaptive idea and behavior change will require you to design a lot of your own paths to execution.

        regards

        Paul

  6. I really enjoyed this post. I especially liked your tips for practicing and maintaining your skills which can certainly be difficult depending on current job responsibilities, project assignments, etc.

    Thanks for taking the time to share your valuable thoughts!

  7. Hi Bjorn,

    I believe I was also in the category that thinks just by being an architect in SharePoint means the person has to know the ins and outs of SharePoint. I have worked under two “prominent” (pun intended) SharePoint “experts” (again, another intended pun) who just by having MCP in SharePoint has led people, me included, to believe they are the “experts” when they barely scratch the surface of SharePoint. Even I have more expertise as compare to them in issues with SharePoint administration. Few incidents provide me the epiphanies that being a SharePoint architect is more like a person should know the best architectural design for SharePoint based on the user requirements, knowing the hardware limitations and whether to use multi-farm deployment and what not. This has led me to bestow more respect to those who have done code-level development in SharePoint and have moved on to be an architect, not those who just add SharePoint as one of its portfolio as Principal Software Consultant!

    Also I view MCP in SharePoint certification as a piece of crap, considering that you can pass the exam(s) by reading the questions from the Internet! This is akin to a fresh undergraduate getting an MBA! Only after years (this can be 1 to x years, depending on the extent of involvement in SharePoint’s wide horizon of development) of experience in SharePoint, and then getting the certification can be seen as an acknowledgement of the experience garnered to substantiate one’s expertise! And yes I don’t ave the certification yet since it is pointless to have one now that SharePoint 2013 might be out soon!

    Louis

  8. Bjorn,

    This is an important article – thanks for posting it. I brought up your suggestion of “thinking about the next steps in a more complex scenario” once a project is complete in a team meeting today and everyone is excited about making this part of our post-mortems.

    I was a little dissapointed though – aren’t your blog posts usually designed to incite riots? This one will barely raise people’s blood pressure 😉

  9. Something we don’t have enough of in the SharePoint field is guidance on how to approach architecture and consulting engagements. I’m not saying that everyone should follow the same path towards designing a solution or infrastructure – but I think we all see our fair share of crappy design documents and powerpoint architectures. One size certainly doesn’t fit all, but I see room for a community-led initiative here…

    1. Thomas,

      I think a major challenge in this is that so much of SharePoint is subject to the ID factor (It Depends). Although there certainly are guidances on various components whether infrastructure, security, or features, both official and community, these often fall short of ‘real life’ because each project has ID components that mess up the neatness of the designs.

      .b

  10. Hi,

    Great article and off course addition of knowledge. I have recently got the SharePoint solution architect position in my company on the basis of my strong technical knowledge in SharePoint. I would like suggestion and guideline to start my career in architect level.
    1) How to start
    2) where to start
    3) What things should be handled initially to improve my architect level.
    4) What basic things I need to understand before starting it,
    5) How come I will look like Architect in the beginning.

    There are so many question I have and will have have once I will start it. Will let you know one by one times come.

    Would be very thankful if you guide me of above question.

    Thanks,
    Nitinkumar Kakulde

Leave a Reply

Your email address will not be published.