It's the Thought that counts

It's the Thought that counts

I had a thought. One I wanted to share. As I thought further, I realized there were a hundred different ways to get that thought out. My first inclination was to post it on my blog, then propagate it through my Twitter account, Facebook account, and my 11,000+ followers on LinkedIN. But there was a problem. The shear amount of noise that would surround my thought could easily drown it out.

Billions of people all over the world share their thoughts electronically with everyone they know and even those they don’t. So, what separates one thought from another? Why would people spend their precious time looking at my thought versus the millions of other thoughts that are competing for their attention?

This made me focus my thoughts through a business lens. Could I create a process in which I could share specific thoughts with people that would enjoy them or gain the most from them? Could this also be something that my professional network could leverage to get their own thoughts out?

One of the most expansive and rewarding communities I participate in, is the Industry group I started earlier this year called Infrastructure Masons. It is a group of professionals who are responsible for designing, building and operating the logical and physical structures of the digital age. The engines they build drive the Internet of Everything. Literally! If you are using an electronic device attached to a network, you are leveraging the infrastructure they have deployed.

Thinking of this community has helped me narrow down what I would like to share. More importantly, I realized that iMasons could become an ideation platform for our members.

This isn't a new approach. Like most of my peers, I have created and distributed content through many industry organizations over the years. So why reinvent the wheel? Because the old methods are painfully slow and limiting. At our first leadership summit in November of 2016, many of the members confirmed this. In previous organizations it was just too difficult to release content. First, the internal debate compounded by continuous technical, leadership and legal reviews delayed the releases by months, even years. Secondly, everyone assumed that the paper had to be perfect. The couldn't release "ideas" or "concepts", they had to be proven and validated before release. Finally, many groups limited what members could say due to controversial topics and potential liability that the industry group was unwilling to take on. By the time the content was published it was out of date or irrelevant. We decided to flip this on its ear.

The best way to have a good idea is to have lots of ideas - Linus Pauling

Today we are officially launching iMasons Thoughts - these are papers written by members to share ideas, concepts, challenges and contrarian views. The author(s) own the content, the opinion, and the discussion/debate that will follow. The intent of these papers is to stimulate timely dialog to help advance the industry. These papers are not meant to be static. They will be tested by leveraging community feedback to refine, change, bench or even kill the ideas. What matters is the community engagement to hone those thoughts into something useful.

Our members have unique perspectives and insight built from their extensive experience. Their ideas need to be heard. The Thoughts program is to enable timely release and iteration of their ideas.

Our first publication comes from Oz Morales, former VP of Data Centers for Amazon, and a 2nd Degree Master Level Infrastructure Mason. During his tenure, he built one of the largest and most cost effective Data Center portfolios in the world. Oz reached out to me with a proposed methodology to measure the real performance of infrastructure systems. If effective, this should give executives a simple measure of how well their infrastructure investments, and the systems that were created from them, are performing. He calls it the Engineering Operations Ratio (EOR).

IM Thought Publications - https://imasons.org/pubs/thoughts

So what do you think? My thought is that his thought could become an interesting thought for others (and you thought my puns were over). :-)

If you would like an opportunity to publish your thoughts through Infrastructure Masons, become a member. For more information on the Thoughts process, contact [email protected].

Good one. ..pj May be some day when in the Bay Area, i will enjoy contributing. You still look like a kid. When are you gonna start looking like me :- ) ?

回复

Hello Rob. All the best my friend.

回复
Brent E.

Architect FinOps - Strategic Operations Finance

7 年

I see this as one of the layers. I would recommend approaching the layers by inception points of usage/waste/inefficiency at the top and work down. Top is Code, 2nd Computing Stack, 3rd Facility. I think your car reference to how different measures of the F1 car at ideal peak or something less is what we are after. However you need to know what measurements are going to let us quantify and visualize the delta's. Lap time, acceleration, load capacity, HP, MPG, braking distance, Revenue/Profits per race, etc. Let's say 1 million fans want tickets that day. The developers/customers demand the app to do work and the code triggers requests and processes those. That code depends on the computing tech stack for handling the code to customer value. That computing tech stack depends on physical things at the facilities layer. The code could be running poorly architected legacy methods/calls little caching etc on average oversized and medium age tech stacks from 2-4 years ago, in a facility with 1.4 PUE in a high cost electricity datacenter in Los Angeles. If we just change the code and the computing stack(SW only, not HW changes) and see the same amount of work processed at a very small fraction of the physical facilities layer, where do we account for the improvements? The facility level measurements did not get any more efficient simply because the computing software and the code changed, yet that typically has the most profound effects on power consumption, cooling, space needed to do work for the organization. Remember the old IBM commercial of the guy sitting by one rack in the middle of empty datacenter. I have seen many datacenters with 5-10 CapEx Utilization ratios of the computing stack. The cooling, power, space optimizations are near all time high and not sure what else will give the remaining few % of optimization. The next long term trend of datacenters showing large improvements in things like # of transactions per KWhr, $ Revenue per KWhr that take into consideration Code, Compute, Facility layers are where the biggest opportunities lie. **I know Dean knows this as they ate PIE at ebay. Physical, Infrastructure, Engineering. Love this paper https://law.stanford.edu/wp-content/uploads/sites/default/files/publication/442226/doc/slspublic/Stanford%20eBay%20Case%20Study-%20FINAL-130926.pdf on page 16. Maybe the metrics are per layer for each Application then those all rollup? Code layer has 50-90% improvement possible, Computing stack 50-85% possible, Facility has 5-15% improvement possible. This is much more meaningful to me and the way we build software products and budget/account for them on the backend. Thoughts?

Steve Harrington

CEO at Chilldyne | Expert in thermodynamics, fluid dynamics, and liquid cooling systems

7 年

These seems overly simplistic to me. How solid is the design spec? How much does it cost to over or under design the system? is an over designed system more reliable or less efficient? All these factors do not fit into the ratio, but they all matter.

回复
Gabe Andrews

Vice President Operations | Data Center Operations, Product Delivery | MBA | Data Center Design Planner for High Density, Efficiency, & Agility | Team Leadership, Process Improvement Specialist

7 年

Number 1 the intent of Thoughts is perfect and well timed. I have been looking for places where ideas are shared without being fully baked out and allowed for the "community" to expand and work towards a finished product. As you noted there is such a lag in the release of many conceptual ideas due to the need to only deliver to market papers and articles that are proven out. Ideas like EOR presented by Osvaldo Morales are what the market needs to continuing pushing forward. Appendix B of the paper touches on the need for the baseline to not be a one time permanent stamp, but rather to monitor and update over time. The base line design PUE is set at completion of design review, then validated/updated at commissioning, and finally may be validated/updated based on geographical deployment. As I read this it stuck me as very common sense, but not something that is openly reviewed and discussed. Most certainly it is not a topic which I have considered, but will now carry forward in discussions.

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了