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

2015 resolutions for technologists??

Happy New Year.jpgI was looking at the January 1st issue of CIO magazine over my holiday break and saw an article by Steve Andriole titled: Go Play with Technology (unfortunately, there was not a link to it on line – yet). It discussed the value of experimentation vs. gathering requirements, especially in areas that are new. The article advocated getting your hands dirty with some of the newer technologies, since access is now cheaper and more flexible than it has ever been before.

 

Lately, I’ve been talking to some individuals for a set of architect roles and one of the questions I always ask is: “What’s been your experience in setting up a virtual machine in the public cloud?” Not to find out if they are an expert, but more to determine their level of curiosity and experience. If the role they are targeting is dealing with analytics then I ask them about their various data warehouse or even DBA experiences. No matter the level of experience described, it is always a useful discussion.

 

We all need to push each other to know and experience more. Pushing each other would be a good resolution.

 

If you want to define a new year’s resolution about getting up to speed on some of the newer technologies, there are plenty of on-line (free) courses taking place. Here is another CIO magazine article that might be of some use: 8 Free Online Courses to Grow Your Tech Skills

Will the Internet of Things turn all CEOs into CIOs?

 

CEO.pngSince the CIO's role is focused on generating business value out of information securely and reliably, and now an ever increasing percentage of our enterprise environment will be collaborating in that goal – the CEO’s dependence and need to manage the use of information will increase.

 

IoT means sensitive information, can be derived leading to information about enterprise operation details and personal data crossing from secure networks to devices and third party services. The risk and the benefit are far different than what traditional CIOs have had to address. The CEO will need to understand (at least at some level) the rapidly changing world of security and information consumption and the implications of IoT – even if it is just to make sure that the delegated business and IT responsibilities are being addressed effectively.

 

Some view that IoT hype has peaked. If that is the case, it would only be because organizations have internalized the change, but I doubt that. I think we have a long way to go before the possibilities are even well understood, let alone embraced and incorporated to generate value outside the initial deployment silos.

Leaders need to ask two questions:

  • So what? – find out the perspective of business value for the effort
  • Is that all? – see if the teams are thinking broadly enough about where and how the information can be used. There seems to be a great deal of potential being left on the table.

 

Is it time for a Chief Automation Officer?

Automation officer.pngOver the last few years, there has been quite a bit of discussion about the race against the machines (or the race with the machines), based on the abundance of computing available. When I think about the IoT and its implications on business, it may be that information is just a side effect of an entirely different corporate strategic effort.

 

Maybe there is a need for a Chief Automation Officer more than a Chief Information Officer going forward?!? Someone who looks at the business implications and opportunities for cognitive computing, sensing, robotics and other automation techniques.

 

Or is automation just assumed to be part of all future strategic planning activities. As I began thinking about it, it’s clear that others have thought about this CAO role as well, although mostly from an IT perspective instead of one based on business need. It could be viewed that this is a role for the CTO or even the enterprise architect.

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??

Is an Agile Architecture in your future?

agile architecture.pngA few weeks back I did a post on agile development and that got me thinking about the future of architecture and the need for agile architecture.

 

The same pressures of shifting needs are present at the macro level and should affect the creation and use of architecture work products – although since it is architecture it will be a bit different than agile development.

 

Some of the same principles apply:

  •          People – Architecture lives at the intersection of business and technology. People are at the focus of that intersection, not technology. Architectural efforts should focus on the effect upon the people involved. What needs to happen? How will it be measured? These factors can be used to make course corrections along the way – once you realize that an architecture is never finished. If it doesn’t deliver as expected, change it. Make the whole activity transparent, so that people can buy in, instead of throw stones.
  •          Continuous change – When you begin to think of the business as dynamic and not static, the relationship with the real world becomes clear. In nature those species that are flexible and adjust to meet the needs of the environment can thrive – those that can’t adjust die off.
    Architectures need to have standards, but it also needs to understand where compromises can be made. When talking with CIOs the other day, it became clear that ignoring Shadow IT efforts doesn’t mean you will never need to support them. It is better to understand and facilitate their effective use (through architecture), rather than try and stand in the way.
    In a similar way, the link between the agile projects and the overall architecture need to be recursive. Building upon the understanding that develops. The architecture does not stand alone.
    Architecture development can also have short sprints of understanding, documenting and standardizing the technical innovations that take place, while minimizing technical debt.
  •          Focus on business goal based deliverables – Over the years, I’ve seen too many architectural efforts end up as shelf-ware. In the case of architecture, just-in-time is probably the most effective and accurate approach.
    If the architecture work products can be automated or at least integrated with the tooling used in the enterprise, it will be more accurate and useful. The concept of machine and human readable work products should be part of any agile architecture approach.
    From a goal-based perspective, the architecture needs to understand at a fundamental level what is scarce for the organization and what is abundant and then maximize the value generated from what is scarce – or at least unique to the organization.
  •          Good enough – Don’t let the perfect architecture stand in the way of one that is good enough for today. All too often I’ve seen architecture analysis go down to 2 or 3 levels of detail. Then people say “if 2 is good, let’s go to 5 levels of depth.” Unfortunately, with each level of detail the cost to develop and maintain goes up by an order of magnitude – know when to stop. I’ve never seen a single instance of where these highly detailed architecture definitions where maintained more than 2 or 3 years.
    The goal should be functional use, not a focus on perfection. Architecting the simplest solution what works today is generally best. If you architect the solution for something that will be needed 5 years out, either the underlying business need or the technical capabilities will change before it will actually be used.

None of this is really revolutionary. Good architects have been taking approaches like this for years. It is just easy to interpret some of the architecture process materials from an ivory tower perspective.

Search
Showing results for 
Search instead for 
Do you mean 
Follow Us
Featured
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.