Optimizing Software Development Sourcing To Drive More Customer Value

The past few years haven’t been kind to software developers. Having the equivalent of a US master’s in computer science and having spent the first 20+ years of my professional life developing mission-critical software products and applications, I have had a hard time adjusting to the idea that developing software applications is a cost to avoid or a waste of time for many CIOs and application development leaders. It seems to me that we have been giving more emphasis to contracts, legal issues, SLAs, and governance concerns but forgetting about how IT can really make a difference – through software development. 

Nevertheless, outsourcing kept increasing, and packaged apps exploded onto the scene, and software developers “outplaced” from enterprises. People started to believe they could get more value and good-quality software cheaper…but could they really?

With BT, digitalization, and customer centricity exploding, today is the perfect moment for application development leaders to review their application development sourcing strategy and align it to their BT strategy.

Why? Many reasons, including:

  1. Software is the most important enabling technology for business innovation.
  2. Clients use software every day. It’s become part of their life, and they enjoy the experience. Better software makes a better experience.
Read more

Agile And Compliance? Now That's A Product!

In my previous post about Agile practices and compliance requirements, I described the first of two big surprises encountered while doing the research. Compliance, as it turns out, is not quite as high a barrier to Agile as we thought. The second surprise has to do with the approach teams have developed to getting over or around that wall. 

Leaving Scrum, Sarbanes-Oxley, and related concerns aside for the moment, a hot topic these days in app dev circles is product-oriented development. While teams in IT departments might have different motives than ISVs, systems engineers, or people in other situations, they're all interested in roughly the same thing. What it takes to qualify as a product may not be altogether clear, and there may be no definitive way of measuring whether your team's thinking and behaviors have shifted from project-centric to product-centric. As rough-hewn as the concept of product-oriented development might be, it's still an attractive destination for people coming at it from multiple directions. (Not coincidentally, this is the topic of a soon-to-be-published doc.)

In an unexpected way, many of the app dev teams that have been most successful at dealing with compliance are, as it turns out, acolytes of the product-oriented approach. They may not realize it, as their work output may not be any more productized than it was before. Instead, compliance is what turns into a product.

Read more