Setting Up Your IIoT/IoT Initiatives for Success
Create an IIoT/IoT Organization
by Chris Herrera
It seems, more often than not, that as we are working with clients on business requirements, technology challenges, and solution design and development, we are also getting asked about how to setup for success from an organizational perspective, specifically related to IIoT/IoT, and the challenge that comes with working across both Operations Technology (OT) and Information Technology (IT) domains. This post will describe a bit more on the agile development team structure…It works for IoT/IIoT in the context that there is this confluence of IT and OT, which does impact the team make up, however, this is truly about creating an agile cross-functional team.
Sandwiches — a Lunchtime Cross-Functional “Team”
I tend to be on the run a lot during the day, and even when I’m in the office, I move from meeting to call to project and as a result have little time for lengthy lunches so the local sandwich shop has gotten to know me well and I’ve gotten to know their sandwiches well, and while I do happen to like the individual components of sandwiches on their own (let’s be honest no one wants to eat iceberg lettuce on its own), for my mid-day meal, they function much better as a cross-functional “team” of savory goodness layered in between my favorite roll or bread.
Silos Don’t Work for Your IIoT/IoT Organization
Many organizations tend to operate in silos because that is the way they have done business for many years — either OT or IT keenly focused within their respective domains and doing a great work individually, but frankly, that approach doesn’t get the performance you need for a dynamic IIoT/IoT organization.
“Classic” IT Approach
The “classic” IT project flow of going from Business User to Business Analyst to IT PMO who reviews, budgets and schedules (high and for very long duration usually), but ultimately ends up disappointing and delivering a subset of the needed requirement many moons down the road and calling it day is not acceptable for the business. Solving problems quickly can be a hassle for IT and it’s another altogether to support the solution for those problems. Typically this team has their toolset or technology platform that they are comfortable with and that they have deemed supportable, so naturally they are wary about stretching beyond that.
“Classic” OT Approach
On the other hand, a “classic” OT organization will see a fire at a facility, won’t be able to locate a fire extinguisher, and will get 40 guys to get a bottle of Ozarka and pour it on to fix the immediate problem at hand, of course, that will not stop another fire from happening and who knows if you’ll be able to find 40 guys next time you have a similar event. OT operates in a mode of needing to solve a problem and solve it yesterday.
So there is an obvious disconnect between the two organizations.
I believe that to truly setup your IIoT/IoT organization for success, you need a more cross-functional “sandwich based” approach that includes a good representation of IT Business Analysts (how applications are setup, where date lives, how service tickets flow, what is required from a security perspective, etc.) as well as OT Business Users that actually use the technology today and will use the new solution technology — engineers, business operations team members, etc. that are very concerned with how the data will be used and analyzed, what visualizations are required, what is the business process flow, etc.
You take a cross-functional approach so that neither domain tries to solve problems that the other has already figured out thereby helping to shorten the overall duration of the project. Yes, the solution may require some adjustments or tweaking, but RE-solving for areas that have previously been addressed by the IT team for instance…consistency issues, data replication, data movement, etc…is a waste of time and money.
This is also not saying that you should pursue a strategy of technology entropy. From an enterprise perspective, there is value to creating guiding principles and preferred tech stacks, however, the teams need to have the autonomy to experiment with different tech, especially due to the velocity of innovation in the IIoT/IoT space.
You Need Doers — Form a Cross-Functional Technology Team
Additionally, you will want to ensure that there is a healthy dose of “doers” on the team. Thinkers and PowerPoint-makers are great and definitely needed, but this team will need to take substantive action by all involved and not just to provide oversight and direction — they will need to be empowered to actually deploy the technology against business problems and carry with them an in-depth knowledge of everything from security and consumption patterns to user types, devices, and use case challenges.
Critical for this team, when tasked with deploying IIoT/IoT technology and various design patterns, is to have autonomy to try new things while simultaneously succeeding and failing, sometimes a lot — not everything is going to work — that’s okay.
It’s not an IT team or an OT team as much as a cross functional technology team that doesn’t necessarily have gates at which the business unit or users come in for reviews (traditional way), but the business users are heavily involved in all decisions, overall user experience, and the solution approach in general.
Business User Involvement Gets You to the “Why”
A common theme currently in the Oil and Gas industry, for example, is to collect/capture data from a drilling rig or production facility. A wellhead may be outputting high frequency data at 400hz which would be costly to transmit in its entirety without a defined use case supporting the need to transmit that data. But maybe the problem can be solved by decimating, approximating, or compressing the data, or even having someone drive to the site and dump the data. When a business user is involved in the entire process, they will be able to ask the hard questions or provide the hard answers about “why”. They will be able to pinpoint for various use cases the level of data fidelity required in support of the business problem at hand.
From there, the team can quickly loop their Hypothesize — Experiment/Develop/Test — Productionize/Trash cycle. Asking “why” is typically the best way to simplify a problem. An actual user will definitely be able to tell the developer that you don’t have to handle the case where the rig is airborne (hopefully), for example.
In summary, the infographic below highlights three principles to focus on for a strong IIoT/IoT organization and culture — we will explore these further in future posts.
Get Moving
The organizational challenges of dealing with IT and OT are very real and much of what we have discussed in this post is common sense, but it does take a shift in mindset and focus to get there. If an individual regional business unit is ready and able to move quickly, then go with it, as you may need a different approach, technology solution, or team makeup for the next business unit anyway.
If you’d like additional assistance in this area, we offer an IIoT/IoT organizational enablement workshop as part of our consulting service offerings and would be glad to work through your specifics in this area.
Feel free to share on other channels and be sure and keep up with all new content from Hashmap at https://medium.com/hashmapinc.
Chris Herrera is a Senior Enterprise Architect at Hashmap working across industries with a group of innovative technologists and domain experts accelerating high value business outcomes for our customers. You can follow Chris on Twitter @cherrera2001 and connect with him on LinkedIn at linkedin.com/in/cherrera2001.
