Development Methods and Architectural Styles
This is the first in a series on how applications are developed, with a focus on development methods and architectural styles that are gaining in significance. Methods aren’t the same as styles and some pairings work well together. This discussion starts with a bit of history.
Development Methods or Philosophies
Computer applications have been developed for over 50 years. During this time, ideas have changed quite a bit about the right way to develop them. Demands originating from the applications themselves have changed and driven the development and deployment methods used. Consider how two major software updates a year versus four incremental changes a day significantly influences the approach used to plan, change and deploy those modifications.
Architectural Styles
Architectural styles have also changed over the years. In the early days, applications were often designed so that they collected the daily data changes for the recurring update run. They did this because I/O devices were slow and other resources like computer time were scarce, so once a day was all that was possible. Batch was an architectural style that had certain goals and tactics like keeping run time to a minimum by reducing operator inputs and intervention. Part of the style included conventions like a master file that was updated from a transaction file containing all of the day’s updates.
Methods and Styles
In the past, we used the waterfall method of development paired with the pseudo-conversational architectural style for CICS. This was a common pairing. Waterfall was a good method for the time for many companies. It helped to roll out new application function in an orderly manner but not too quickly, as there were often limitations in the company as to how a company made IT changes. Requirements were gathered and shared. A plan for the release was developed in conjunction with a design for each block of new function. Along the way, with each deliverable, management and stakeholders were given a chance to weigh in and change the plan, order of the roll out, and make other inputs although these inputs understandably slowed the rate of change.
When teams started developing the code, they were aware of the constraints of the style. Because the style was pseudo-conversational, developers had the job of making the interaction with the application appear as one well-coordinated conversation whereas within the application code, they would use techniques like imbedding the next transaction identifier in the map on the display screen or use the “RETURN on TRANSID” technique when each part of the logical transaction was completed. Programmers also learned to save context data needed to continue the conversation at the display screen in temporary storage or transient data queues. This was the essence of the pseudo-conversational architectural style.
Other Methods Styles
Over the next few weeks, I’ll discuss other pairings of methods and styles that have become useful focusing on the drivers that have caused them to arise. Old methods and styles survive and sometimes thrive whereas new approaches reflect the changes in technology driven by human wants and needs.