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 the requirements again, and see whether
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, because 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 to do.
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.
About the Author
Bjørn Christoffer Thorsmæhlum Furuknap is a senior solutions
architect, published author, speaker, and passionate
SharePointaholic. He has been doing software development
professionally since 1993 for small companies as well as
multinational corporations.
About Understanding SharePoint Journal
Understanding SharePoint Journal is a periodical published by USPJA Publishing LLC. The
journal covers few topics in each issue, focusing to teach a deeper understanding of each topic
while showing how to use SharePoint in real-life scenarios.
You can read more about USP Journal, as well as get other issues and sign up for regular
updates, discounts, and previews of upcoming issues, at http://www.uspjournal.com/ .
You can download whole book on the following link http://sharepoint-career.com/
