Almost all organizations, across industries and sizes, need to have geographically dispersed employee bases. The extent of dispersion varies from multiple locations in a single metro area (for smaller organizations) to hundreds of locations across multiple countries (for larger, multinational organizations).
All of these geographically dispersed locations (factories, remote offices, warehouses, service centers, and so on) need to have local backend IT infrastructure to deliver services to the local staff. Examples of these services include local file storage, local applications, network connectivity, and more.
One common design question that CIOs and IT teams of these organizations face is how to strike an optimal balance between “Standardization” and “Customization” – which have divergent objectives.
On one hand, “Standardization” hopes to achieve (a) ease of management (b) reduction in costs and (c) consistent services for all staff; and on the other hand, “Customization” hopes to achieve (a) local needs catering (b) best-fit solutions (c) specialized services.
Wipro’s OIB (Office in a box) framework aims to bridge this gap with a structured approach.
1. Services Needed
The first step is to list out all services that are required to be delivered at your remote sites. This should be an all-encompassing list covering all possible services (not all services maybe required at all sites).
Having this list helps to create a good starting point for identifying the right solutions that can cater to all the requirements. It also helps to arrange these services in a ladder fashion to identify the various technology components needed.
An example of this ladder is shown below.
As you look at the figure on your left, the questions that you need to ask yourself are which services to include and exclude.
For example, if you come from a manufacturing background, a good question to ask will be “Should we include OT security in this list?”
Another example, if you are a user of Raspberry PI or you are thinking about sensors to collect IoT data from windmills, it may be relevant to ask if these services should be included.
These decisions are often driven by organization design, separation between IT/OT teams and responsibilities, gaps in current services, and a vision for future services.
The output of Step 1 will be an exhaustive list of services required across the various sites.
2. Categorization of Sites
The next step is to categorize the sites in a particular fashion. The objective of categorization is to group sites with similar requirements together, which can likely be supported by a single solution.
The rationale used for categorization, as well as the factors considered to arrive at a categorization, may be different for each customer. However, the objective remains the same: each site should not have its own unique “Christmas tree.”
For example, sites could be categorized based on number of staff members at each site, or they could be categorized by the nature of business conducted at each site. They could also be categorized by distinct IT needs at each site. Take a look at the picture below to see how sites are categorized on three dimensions: criticality, size, and type.
Looking at the picture above, you might ask yourself, “Why don’t I categorize sites as factories, warehouses, and so on?” Or you may wonder, “Why don’t I have four types of sites by criticality and five types of sites by size?”
The output of Step 2 will be a defined list of site types or site categorizes where all sites within a single type or category have homogenous IT requirements (the services identified in Step 1).
3. Design Principles
At this stage, we have a matrix consisting of lists of services and services needed per site category (as shown below).
The final step is to lay out the design principles, which will be used as a basis for creating the solutions that will be deployed at each site. The intent is to develop design principles at a tactical and operational level, which will help make critical decisions around costs, choice of technology/OEM, and so on.
Take a look at the design principles listed below. These could be generic or specific to your situation.
For example – if you have already invested in a particular brand of hyper-converged infrastructure it maybe worthwhile to take a decision to either continue or change.
Or it maybe on your mind to reduce remote site infra by moving to cloud
Based on the design principles, the final decision on the OEM and technology solutions will be made. In parallel the service delivery mechanism will be defined to be used to deliver services to customers/staff/business. From a pricing standpoint it will be an objective to convert the services into a simple intuitive catalog.
The final output of the entire framework will be a catalog as depicted below comprised of a service catalog and a price catalog.
And so on.
To conclude, Wipro’s OIB framework takes a simple yet customizable approach to converting IT requirements into a simple, reusable catalog.
About the author
Senior Architect, CIS, Wipro