Bookmark and Share
RSS

Recent Posts

Modernizing Application Change

September 12, 2016

This week, I’ll explore modernizing the way applications are created and supported through change management. Existing applications were created in one way—is this the way modernized applications should be changes and sustained in the future? 
 
Methods That Evolved
In the past, there were fewer approaches to developing an application where a framework called waterfall dominated. As time went on and teams gained experience, additional ways were tested and became mainstream. Different approaches evolved to lower risk, save time and produce more useful results.

Today, many processes and approaches support software development. You will recognize the names including waterfall, prototyping, incremental, spiral, rapid, extreme, agile and DevOps. These frameworks are often related to one another in subtle ways. In practice, many methods have built upon each other over decades becoming the next best approach. Each can be explained by describing its basic operation and principles, as well as its fit for specific projects based on a number of factors.

What factors influence which one to use? Some approaches work better for less experienced teams, whereas others require expert teams. Some frameworks are a good fit for organizations that choose to have high organizational participation, whereas others work best when teams are autonomous. Some processes favor minor efforts, whereas others are best for large and complex projects. Finally, some approaches are designed to respond to the rapid need for application change whereas others are favored for applications where changes is made more slowly like yearly software releases.

Approaches to New Needs
Today, many existing applications are under pressure to change at very rapid rates. What method facilitates rapid change to an application? How can these changes be made in a way that is well tested and secure and timely?

A method that is being used to address this need is called DevOps, which is development and operations, two phases associated with application creation and support. Why join development and operations in this way? There has always been a natural tension between change and stability. Developers are paid to create change in the form of new applications and changes to existing ones. When developing applications for the web, the changes often need to be made rapidly and frequently. On the other hand, the operations staff is paid to provide stability and the changes were hard for them to control and make with predictability as they enabled new and changed application functionality. DevOps seeks to reduce this tension and improve outcomes for the company and the users of the systems and applications.

DevOps focus is on two main goals: improved business agility and better alignment of IT with the company. Business agility is supported by DevOps through techniques to make more frequent software deployments possible through the increased use of automation for testing, as well as packaging for production distribution. Automation helps to maximize the predictability and efficiency of operational procedures, which is especially important when changes are made multiple times in a day.

IT alignment is supported because members of both development and operations are supporting the same goals using the same approach and a common toolset. Development, testing, quality assurance, maintenance and operations specialists are often part of the same team supporting the business goals of the company.
 
DevOps for All?
Companies make changes about the methods they use to maintain applications and to develop new ones. IT departments are smart and they know when a new IT approach is needed. Some organizations use legacy methods because they still work due to the composition of the team and the nature of the application. Others have looked for new ways to change and develop because of new challenges and they have found DevOps and similar methods. They change for good reason.

What’s Next?
I plan to explore internal modernization by writing about change and growth that has happened to legacy languages, files systems, databases and other elements of the modern application. Some modernization proponents say, “dump COBOL” but are you aware of the internal modernization that has happened within COBOL over the decades?

Posted September 12, 2016| Permalink

comments powered by Disqus