Well, it’s a new year; a good time to break away from old ways and try something new. Sometimes, however, trying new things can be a little intimidating. Conventional wisdom tells us that it’s always safer (and generally more comfortable) not to rock the boat by questioning established policies, processes and procedures. When we finally do summon the courage to venture outside the box (admittedly a tired cliché, but appropriate here nonetheless!), it can be quite difficult to decide how to go about causing real change. Consider this…
At one time or another, someone has probably suggested to each of us: You need to know what you don’t know! (Or, at least something along those lines.) However, there is also a little known corollary to that axiom regarding not just knowing what you don’t know but why you don’t know it. Yet although we do many things by rote (heck, if we had to analyze everything as if we’re doing it for the very first time we’d never get anything done!), there is also an argument to be made for understanding why we do things the way we do – especially when millions of dollars are involved. Maybe – just maybe – there’s a better way.
Thinking about this reminded me of a behavioral research project I heard about many years ago that went something like this:
First, they put a monkey in a room housing a single banana tree. At the top of the tree was a bunch of bananas connected to an electrified wire. As soon as the monkey went after the bananas, he received a mild electric shock, and after several attempts, he finally stopped trying to get the bananas.
Then, one by one, they let additional monkeys into the room. Predictably, each immediately went for the bananas, but before getting halfway up the tree, monkey #1 yanked each newcomer down by the tail. Then, after several new monkeys had tried and failed each time they tried to get the bananas, they all finally succumbed to the reality that the tree was off limits. At this point, the original monkey was removed from the room. (Remember, he was the ONLY monkey who was ever actually shocked trying to grab the bananas!) But even after he was removed, none of the other monkeys tried to go after the bananas again, even though the protector of the bananas (aka monkey #1) was gone.
Here’s where it gets really interesting. A short time later, a new monkey – one that had never been in the room before – was allowed to enter. Spying the ripe bananas, he immediately made a beeline for the tree, but each time the new monkey tried to climb the tree, he was slammed back to the ground by one of the other monkeys in the room. After several more failed attempts to win the tempting banana prize, albeit without ever being shocked, he too finally gave up the quest.
What’s interesting to note here, of course, is that none of the monkeys in the room at that point had any first hand knowledge of exactly why the bananas were off limits, nor did they know what would happen if they actually got their hands on them. They just “knew” that going up that tree after the bananas was not a choice – without having a clue in the world why not! That is to say: They had a good handle on what they didn’t know; they just didn’t know why.
Okay, so we’d all like to think we’re better than a bunch of monkeys, but I’ll bet we can all identify something we learned do a certain way yet don’t have any idea whatsoever why we do it that way. Before you waste any valuable time on this mental exercise, let me save you some time while also bringing this theory back into the real world of automation.
Within the first few years after starting out in this field, I had the opportunity to work on a wide range of automation projects in various market sectors including oil/gas pipelines and production; gas, electric and water/wastewater utilities; heavy rail, light rail and vehicular transportation; telecommunications networks; and discrete, batch and continuous process industries. At that time, the projects were all very different, using different hardware (there was no software then!) and employing very different technologies and operating philosophies.
Appropriately, each project within a given market sector was planned, designed, budgeted, implemented and supported on its individual merits. There was no “cross platform” technology – it was still a very proprietary world at that point – and the concept of interoperability had not yet been seriously contemplated; in fact, I’m not sure the term even existed in the automation vernacular of the day. So, everyone went along their merry way, albeit in blissful ignorance, that any of their efforts could, should or ever would be shared with their comrades on the other side of the cubicle.
However, as the years wore on, share they did. I recall one municipal water utility customer in the early 1980s that bought a SCADA system from the supplier I worked for at the time. They were quite proud of the fact that the system they purchased shared absolutely nothing with the electric utility side of the house. Although the water and electric factions sat on opposite sides of the same hallway, they might as well have been in different countries; they wanted nothing to do with one another, mainly because they were convinced that they had nothing in common.
About five years later, I came across a friend of mine at a conference who had worked for the electric side of that same utility. Inevitably, the conversation came around to the system they had purchased from us. When I asked him if the system had been changed or expanded, he told me that the whole master station had been scrapped along with that for the electric side and was being replaced by a new computer host that would talk to all of the legacy water and electric RTUs (remote terminal units) that had been purchased from disparate vendors at various times. I suppose that was the beginning of not just an evolution, but perhaps what might even be termed a revolution that brought us to where we are today.
Indeed, over the decade or so that followed, the now widely accepted concepts of COTS (commercial off-the-shelf) automation products and interoperable systems caught on, slowly at first, but eventually reaching an avalanche pace. Today, no one even contemplates buying proprietary solutions and multipurpose offerings are plentiful, often crossing vertical markets, platforms and applications. However, when it comes to planning and budgeting, most utilities are still acting like they’re dealing with apples and oranges even though virtually every platform uses fundamentally the same hardware and foundation software.
For decades, users have been screaming for broader use of standards and improved interoperability. Guess what, folks; it’s here! In fact, even systems with, heretofore, disparate components and applications can increasingly be procured from a single source, due in part to recently escalating merger/acquisition activity among automation/IT suppliers.
So, why then do utilities go on planning and budgeting for automation the old way, implicitly pretending that these are still isolated projects that have nothing in common with one other? Why keep trying to justify a system one year that needs the 2-way communications backbone that won’t be budgeted until two years later in order to make the cost-benefits analysis work? Why not change the budgeting process to buy solutions – whatever fiscal or departmental boundaries that might cross – rather than simply buying equipment? The answer is actually quite simple, I think: Go for the bananas! (Sometimes a little shock is a good thing.)
_____________________________________
About the Author
Mike Marullo has been active in the automation, controls and instrumentation field for more than 35 years and is a widely published author of numerous technical articles, industry directories and market research reports. An independent consultant since 1984, he is co-founder and Director of Research & Consulting for InfoNetrix LLC, a New Orleans-based market intelligence firm focused on Utility Automation and IT markets. Inquiries or comments about this column may be directed to Mike at MAM@InfoNetrix.com. ©2006 Jaguar Media, Inc. & Michael A. Marullo. All rights reserved.
At one time or another, someone has probably suggested to each of us: You need to know what you don’t know! (Or, at least something along those lines.) However, there is also a little known corollary to that axiom regarding not just knowing what you don’t know but why you don’t know it. Yet although we do many things by rote (heck, if we had to analyze everything as if we’re doing it for the very first time we’d never get anything done!), there is also an argument to be made for understanding why we do things the way we do – especially when millions of dollars are involved. Maybe – just maybe – there’s a better way.
Thinking about this reminded me of a behavioral research project I heard about many years ago that went something like this:
First, they put a monkey in a room housing a single banana tree. At the top of the tree was a bunch of bananas connected to an electrified wire. As soon as the monkey went after the bananas, he received a mild electric shock, and after several attempts, he finally stopped trying to get the bananas.
Then, one by one, they let additional monkeys into the room. Predictably, each immediately went for the bananas, but before getting halfway up the tree, monkey #1 yanked each newcomer down by the tail. Then, after several new monkeys had tried and failed each time they tried to get the bananas, they all finally succumbed to the reality that the tree was off limits. At this point, the original monkey was removed from the room. (Remember, he was the ONLY monkey who was ever actually shocked trying to grab the bananas!) But even after he was removed, none of the other monkeys tried to go after the bananas again, even though the protector of the bananas (aka monkey #1) was gone.
Here’s where it gets really interesting. A short time later, a new monkey – one that had never been in the room before – was allowed to enter. Spying the ripe bananas, he immediately made a beeline for the tree, but each time the new monkey tried to climb the tree, he was slammed back to the ground by one of the other monkeys in the room. After several more failed attempts to win the tempting banana prize, albeit without ever being shocked, he too finally gave up the quest.
What’s interesting to note here, of course, is that none of the monkeys in the room at that point had any first hand knowledge of exactly why the bananas were off limits, nor did they know what would happen if they actually got their hands on them. They just “knew” that going up that tree after the bananas was not a choice – without having a clue in the world why not! That is to say: They had a good handle on what they didn’t know; they just didn’t know why.
Okay, so we’d all like to think we’re better than a bunch of monkeys, but I’ll bet we can all identify something we learned do a certain way yet don’t have any idea whatsoever why we do it that way. Before you waste any valuable time on this mental exercise, let me save you some time while also bringing this theory back into the real world of automation.
Within the first few years after starting out in this field, I had the opportunity to work on a wide range of automation projects in various market sectors including oil/gas pipelines and production; gas, electric and water/wastewater utilities; heavy rail, light rail and vehicular transportation; telecommunications networks; and discrete, batch and continuous process industries. At that time, the projects were all very different, using different hardware (there was no software then!) and employing very different technologies and operating philosophies.
Appropriately, each project within a given market sector was planned, designed, budgeted, implemented and supported on its individual merits. There was no “cross platform” technology – it was still a very proprietary world at that point – and the concept of interoperability had not yet been seriously contemplated; in fact, I’m not sure the term even existed in the automation vernacular of the day. So, everyone went along their merry way, albeit in blissful ignorance, that any of their efforts could, should or ever would be shared with their comrades on the other side of the cubicle.
However, as the years wore on, share they did. I recall one municipal water utility customer in the early 1980s that bought a SCADA system from the supplier I worked for at the time. They were quite proud of the fact that the system they purchased shared absolutely nothing with the electric utility side of the house. Although the water and electric factions sat on opposite sides of the same hallway, they might as well have been in different countries; they wanted nothing to do with one another, mainly because they were convinced that they had nothing in common.
About five years later, I came across a friend of mine at a conference who had worked for the electric side of that same utility. Inevitably, the conversation came around to the system they had purchased from us. When I asked him if the system had been changed or expanded, he told me that the whole master station had been scrapped along with that for the electric side and was being replaced by a new computer host that would talk to all of the legacy water and electric RTUs (remote terminal units) that had been purchased from disparate vendors at various times. I suppose that was the beginning of not just an evolution, but perhaps what might even be termed a revolution that brought us to where we are today.
Indeed, over the decade or so that followed, the now widely accepted concepts of COTS (commercial off-the-shelf) automation products and interoperable systems caught on, slowly at first, but eventually reaching an avalanche pace. Today, no one even contemplates buying proprietary solutions and multipurpose offerings are plentiful, often crossing vertical markets, platforms and applications. However, when it comes to planning and budgeting, most utilities are still acting like they’re dealing with apples and oranges even though virtually every platform uses fundamentally the same hardware and foundation software.
For decades, users have been screaming for broader use of standards and improved interoperability. Guess what, folks; it’s here! In fact, even systems with, heretofore, disparate components and applications can increasingly be procured from a single source, due in part to recently escalating merger/acquisition activity among automation/IT suppliers.
So, why then do utilities go on planning and budgeting for automation the old way, implicitly pretending that these are still isolated projects that have nothing in common with one other? Why keep trying to justify a system one year that needs the 2-way communications backbone that won’t be budgeted until two years later in order to make the cost-benefits analysis work? Why not change the budgeting process to buy solutions – whatever fiscal or departmental boundaries that might cross – rather than simply buying equipment? The answer is actually quite simple, I think: Go for the bananas! (Sometimes a little shock is a good thing.)
_____________________________________
About the Author
Mike Marullo has been active in the automation, controls and instrumentation field for more than 35 years and is a widely published author of numerous technical articles, industry directories and market research reports. An independent consultant since 1984, he is co-founder and Director of Research & Consulting for InfoNetrix LLC, a New Orleans-based market intelligence firm focused on Utility Automation and IT markets. Inquiries or comments about this column may be directed to Mike at MAM@InfoNetrix.com. ©2006 Jaguar Media, Inc. & Michael A. Marullo. All rights reserved.
