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

The need for an innovative look at innovation efforts

innovation unlock.pngI’ve been in a number of discussion lately looking at innovation activities. In today’s dynamic business environment, the status quo is riskier than changing – sometimes it may not matter which direction you move, as long as you’re not standing still.

 

I am a big advocate for gamification, but most of these efforts are based on a bottoms-up approach that tries to leverage the ‘intelligence of the crowd’. Some interesting things definitely do come out of these efforts, but rarely are they directed on what is really needed. If 5% can be implemented, you’re doing great with these approaches.

 

That is where top down approaches to innovation come into play. They try to focus the innovation flow around a specific concern or issue. I used the term flow, because it’s happening, whether we tap into it or not – innovation is just part of being human. Top down in combination with a bottoms-up approach are more effective. Yet – they’re not effective enough.

 

I have figured out a few things (that are probably obvious to most):

  • Innovation needs a strategic focus. At the same time, the chance of getting it right the first time is slim, so an approach needs to be both strategic and agile (at the same time).
  • Innovation needs to be part of the mindset of the people involved. For many organizations, innovation doesn't feature anywhere in their plans and that’s a shame. This can be true for entrepreneurial organizations as well as large corporations. I mentioned strategic importance of innovation, yet culture eats strategy for lunch.
  • If you want to grow, you need to find a way of embedding innovation in your strategic priorities – and that means investment. It also needs to be focused on what you do and how you do it. This is one of the most frustration parts of working in the IT space. We think that being innovative in IT is something that should be recognized by the rest of the business. In many ways, they pay us (particularly service organizations) so they don’t need to see it at all – let alone view it as innovative.
  • Innovation efforts need to be measurable. Just because ideas are new, doesn’t mean there won’t be a ruler to measure progress. There will be one, why not plan on it.

A while back I mentioned that one of the first laws of technical leadership is “don’t discourage them”. The same can be true about the approach to innovation. At the same time, innovation efforts need to be focused on outcomes -- we actually need to do something and not just think about it.

 

I have come to the conclusion that we need a more innovative approach to innovation, since the whole concept is full of conflicts. One of the first things that is probably always true though is the need to develop a common understanding and definition of innovation, since it can mean so much to so many .

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.

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.

Dimensions of assessing an agile architecture?

measurement.pngI keep hearing that organizations have greater expectations from their IT organizations than are being delivered. Shadow IT is the response as the business-side of the enterprise decides to go-it-alone. Many times those investments are done in a relative vacuum when compared to the rest of the organization’s portfolio.

 

As businesses move to be more agile and make better informed decisions, the focus is on being flexible in a number of dimensions:

  • Location – where and when works takes place
  • Social – relationships with and between customers, partners, devices and employees
  • Secure – what, why and how much in good enough
  • Process – for the past, now and in the future
  • Insight – what is and will be happening, and why

In continuing to think along the lines of the post on agile architecture, it makes me wonder how an architecture can be measured along these lines in the dimensions of time and value. Even though the requirements for the architecture can’t be nailed down do the perspectives (like those listed) remain constant? Should we also build into our thinking how long we think the architecture element is viable? That can be a tough issue as evidenced by the continued contributions of mainframes, COBOL and other technologies that are pretty far along the ripe cycle.

 

I recently read a thought provoking article titled: Management in the Second Machine Age that made me wonder about the effects of automation on IT architects as well. If you can measure it, you are closer to being able to automate it.

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