Make Implementing SharePoint Easier Using the 4 Architectures

SharePoint is probably one of the best money-saving content management systems on the market today. More than a few organizations have boasted of saving $400,000 or more. And the money-saving stories come from various industries including city government, retail, federal government and more.

But most organizations only harness about 50% of SharePoint’s capabilities—mainly using Document Management, Records Management, Workflows and Business Intelligence. There are a few, however, who have taken their SharePoint implementation one step further and used it to replace third-party applications. SharePoint  introduces external content types, which make it easy to use SharePoint to add as well as view/update data stored in an external database. Its secure store service provides a way to securely connect to external data. But, a project aimed at taking advantage of all that SharePoint has to offer could easily become massive.

This post discusses the feasibility of using enterprise architecture concepts in conjunction with Microsoft SharePoint Worksheets, technical diagrams and guides to implement SharePoint. This post does not discuss doing away with information published by Microsoft. Instead it presents a way to divide a SharePoint implementation into smaller, manageable pieces so a broader range of requirements can be defined and incorporated into an overall SharePoint Implementation.

Basic Enterprise Architecture

Enterprise Architecture presents the framework necessary to break an organization into manageable pieces.  Most Enterprise Architecture frameworks include a Vision and four architectures (Business Architecture, Data Architecture, Technology Architecture and the Application Architecture).  Several enterprise architecture frameworks recommend dividing the organization into segments.

Segment Architecture

A Segment Architecture approach focuses on analyzing a business function within an organization. The Business, Data, Application and Technology Architectures are completed for the segment—a cycle that is repeated until all segments in the organization are completed. Below is a diagram from the Federal Enterprise Architecture (FEA) Reference Model Document. The diagrams show how the federal government has broken its two support operations (Management of Government Resources and Service for Citizens) into segments.
Enterprise Architecture is often used to implement Enterprise Resource Planning (ERP) systems—making it a feasible option for an enterprise-wide SharePoint implementation.

Business Architecture

Business Architecture focuses on the following key areas:  Business Activities (tasks performed to complete a process), Business Rules, Business Goals, Business Services and the Business Functions used to deliver the Business Services. Some Enterprise Architectures also call for performance metrics so organizations can measure their success toward achieving their business goals.

In general, the Business Architecture provides organizations an opportunity to review current  Business Activities for a business function.The objective is to define how the activities are completed and look for improvement areas that SharePoint provides. There are various artifacts that can be used. For example, FSAM recommends the "As-is Business Process Swim Lane Diagram" to capture how work currently gets done. The "Target Business Process Swim Lane Diagram" to identify how work will get done in the future, which should include activities to be automated by SharePoint workflows.

In addition, the inputs and outputs used by a business function (s) is also captured. Data and documents shared by multiple business functions are captured through data-sharing matrices.  Keep in mind that the enterprise architecture approach used drives the artifacts used to document each architecture. 

The most critical pieces of information captured for a segment's business architecture are the activities, roles and the information shared. A business function defines how it does work and the information it creates or produces.  If an organization uses Business Process Swim Lane Diagrams to capture activities and activity steps, the Target Business Process Swim Lane Diagram should include a swim lane for a SharePoint workflow to capture its role in the process.  Also keep in mind that once the Target Business Process Swim Lane Diagram is completed; the SharePoint Developer still needs to create the Visio diagram to define the steps, actions, branches, etc. for the workflow. Following is a segment artifacts business architecture Target Business Process Swim Lane Diagram for Staff Acquisition.

Note:  An Operational Node Connectivity Description Diagram, which is an enterprise architecture artifact from the DoD Architecture Framework (DODAF), could provide additional insight as needed.

Partial Operational Node Connectivity Description (OV-2) Diagram

Breaking the SharePoint implementation work down into architectures and segments gives organizations the ability to implement more in less time because the focus is on a smaller scope of work. This approach applies industry best practices to ensure the project does not become overwhelming.  When capturing the business architecture, information regarding the roles and who does what provides the information needed to configure SharePoint’s security in addition to outlining high-level workflow behaviors.

Lastly, the Microsoft Office SharePoint 2010 Worksheets used during this architecture include planning for audience and content targeting worksheets related to planning workflows, etc. Additional documents can include the Business Process Operations Report, Operational Node Connectivity Description Diagram, Organizational Chart, etc.

Data Architecture

The Data Architecture focuses on the organization’s data. The inputs and outputs captured using the TO-BE version of the Business Process Operations Report identifies the data, documents and records to be implemented. The rules associated with the process are also captured. As the inputs/outputs were captured, a matrix was also managed so others in the organization could indicate whether or not they used a given input or output.

At this this point there is still additional information that must be considered for the Data Architecture, including designing and implementing the Information Architecture.  As additional business functions are assessed the termsets, terms, content types, etc. will increase based on additional information gathered. There are a number of SharePoint 2010 Worksheets used to capture the information needed to answer the above questions. A few of the considerations include the following:

• What data is shared across two or more groups?
• What document templates and forms must be made available?
• What document libraries are required?
• What document routing rules are needed?
• What global versus local termsets and terms are required?
• What records are we managing and what retention and other policies are needed for the records?
• What content types are used to standardize data collection, document grouping, etc.?
• What documents do we want to rate?
• What audiences are associated with what documents?

These are just a few of the questions that are addressed to complete the Data Architecture.

Technology Architecture

The Technology Architecture is used to define the technology required to implement a customer’s SharePoint implementation. Discussions are held regarding servers, software, backup/recovery, planning import and export servers, upgrade paths for any existing SharePoint instances, etc.  Microsoft has developed a number of technology diagrams that can help with defining the Technology requirements for an organization’s server farm. A number of the technology diagrams are in the “Planning Guide for Sites and Solutions for Microsoft SharePoint Server 2010, Part 1.” Any other worksheets related to configuring or building the infrastructure are used in this architecture.

Application Architecture

The Application Architecture is most concerned with application capability and branding.  Discussions held during this Architecture also include capturing information on the capability that should be built in SharePoint to replace third-party applications or outdated home grown applications. The organization’s objective drives what artifacts are used. For example, the organization may compile a list of software capabilities by system (for organizations with multiple business applications). This makes is easy to spot duplicate capability and even duplicate systems. It can also be used to determine what capability should be rebuilt using SharePoint to operate a more integrated environment.

Other areas reviewed during this architecture include what business service applications will be used as well as the secure stores and external content types required to connect to external data. The Microsoft SharePoint Worksheets used include Plan top-level site collections and sites, plan incoming e-mail and all other worksheets that relate to building or configuring software capability.

Summary

More than a few organizations have boasted of saving $400,000 or more. And the money-saving stories come from organizations in various industries including city government, retail, federal government and more. But most organizations only harness about 50% of SharePoint’s capabilities—mainly using Document Management, Records Management, Workflows and Business Intelligence.

Most likely, many organizations do not use SharePoint to its fullest ability because of its many features and using it to its fullest likely means an overwhelming project that is likely to fail. Organizations can be divided into segments and divide the SharePoint work into architectures (i.e., Business, Data, Technical and Application). Dividing the implementation into smaller pieces gives organizations an opportunity to include more SharePoint functionality and experience a more useful implementation that will save money.

The process begins with the Business Architecture, which would use the selected business architecture templates to capture the business activities and steps along with data and documents being shared.  The next step would be to further define the Data Architecture. Although the Application Architecture is defined before the Technology Architecture; the Technology must be implemented prior to the Application Architecture. In other words, update or add hardware before deploying the applications.

Use SharePoint 2010 Custom Lists to Design & Build Custom Applications

This article discusses SharePoint development, capabilities and the tasks required to use lists and libraries to build a site.

As a SharePoint and .NET Developer, I can attest that designing and developing SharePoint 2010 solutions is different from designing and building .NET solutions. In many ways, it's easier to build .NET business applications because Developers don't have to figure out how to build what a customer wants using an existing framework. On the other hand, basic business applications can be built rapidly with SharePoint 2010. 

When a SharePoint Developer builds a SharePoint list SharePoint creates the add, edit and display forms, a mobile version of the list or library, an all items view (that lets you see all the data added to a list); and, RSS feed capability. Imagine the time it takes to manually code all of that functionality in a .NET application. Time-to-market and reduced costs is one key reason big businesses have deployed SharePoint. (The other reason, of course, is they gain the expertise needed to compete for multimillion dollar federal government contracts.  But that topic is fit for a different article.)

The other benefit SharePoint  brings to the table is the ability to easily implement security. With SharePoint sites, SharePoint Site Administrators add the roles and then add people to the role to grant access to a site. If the security isn't configured properly SharePoint automatically prohibits rather than permits. And, SharePoint supports fine-grained security. This means the Site Administrator can add roles and people directly to SharePoint lists instead of accepting the default list security, which is the list inherits the "site's" roles and users. When fine-grained security is used two people with different permissions can look at the same page and see different content. For example, if one person is in sales and another is in marketing; the sales list can be configured so only sales people see it. The marketing list can be configured so only marketing people see it. There may also be lists, on the same page, that allow both marketing and sales to see the list items.  If you understand how SharePoint security works, it doesn't take very long to figure a site to behave the way a customer wants it to. Security flexibility and secure access is one key reason nearly every branch of the US military has also adopted SharePoint.

But the advantage many .NET Developers see with .NET is they don't have to figure out how to use an existing framework. They can build a web application without any barriers; and I whole heartedly agree with this.

But for SharePoint 2010 Developers who learn out-of-the-box SharePoint Server 2010 features, SharePoint Designer and Visual Studio--the world is theirs (figuratively speaking). Building robust, collaborative web applications can be completed within days or weeks (unless complex, custom functionality is requested).  And, these sites can include spunky workflow functionality that further streamlines a business process through automation. SharePoint Developers can also use SharePoint Server, SharePoint Designer 2010 and Visual Studio 2010 to build custom lists and/or libraries. Or, they can create an .aspx page, using an existing master page, and add webpart zones (which are used to hold lists and libraries). The Developers or users can then drop the desired lists and libraries on the page, which is then ready to be deployed. 

Using SharePoint to Design a Customer List or Library

The following paragraphs discuss the various ways a product ordering system could be designed using SharePoint.  (Note that in the real world SharePoint would be used with Microsoft Commerce Server to build an integrated ordering system. However, I still think the ordering system is a feasible design to use as an example.)

For this example we are going to walk-though designing multiple Products Lists (a Product List for each product category) and a Shopping Cart List. We will have a User role and a Product Administrator role. In our design, the User role can view all products and edit two fields on the Products List. However, the User role cannot create new products. In addition, the User role can create and update items in the Shopping Cart list.

In our design the Products Lists will be built from content types. We are building the Products Lists from content types because we would only need to build the list once. That list is then available to the entire site. This will allow us to rapidly build the Products Lists. The Shopping Cart will be built from a custom list. We will design a reusable workflow and associate it with our Product content type. We will also add a workflow to our Shopping Cart.

Product Content Type

As previously mentioned the Product content type will be used to build multiple Product Lists. Using a content type means the SharePoint Developer only builds a Products List once. 

• To begin, we create a list and give the list a name. For example, the first list is created and called Arts, Crafts & Sewing. 
• Once the list is created we use the List Settings option to enable the ability to use content types. SharePoint automatically adds the list content type and sets it as the default content type. 
• Next we add the Products List content type we created. The Arts, Crafts & Sewing list inherits all of the columns in the Products List Content type. 
• Now we have to set the Products List Content Type as the default content type so we can delete the list content type SharePoint added. 
• Lastly, we can add our Arts, Crafts & Sewing items to the Arts, Crafts & Sewing list. 

We repeat these five steps for each product category. Using content types means we can very quickly create usable lists for all of the product categories. The left menubar displays the name of each list we created. The Administrator can click on a product category, on the left menubar, to add the products. The users can then click on a product category to view the list of items added by the Administrator. The following picture shows the the Baby category selected by a user. 

Notice the Limited View is shown to users because the users can only see the columns needed to identify the items to be purchased. The Administrator uses a different view because the Administrator must add columns the user should not see. For example, the Administrator adds the number in stock column, and the quantity sold (a workflow is used to deduct the quantity sold from the number in stock to keep the number in stock current). The Administrator also adds the restock level column. The system can use this column (and a separate workflow) to automatically reorder a product when number in stock column reaches the number in the restock level column.
 The system design calls for the following site columns to be added to the Product content type: Product Name, Category Name, Product Description, Product Price, Product Size, Product Price, Quantity in Stock, Quantity, Add to Cart (which is a checkbox where checked = yes and unchecked = no) and others, as applicable.

Note that there are many ways to build the same application in SharePoint. For example, instead of using content types we could design the application to use a Product Category list template. To do this a Product Category list is created with all of the relevant columns. The SharePoint Developer saves the Product Category list as a template. Then a list is created for each product category using the template.

Alternatively, the design could use a Category list made from a Category Content Type. The Category content type would have two columns as follows: Category Name and Category Description. The Product Content Type would then have a Category look-up column so the Product Administrator can select a category from the Category list when adding products. A third design option could be to add a Category column (using the Choice option) directly to the Product content type. Then add the categories to the Category column so the Product Administrator can select the desired category when adding new products.

However, in this design a separate list is to be created for each category. SharePoint will create the navigation so the Developer will only have to reorder the items on the left navigation bar so they display alphabetically. The initial number of items that will automatically display in the Product list is 100. The system design can also use a SharePoint List Filter webpart to filter products within a category. In addition, products can be sorted by price. The design could also allow for users to rate each item.

Whenever a SharePoint list is created a Title column is automatically added. This column automatically links to the View Details page, which enables a user to see all of the columns associated with the list. However, we can use SharePoint Designer to create a custom View Details page.  We only add the columns the user should see to the new View Details page. When the user clicks an item under the Title column (which has been renamed to Product Name) the user will see the custom View Details page we created. 

In this example we named our custom View Details page as follows: View Product Details. Whether the user clicks View Product Details option from the shortcut menu; or, clicks the item name under the Product Name column the user will be directed to the View Product Details page. 

We also designed our View Product Details page so all fields of the fields are read-only except the "Quantity" field and the "Add to Cart" checkbox. The User role can update these two fields indicate the quantity of a product to be ordered and add the item to the shopping cart. When the Save is clicked on the Product View Details page, the form checks to see if the Shopping Cart checkbox is checked. If it is and the Quantity field is empty, a message displays telling the user the Quantity field is required. Or, if the user adds a value in the Quantity field; but does not check the Add to Cart checkbox then the "required field" message displays for the Add to Cart checkbox. This ensures the user does not complete one field and not the other. 

 
The Shopping Cart

If no errors are found the updated occurs, which initiates the workflow. The workflow checks the Quantity field only (the form already performed the checks to make sure both the Add to Cart field and Quantity field are both completed). If a value is found the workflow captures the product name, quantity, calculates the price for the items, etc. and inserts a new list item to the Shopping Cart list.  The User role never directly adds items to the Shopping Cart list. Instead the workflow copies a Product, on the user's behalf, to this list.

The Shopping Cart List Workflow

The Shopping Cart List has a Purchase drop-down list. The drop-down list includes two options: Keep in Cart or Discard. When the workflow inserts a new list item, it sets the default value to Keep in Cart. The Shopping Cart list was updated to display the "total" based on the Price of each item (which is driven by the quantity of the items purchased). At anytime the user can select "Discard" and save the update. The update action initiates the workflow, which removes the item from the list. The list is managing the total so that when an item is removed the total is updated. In addition, the Shopping Cart List workflow adds the quantity back to the inventory.

Summary

This article outlines how a developer can use content types to reduce development time. And, it explains how workflows can be used to copy a list item in one list to another list. It also provides an overview to the benefits of using Microsoft Office SharePoint Server for custom development projects.

Value-Driven Agile User Stories & Test Cases

I’ve had an opportunity to use Agile methodologies while working with a large federal agency and a few other organizations. The large federal agency project was most interesting because it was a complex project. One thing I noticed right away was the level of collaboration used. The experience was very different from what I had been accustomed to. The Development team was large, but despite its size everything was well organized. Problems were discussed daily and solved before the next day’s meeting. It was great to get experience in supporting a large project using Agile. But I still was not convinced user stories were better. This is one key reason it has taken some time for me to actually write about them.

After spending years writing use case specifications and software requirements specification, I wasn’t sure user stories where a good idea. But after working with them over time I began to see their value. I wanted to use this blog article to discuss the format I use to write user stories and present some examples, which I hope are useful.

Value-Driven User Stories

User stories do a good job of presenting requirements in a way that is more concise and easier to understand. Over the past couple of years I have focused primarily on writing value-driven user stories. This means I try to make sure every aspect of the user story adds value in defining the software functionality as it pertains to user expectations. I think facilitating a meeting does mean asking questions to help users think and talk about what they want. But I also think the BA or SA has some editing to do to make sure the content is as useful as possible. For example, I could write a user story that says: "A salesperson wants to add an order to meet customers’ needs." I’ve included the role (salesperson). I’ve also included the what (add an order) and the why (meet customers’ needs). However, the “why” can be written to add the same level of value as the “who” and “what”. If I rewrite the user story, it might look like this: “A salesperson wants to add customer orders to track products purchased”. This user story ties orders directly to products purchased.

In this example, we would expect the user story conversations to include discussions not only on customer orders but also products. This is useful because a customer cannot place an order without a list of products or services to order from. 

From a Developer perspective (i.e., Database Developer or Software Developer) writing user stories that are concise and value-driven strengthens the quality of the requirements and, ultimately, the product being built. The following example includes a user story that associates software problems with trouble tickets. Notice in the Notes section taken from the conversations, “problem description” is discussed. Also notice the user story description provides insight to the workload and the business users’ objective for the user story (i.e., “they want the system to help them process new tickets in a timely manner”, which results in alerts being added).

To make user stories easier for Developers to work with, I embed the use case in the user story. In the following user story [employee] is the role, [submit trouble tickets] is the use case or the “what” and [to describe software problems] is the why. This approach helps developers transition into user stories more easily. They always know to look to the middle of the user story to extract the use case. And, they know the role is at the beginning of the story with the why at the end, as applicable. 

 

The above user story is ready for development. It includes the details necessary to convey the functionality required for the Product Owner and Development Team to all agree on what “Done” means. Notice this user story is assigned 8 story points. To add story points, the Development Team used the Fibonacci sequence (1,2,3,5,8,13,21,34,45), which when diagrammed shows an upward curve indicating an increase in complexity as the numbers go up . They gave this user story 8 story points. This story serves as the baseline to assign points to all future user stories. More complex user stories will consistently have a higher number. User stories with the same complexity will be assigned the same number. And, user stories that are less complex will be assigned a lower number.

Test Cases

Test Cases are a great way to confirm user requirements have been met. The following capture shows the test cases associated with the “As an employee I can submit trouble tickets to describe software problems” user story.

Initial Task List

During the Sprint Planning Meeting, the Development Team can identify all of the tasks associated with development. The System Administrator should also document any items he/she must complete for development to commence and move forward. If a Database Developer and/or Data Analyst is part of the project these individuals should also add items to the list. Once the task list is created individuals can volunteer for the work they want to complete or the work can be assigned by a team lead, whichever is applicable.

The Barriers/Action Items List

As the Development Team works to complete the iteration items for a Sprint, problems always arise. One way to manage daily problems is to keep a Barriers/Action Items list. The list should be accessible to everyone at all times. It can be updated during the daily standup as well as throughout the day. If SharePoint is used to manage the Barriers/Action Items list, the Product Owner, Project Manager and team members can all subscribe to alerts to be notified as new items are added. This way if you can solve a problem, you hear about the problem as soon as it is recorded.

Hopefully you will find this information useful and it will shorten your workdays and make your career a bit more brighter.