Understand the Impact of Change



Understand the Impact of Change

Doug Crawford

A good ARCHiTECT REduCES CoMplExiTy To A MiniMuM and can design a solution whose abstractions provide solid foundations to build upon, but are pragmatic enough to weather change.
The great architect understands the impact of change—not just in isolated software modules, but also between people and between systems.
Change can manifest in a variety of forms:
• Functional requirements change
• Scalability needs evolve
• System interfaces are modified
• People in the team come and go
• And the list goes on…
The breadth and complexity of change in a software project is impossible to fathom upfront, and it’s a fruitless task trying to accommodate every potential bump before it happens. But the architect can play a crucial role in determin- ing whether the bumps in the road make or break a project.
The architect’s role is not necessarily to manage change, but rather to ensure that change is manageable.
Take, for example, a highly distributed solution that spans many applications and relies on a variety of middleware to glue the pieces together. A change in a business process can cause havoc if the set of dependencies is not correctly tracked or accurately represented in some visual model. The impact down- stream is particularly significant if the change affects the data model or breaks existing interfaces, and the existing long-running, stateful transactions must successfully complete under the old version of the process.

This example may appear extreme, but highly integrated solutions are now main- stream. This is evident in the choice of integration standards, frameworks, and patterns available. Understanding the implications of change in these outlying systems is critical in ensuring a sustainable level of support to your customers.
Luckily, there are many tools and techniques to mitigate the impact of change:
• Make small, incremental changes
• Build repeatable test cases and run them often
• Make building test cases easier
• Track dependencies
• Act and react systematically
• Automate repetitive tasks
The architect must estimate the effect of change on various aspects of the proj- ect’s scope, time, and budget, and be prepared to spend more time on those areas whose impact would be the greatest as a result of “a bump in the road.” Measur- ing risk is a useful tool for knowing where your valuable time should be spent.
Reducing complexity is important, but reduced complexity does not equate to simplicity. The payoff for understanding the type and impact of change on your solutions is immeasurable in the medium- to long-term.
Doug Crawford manages a team of middleware developers for a telecommunica- tions company in South Africa. He spent the last 10 years fitting square pegs into round holes, and has been intimately involved on application integration projects in a range of industries: advertising, corporate banking, insurance, and education.