Using Software Value to Drive Organizational Transformation

I was delighted to read a thought leadership article from McKinsey recently, “How to start building your next-generation operating model,” that emphasizes some key themes that I have been pushing for years (the quotes below are from the article):

• The importance of orienting the organization around value streams to maximize the flow of business value – “One credit-card company, for example, shifted its operating model in IT from alignment around systems to alignment with value streams within the business.
• Perfection is the enemy of good enough – “Successful companies prioritize speed and execution over perfection.
• Continuous improvement relies on metrics to identify which incremental, experimental improvements work and which don’t.  Benchmarking and trend analysis help to prioritize areas where process improvement can offer the most business value – “Performance management is becoming much more real time, with metrics and goals used daily and weekly to guide decision making.”
• Senior leaders, “hold themselves accountable for delivering on value quickly, and establish transparency and rigor in their operations.
• “Leading technology teams collaborate with business leaders to assess which systems need to move faster.”

There is one “building block” for transformation in the article to which I am a recent convert and so kudos to the McKinsey team for including it in this context.   Their “Building Block #2” is “Flexible and modular architecture, infrastructure and software delivery.”  We are all familiar with the flexible infrastructure that cloud provides, but I have been learning a lot recently about the flexible, modular architecture and software delivery for application development and application integration that is provided by microservices frameworks such as the AnyPoint Platform^TM from Mulesoft.

While they promote organizing IT around business value streams, the McKinsey authors identify a risk to be mitigated in that value streams should start to build up software, tools and skills specific to each value stream.  This might be contrary to the tendency in many organizations to make life easier for IT by picking a standard set of software, tools and skills across the whole organization.  I agree that it would be a shame indeed if agile and lean principles that started life in IT software development are constrained by legacy IT attitudes as the agile and lean principles roll out into the broader organization.

There are a lot more positive ideas for organizational transformation in the article, so I recommend that you take a few minutes to read it.  My only small gripe is that while the authors emphasize organizing around value throughout, they do not mention prioritizing by business value.  Maybe at the high level that McKinsey operates in organizations that concept is taken for granted.  My experience is that as soon as you move away from the top level, if business value priorities are not explicit, then managers and teams will use various other criteria for prioritization and the overall results may be compromised.

This blog was originally posted at https://www.softwarevalue.com/insights/blog/posts/2017/march/using-software-value-to-drive-organizational-transformation/.

Algorithms: What are They Worth and What Might They Cost You?

Every so often, I read an article that gets me thinking in a different way about software value and software risk.  Danilo Doneda of Rio de Janeiro State University and Virgilio Almeida of Harvard University recently published an article entitled, “What is Algorithm Governance?[1]”

Doneda and Almeida suggest that the time may have come to apply governance to algorithms because of the growing risks of intentional or unintentional, “… manipulation, biases, censorship, social discrimination, violations of privacy and property rights and more,” through the dynamic application of a relatively static algorithm to a relatively dynamic data set.  

By way of example, we have probably all experienced the unintended consequences of the application of a reasonably well understood algorithm to new data.  We all have a basic grasp of what the Google search algorithm will do for us but some of you might have experienced embarrassment like mine when I typed in a perfectly innocent search term without thinking through the possible alternative meanings of that set of words (No, I’m not going to share).  At the other end of the spectrum from the risk of relatively harmless misunderstandings, there is a risk that algorithms can be intentionally manipulative – the VW emission control algorithm that directed different behavior when it detected a test environment is a good example. 

For those of us who deal with outsourcing software development, it is impossible to test every delivered algorithm against every possible set of data and then validate the outcomes. 

If we consider software value, from a governance perspective, it should be desirable to understand how many algorithms we own and what they are worth.  Clearly, the Google search algorithm is worth more than my company.  But, are there any algorithms in your company’s software that represent trade secrets or even simple competitive differentiators?  Which are the most valuable? How could their value be improved?  Are they software assets that should be inventoried and managed?  Are they software assets that could be sold or licensed?  If data can gather and sell data then why not algorithms?

From a software metrics perspective, it should be easy to identify and count the algorithms in a piece of software.  Indeed, function point analysis might be a starting point using its rules for counting unique transactions, each of which presumably involves one or more algorithms, though it would be necessary to identify those algorithms that are used by many unique transactions (perhaps as a measure of the value of the algorithm?).  Another possible perspective on the value of the algorithm might be on the nature of the data it processes.  Again, function points might offer a starting point here but Doneda and Almeida offer a slightly different perspective.  They mention three characteristics of the data that feeds “Big Data” algorithms, “… the 3 V’s: volume (more data are available), variety (from a wider number of sources), and velocity (at an increasing pace, even in real time).  It seems to me that these characteristics could be used to form a parametric estimate of the risk and value associated with each algorithm. 

It is interesting to me that these potential software metrics appear to scale similarly for software value and software risk.  That is, algorithms that are used more often are more valuable yet carry with them more risk.  The same applies to algorithms that are potentially exposed to more data. 

[1] Doneda, Danilo & Almeida, Virgilio A.F. “What is Algorithm Governance.” IEEE Computer Edge. December 2016.

Mike Harris, CEO