Lessons Learned (or Not): Development and the Cloud
Talk about agile technology and how great things are because we can experience rapid software solution development and deployment via the cloud is shining a brighter light on certain IT management issues which have existed for quite some time, but perhaps went largely unrecognized. One of these issues is product development direction and influence, and where it really comes from. If you think most IT companies determine their product lines and offerings from the top down, with detailed specifications supported by a strong business case, you may want to think again. Based on my experience and that of a lot of other folks, there are many companies out there offering products and services that were crafted in more of an ad hoc manner than through a focused “product development” effort with long term sustainability in mind. In some cases, this demonstrates ingenuity and a desire to look at things in new ways. Sometimes it’s just uncontrolled and unstructured chaos with dollar signs attached.
“there’s a school of thought, put forward by the small but influential analyst firm RedMonk, that developers now occupy the role of IT kingmakers. This theory holds that the traditional model of IT adoption, which assumes that major decisions emanate from the top, is wrong. Instead, the decisions that appear to come from a CIO are, in fact, dictated by the choices made by people way down in the IT organization-the traditionally denigrated developers. CIOs merely ratify the decisions made by “lowly” developers.”
It goes like this: a high level concept comes from upper management… some “great idea”. This high level idea is communicated (at a high level) to the production teams who will make it real. The production teams decide what it really is, how it will really work, what it will look like, and how it will be offered – and all of this generally based on the preferences, skill sets, moral guidelines, belief systems, and work ethic of those involved in the development process. The product details are run back up the food chain, where they then become the defining elements of the new solution. In many cases, refinements and changes are argued against by the developers, citing various reasons or roadblocks to making changes to their prized construction. But hey – they got it ready to go out the door, didn’t they? So what if it’s not quite what you envisioned, and doesn’t necessarily represent a sustainable strategy?
Experience in business does count, particularly if you learn from it. There is a saying I heard once, and I’m still not sure how I feel about it other than it proves to be so very true each and every day. The saying is that “there is no morality without context”. In business, context is often experience, understanding the cause and effect of an action or activity. Without this learning, without the experience earned within the organization or by others, there is no context guiding the development.
“It’s irresistible to poke fun at some of the most egregious aspects of today’s IT practices-change control committees that only meet once every two weeks;ITIL implementations that place more emphasis on paper trails than actually, you know, getting things done; operations groups that resist application updates in the name of stability, and so on and so forth.
However, the fact is that these functions, if not their manifestation, exist for important reasons. Overlooking them-or outright ignoring them-is not the right solution. Ensuring that updates to production systems are made, and being able to track who makes changes to infrastructure, are enterprise functions are that won’t go away just because cloud computing is in the picture.”
Lessons previously learned will need to be learned again, and addressing problems after-the-fact is generally far more costly than being proactive and trying to avoid them in the first place. It can be a very painful process, watching the company go through puberty all over again (particularly if it had once reached some level of maturity), yet this is what can occur when the bright and shiny new idea causes management to forget fundamental lessons previously learned.
In a recent article on Computerworld.com, author Bernard Golden makes a number of really good and interesting points about the opposing viewpoints of this “agile” development enabled by the cloud (the article focuses on AWS – Amazon Web Services, but it is completely relevant in the broader context). Link here to access the entire post, it’s worth the read.