itHUB - Part 3

December 17, 2013

Reading time ~7 minutes

Continuing from where we left off in Part 2, lets start exploring the software architecture of itHUB a little more in this post.

C. Technology: Web 2.0 and Beyond

The use of Web 2.0 and beyond [9] is a must for the itHUB platform. The following diagram illustrates the architectural layers and partitions of itHUB platform software components: Layers and Partitions of itHUB

1) Internal Products and Services

These products and services are the core competencies of the IT departments. These products and services could range from homegrown applications to hardware and software bundles that the IT departments have direct control over.

2) itHUB Data Store

This is a dedicated data store to itHUB platform for the purposes of storing and retrieving its constructs such as “requests”.

3) External Products and Services

These are from the external service providers such as Walmart, Staples and PC Connection – a select set of products and services that conform to the standards and compliance needs of the IT organization. The products and services from the external service providers will be accessed using their application interfaces (API) and added to the internal products and services to create the consolidated portfolio of products and services.

4) Request Management

Request Management is the crux of the itHUB platform as shown in Figure 7. Requests are managed in two steps as follows:

  1. Configure/Provide Request Types – Either the service providers or the service administrator carries out this step. This is the first step in making a set of requests available to the IT customers to choose from and ultimately requested for. These are configurations or specifications of the requests and not the requests themselves. For example, to process a desktop request, the IT department might need a set of data points such as “Is this a new or replacement desktop?” or “How much RAM is required?” etc. Without these values, processing of the desktop request may not be possible. Plus, the list of approvers is specified for each of the request type. For example, for a desktop request, there may be a need for approvals from the department manager and the general manager (or some suitable roles).

Request Management

  1. Create/Track Requests – After choosing one of the request types, for example, the desktop request, the customer goes on to fill out the necessary data points and submits the request. Once the request is submitted, it is routed for approvals based on the specification of the request type. As described in the previous section, a desktop request will be routed to the department manager and the general manager of the customer who submitted the request. After submitting the request, the customer could check on the status of the request including the approvals.

5) Approval Workflow

As shown in the above picture, the approval workflow enables the management team to ensure that the requested products or services are really a need for the requestor’s job role. One of the primary steps of this component is described below:

  1. Approve/Reject Requests – In this step, requests are either approved or rejected by the approvers. Email/SMS channels will be utilized to send and receive approval notices.

6) User Management

This is where the customer data is managed. As described in the previous sections, customer data includes location information such as address, building, and floor details, billing information in terms of cost center, project number or internal order number etc., and the department information including manager details.

7) User Management Store

The data points about the customer needed to process requests successfully might spread across multiple data stores and ERP systems. There may be a need to assemble the customer data from a wide variety of data sources such as PeopleSoft, Asset management database, LDAP directories to create a unified view of the customer.

8) ERP

Enterprise Resource Planning (ERP) might house the relevant billing information for itHUB to associate with customers and their requests. As described in the previous section, the billable information could include cost center, project number or internal order number for cross charging purposes.

9) Web Layer

The web layer would include components such as wiki/blog creation framework, web application frameworks such as J2EE-based Spring framework for web site navigation development, data persistence, web service development, and for messaging.

D. itHUB – The System Boundary

The following diagram illustrates the system boundary and the dependencies of itHUB with external systems both managed by the IT department and external service providers.

itHUB System Boundary

As shown in the diagram, the user infrastructure could be a combination of systems such as PeopleSoft, corporate LDAP directory etc. The billing information such as cost center details could be housed in ERP systems such as SAP. Therefore, the user management component has to deal with assembling a unified view of the customer. The request management component has to deal with receiving and processing the external service provider’s product data. The following section will go over the data semantics and formats for enabling the integration of customer data with internal to IT, but external to itHUB and exchanging products and services from external suppliers.

I’ll contiunue my discussion in the next post.


[9] T. O’Reilly and J. Battlelle. (2010). Web Squared: Web 2.0 Five Years On - by Tim O’Reilly and John Battelle. Available: http://www.web2summit.com/web2009/public/schedule/detail/10194

Technology Stack for Web Applications

Choices abound when it comes to developing websites and to managing them efficiently. This paper outlines a set of web technologies that ...… Continue reading

itHUB - Part 6

Published on February 15, 2014