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

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.

HP Discover 2014 – see you there…

Channels_RGB_blue_NT.pngIf you’ll be at the June 10-12th 2014 HP Discover in Las Vegas, I hope to see you. As of right now, it looks like I am going to be talking about a number of different topics:

 

  1.        The new style of business value – pulling IT in the driver’s seat
  2.        Agile Architecture - springboard to IT value
  3.        Workplace of the future perspectives
  4.        I also heard rumors about being part of a panel to talk about business value generation.

I am sure there will be some changes to the titles or adding new topics, but last minute panic and public speaking seem to go together.

 

I’ll also spend some time in the meeting zone of the HP Discover Zone, if anyone wants to scheduled time to talk. Drop the coordinator a note, if you’d like to set up a meeting. I’ll also try to meet some of the bloggers that attend, if I can track them down - there should be a bloggers gathering space.

 

This event is a great opportunity where all the expertise will be in one place to answer just about any question that will come up. That saves times as well as provides a diverse set of perspectives enabling choice.

 

I just saw that Thomas Friedman will be speaking. Hopefully, we’ll not be dressed identically like the last time we met.

Search
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