5-10 min read(medium)

In the previous blog here, we looked at the various scopes and solution components that could be built into Microsoft Teams. Also, I mentioned some of the questions that we could get while working on a solution with the various options possible in Microsoft Teams. In this blog, we will compare the ins and outs of these solution components and the challenges we are trying to answer.

Components

Before we start looking into details of how to use components effectively, below is the quick list of components that we discussed in the last blog for reference. For more details, check the previous blog here.

  1. Personal Apps / Tabs
  2. Channel Tabs
  3. Bots
  4. Messaging Extensions
  5. Connectors
  6. Task Modules

Each of the component has their strength and merits that makes them best for specific scenarios. Below in the capability chart section we will look at hosting and architecture scenarios for these components.

Capability chart

There are various cool features with components but as we all know one size doesn’t fit all. Hence, we must match the suitability of the components to the hosting requirements.

For e.g. Personal tabs are user specific but if we want to deploy the app to every user of the firm then the best way is to host the solution at the tenant catalog and then install the app for users using a script. It is also possible for a user to upload the app individually for personal use if an app package file is provided.

To capture all the possible scenarios, below is a capability chart for each of the components at various levels of IT requirements. The Capability Chart shows the relationship of the components with various architectural requirements for each.

We will look at the following levels. There are other levels we could evaluate on but below are few fundamental ones:

  1. Application Scope: Scope at which application can be installed and accessible
  2. Set up configuration: Allow to configure the component when or after installation
  3. Impact Scope: Scope of impact in case of anything breaks or changes
  4. Risk Index: Risk associated with the component’s use and application
  5. Role Based Access Control (RBAC): This is useful to restrict access based on the user roles or security levels
  6. Deployment Scope: Scope of deployment supported by the component

The above will help the architecture and design team to decide which of the options works well for the solution from hosting, deployment and management perspective.

Solutions Map

The capability chart gives us a list of limitations or technological boundaries for the components. If capability scope is flexible, then it now up to business requirements for identifying the best component option. So, we can use the solution map (as below) to see which one of the component options could be best fit for the solution.

The other aspect of the solution model is what requirements and factors that we are trying to fulfill with the solutions. If the requirements are more towards a particular scope, then we can align the solution towards that component.

For eg. Bots are good for Q&A requirements where instead of a Questionnaire form, we have a conversational bot on the other end which understands the user requirements and provides the answer choices.

We can distribute the solutions broadly in one of the below categories

  • Focus work: Relates to requirements which allow user to get information without moving around apps or through multiple business apps from a single place
  • Governance: Relates to control and management of the environment. It also includes capturing information that enables users/admins to use this information for tracking and managing the platform better
  • Team work: Relates to easy collaboration and share information among team members to allow faster team work
  • Integrated Solutions: Related to connecting more than one business applications to share / gather / use information from multiple scenarios
  • Custom Single Page App (SPA): This allows to create Single Page Applications such as Gmail, which will allow users to work on a single screen instead of browsing many pages of the app
  • Third party or Internal Apps: This could be third party vendor app requirements or custom internal apps built to support
  • Alerts / Messages: This allows to receive alerts from other systems or send messages to other systems to allow sharing of information
  • Data Sharing: This allows to send data from teams to external systems that can consume the data
  • Question / Answer Scenarios: Relates to scenarios where user can ask questions and get answers for those questions, which is really common with the chat based interface

Conclusion

In this blog, we have looked at a capability chart and solution map for components which gives us a technical and function overview of the them and some scenarios to use them. In the upcoming blog, Part 3, we will look at how we go about planning the build of a component and introduction to the SIMplE model.

Leave a comment