The Next Big Thing
Posts about next generation technologies and their effect on business.

The need for automated environmental validation in IT

action 002.jpgI was recently reading the post When disaster strikes: How IT process automation helps you recover fast and it got me thinking about the need for automated environmental validation. Recovering fast may not be good enough if the recovery destination environment has changed.

 

In the software space, you can use jUnit or nUnit to codify the limits of the code and make sure it works, and breaks as defined. It can be a very useful component of a test first unit testing approach.

 

I was wondering if infrastructure automation efforts should include a similar capability that we can automatically test an environment to ensure its characteristics are up-to-snuff, before and after we make a change. These tests could either be run periodically, or as part of a promotion to production process.

 

Automating this validation would remove the human element from this tedious step. It seems like this would be a useful and possibly necessary step for cloud deployments, since those environments are dynamic and beyond the scope (and understanding) of the person who wrote the original programs. Maybe this is commonly done, but I've not talked to many who attack this issue proactively.

Metrics usage in an agile approach

change.pngA couple of months ago, I did a post on: The supply and demand issues of governance, including issues that cause organizations to be blindsided by events.

 

Lately, I’ve been thinking about this a bit more but from the metrics side -- defining and collecting the leading and lagging indicators of change associated with governance. There is quite a bit of material on this concept, but this link to a definition on leading indicators is focused on economic leading indicators. The concepts for business processes are similar.

 

Leading indicators show progress, lagging indicators confirm completion (examples on this perspective made me dig up a post I did in 2009 about measuring cloud adoption). Most organization’s processes only have lagging indicators. These are metrics that identify we’ve hit milestones… This can allow efforts to get fairly far down a path before they can do course corrections. More predictive approaches are possible and needed to adapt to this changing approach to business.

 

When I look at applying gamification, I usually come up with numerous leading indicators since gamification is about influencing the work in progress. When approaching change, look for items that show improvement or change and not just validation of achievement.

Preventing the IoT from being the Oort cloud of the enterprise

riding comet.pngLast month, IEEE Spectrum had an article on how Most Technologists Upbeat About Future Internet of Things and I am optimistic as well --do you really think being down about it will prevent it from happening? I mentioned that ubiquitous power is a prerequisite for the IoT to really take off, at least for some applications.

 

On the same day I gave an IoT intro presentation I was in an exchange with CIOs about rogue clouds, in the process I made a joke pointing out that rogue clouds are the Oort cloud of IT - an area we don’t pay any attention to until something is about to impact our business.

 

There are a number of challenges for technologist to overcome. For every positive aspect, there is a negative trap to fall into and be prevented or at least understood.

 

Challenge

Positive

Negative

Privacy/Security

A view into what is actually going on

Passive oversharing

Identity

Knowing what is what

Device ‘identity’ mistaken for true identity- people become a network address

Efficiency

Speed

Unemployment

Decisions

Automation takes latency out

Loss of freedom and understanding, if automation becomes just another legacy system

Culture

Gamification

Big Brother and data bias

 

What are some of the other issues that have both positive and negative dimensions??

Other views about starting small but thinking big

Last week, I did a post titled: Start Small but think big, when transforming. Fairly quickly I got a note from Erik van Busschbach from HP SW that said he’d made some similar statements related to cloud adoption. In fact he even had a video about his perspective. 

 

 Think big, start small.jpg

 

Next week at HP Discover, I hope to track Erik down (who is the Chief Technologist, World Wide Strategy & Solutions for HP Software) and talk about the nuances of our perspectives. He also wrote a post on an HP SW blog about: Why the IT Value Chain is your blueprint for strategically regaining control of IT that also contains the start small but think big concept.

 

Even if we’re coming at the problem from different perspectives, the fact that much of what we’re talking about ends up at the same result is reaffirming. 

Start small but think big, when transforming

StartSmallThinkBig.jpgYesterday, I posted about how we’re half-way through the current stage of IT and mentioned how IT needs to change. Today, I saw an interesting post from McKinsey & Company that has some similar views: Reinventing IT to support digitization.

 

They have identified seven elements critical to IT performance improvement:

1)      Clear, central business leadership on digital

2)      Elite IT talent

3)      Sourcing arrangements to scale the workforce rapidly

4)      Agile development and rapid releases

5)      Rapid innovation architecture supported by stable services

6)      Scalable cloud-based infrastructure

7)      High-quality integrated data

 

I agree with all those points, although I’d have dropped off the ‘on digital’ from the first point. I think all too often we continue to unnecessarily isolate the information technology goals and efforts from the business.

 

The article went on to describe a two-speed approach to transformation. This is one area that is as much about risk control as providing new capabilities. Start small but think big – is probably the rule. We can’t change everything at once and when making this kind of change, you need to develop experience.

This was driven home to me the other day when I was talking with my son (who teaches on-line). He was looking for a way to contact his students in a flexible, yet automated fashion. I said “Oh, no problem. I’ll just write an app for your phone.” I’ve written apps for a number of different mobile platforms over the years, so I thought it would be easy. I laid out a storyboard of the various screens. I bounced requirements off him. I knew exactly what I wanted to do, to make it look professional.

 

I dug into coding the first prototype. It seemed everywhere I turned, the Android environment didn’t want to support me in my efforts. It just didn’t have the fundamentals in the OS that I needed (or maybe the way I wanted them). So, I started to break the application down into various components that I could understand, validate and execute. Eventually, I will stitch them all together into a final application, but my first goal now is to get something dumb and functional that he can play with – without all the bells and whistles that were in the early design. A page out of any Agile Development handbook.

 

The same approach is needed as an organization starts to tackle its larger business support role and reinvention of its application portfolio.

Search
Showing results for 
Search instead for 
Do you mean 
Follow Us
About the Author(s)
  • Steve Simske is an HP Fellow and Director in the Printing and Content Delivery Lab in Hewlett-Packard Labs, and is the Director and Chief Technologist for the HP Labs Security Printing and Imaging program.
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation