Gaining Insights – Part I - By Sanjay Jotwani

Introduction

We live in a digital world!! Every interaction is a “transaction”, and recorded into the computer’s storage.

So, what is the primary need of capturing this transactional data?

·         Proof of Interaction

·         Grain for Business Analysis

·         Case for Predictive Analysis

As we have digitized every piece into a bit, the challenge faced today is more in terms of

·         Volume of Data and,

·         The disparate forms of Data in a Domain.

As mentioned, data has a purpose to serve; the major is that of participating in analysis, leading to the intelligence required by the business to make informed decisions.

In this multi part blog series, we will try to cover the need, along with the design & implementation practices for a Business Intelligence Application.

The Framework for Business Intelligence

A Business Intelligence Application, from a layered architecture perspective would be represented as shown in Figure 1.

This framework is conceptual, and technology agnostic.

Figure 1.

1.       The Data Integration will result in the Consolidated Data Storage

2.       Data Analysis and Rich Visualization such as decomposition trees will use this Consolidated Data

3.       The Consolidated Data can be termed as Data Warehouse OR Data Mart.

 In the next blog, we will explore the Application Data Layer.

Until then; Cheers!!

TFS FAQ - By Sanjay Jotwani

Introduction

A Work Item in common parlance is considered to be an instance of effort/work being carried out by an individual. Multiple instances of Work Items eventually culminate into the delivery of a service or a product that is meant for a customer.

Team Foundation Server Work Items

Depending on the approach one adopts for managing an application life cycle i.e. from requirement gathering to actual delivery/deployment, there are various work item types that will be instantiated and persisted into a database. As business needs and the processes thereof are dynamic, and disparate, customizing a Work Item, hence seems to be inevitable. It is therefore essential to understand the anatomy and thereby gain the basic understanding of customizing an existing work item type, or even adding a new work item type.

The Anatomy of a WIT(Work Item Type), in TFS has three essential parts, viz.

1. Fields
2. Layout, and
3. Workflow
   
   

In TFS there are approximately 57 “Field Reference Names”, mapping to base/native types. This is an extensible set.  In keeping with the .NET namespace tradition, two namespaces are predefined: System and Microsoft. The System namespace includes all system fields that are mandatory for Team Foundation system functions. The Microsoft namespace defines all required fields for work item types defined by Microsoft. Customers and partners can create their own field namespaces for custom work item types. We could define our own namespaces, for e.g. a WIT for tracking leads could have a field with a reference name of “Synergetics.LeadManagement.CustomerName”. This in turn could be of a base type “String”, having a name of “Customer Name”, as shown in Figure 1.1

Figure 1.1

Layout

In this section, you map the reference name of the field to a control. The control is the user interface for capturing the required data, and can be customized with a “Type” property to perform necessary validation and change the look and feel, as shown in Figure 1.2. A “Type” property could a “FieldControl”,  “DateTimeControl”, or even a “LinkControl” depending on the data requirement.

Figure 1.2

Workflow

A wok flow is a series of linked steps which would be used to declare transitions to different states, in the life time of a work item. Transitions would be declared, or provide links between states in a WIT work flow, using a graphical UI, as shown in Figure 1.3

Figure 1.3

As an example, the transition from “Active” to “Closed”, will occur for the reasons:

Obsolete, Chose Competitor, Project Cancelled, Too Expensive, or Offer Accepted;

Wherein default values and rules for the fields Assigned To, Activated Date, Activated By, Closed By, and Closed Date are also declared.

The Actions, provides the events under which this transition is deemed to occur.

To conclude customizing a WIT in TFS is a simple, code free effort and can be done within a short period of time, actually hours if not minutes. The key is to know the process and identify the flows, further to which each flow could be encapsulated as a WIT.

Interestingly, as may have been observed, the example used to explain the anatomy and steps, are for a WIT which captures and tracks non development efforts. If you are wondering why would I use TFS to do such a thing?! Well, think about support calls that one would want to capture, post deployment of a product/application.

Thanks for spending time in reading this blog, and sincerely hope it may have helped clear some doubts on the WITs in TFS.

Cheers & Have A Nice Day Ahead!!

About Author: Sanjay Jotwani is Technology Transformation Group Leader.

Synergetics India: IT consulting and Training services on .NET 4.0, SQL server 2008 BI. Awarded as the Best. NET Training Service Provider by Microsoft.