Jul 112017
Software Risk is Business Risk. Who's Responsible for Mitigating It?

Cutter Consortium Senior Consultant Pete Kaminski has been looking at the business risks posed by software, and how to mitigate them. He gives context to the issue this way: “Driving business risk down is just smart business. Software-related business risk is an increasing portion of business risk, so knowing how to assiduously reduce software risk has become part and parcel of today’s business reality. Fortunately, there is an array of tools and methods that you can apply across your portfolio of software assets and development projects to manage software risk, which we’ll explore in this Executive Update. Industrializing software risk management is critical for organizations in the digital age. It unleashes the “smarts” in developers Read more

Mar 262016

Life complexifies. Perhaps it is a fundamental law of information that the complexity of information increases. In the world of biology, over time organisms become more complex, with new genetic permutations appearing alongside of old genetic pieces. In the hyperastronomical space in the animal genome, nature constantly produces new combinations. In human knowledge and scientific discovery, the same is true. New insights are built on top of old ones. Breakthroughs in insight usually have higher levels of complexity and hence require higher levels of abstraction and difficult codification to accommodate the widening domain covered. We all know E=MC2 but how many of us really know what it means? In the world of medicine, treatments are Read more

Apr 272015
Truly, One Size Does Not Fit All

Software development is not really a single discipline. What comes under the overall field is a combination of disciplines that address a range of problems: Maintaining and evolving fielded code Adding significant new features to an existing application or platform Building an entirely new application or platform These differ in the amount of innovation required and the amount of information available for delivering a quality system. Teams working on type 1 problems generally are not required to invent anything and they have detailed information on the code change required and available technology. Teams addressing type 2 efforts may need to be innovative in building out and integrating the capability. Also, they usually have incomplete information Read more