Over a million developers have joined DZone.

Evaluating Enhancements

DZone's Guide to

Evaluating Enhancements

· Integration Zone ·
Free Resource

The Future of Enterprise Integration: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.

Software architecture is needed for enhancements too

This is a follow-up to Designing enhancements, where I briefly talked about how enhancements to existing software systems can benefit from the principles and practices of good software architecture, particularly where interfaces to other systems are involved.

Given the size of the enhancement project, we could have easily decided to deliver the whole lot in one go and in many ways this does seem the obvious thing to do. After all, it's only ~8 weeks of work for 2-3 people with a small scope and a limited complexity. But I decided against this and split the overall project into two distinct time-boxed phases as follows.

  1. The modification of one key use case, including integration with the third party end-to-end (happy scenario only, no exceptional scenarios).
  2. Delivery of everything else.

It wasn't the business logic associated with the interface between us and the third party that concerned me, nor was it the requirements around security or audit. No, for me, it was the actual connectivity between our application server and the Internet. As I said in the previous post, writing the code to send XML over HTTPS is easy but connecting out to the Internet from the architecture isn't something that's been done before. We knew that we'd need to open up firewall rules on the corporate LAN but this isn't something that I've seen done in this particular environment. For this reason, I wanted to deliver enough of the solution (the architecturally significant bits) to evaluate and prove that the connectivity would work as expected.

We delivered that first phase a couple of weeks ago now and initially the connectivity between the application server and the Internet *didn't* work! Everything was installed correctly and firewalls were configured, but we just couldn't find a direct route out of the network. Despite everybody saying that it wouldn't be a problem, it turned out that we'd need to send the traffic via an existing proxy server, which would only accept authenticated requests. A short while later we had a slightly modified version of our release with the appropriate proxy server configuration enabled and this allowed us to successfully see the outside world.

Although the release didn't go as expected, it was a success because we now have a much better understanding of the constraints placed upon our software architecture by the infrastructure and we found the side-effects much earlier than we would have done by going with a single release. We'd successfully identified the risks with the highest probability of happening and planned for them. Managing technical risk is one of the key aspects of the software architecture role, with early evaluation allowing you to prove that your software will work as expected when released. For new systems or enhancements to existing ones, understanding the big picture can and does contribute to the overall success of projects.

Make your mark on the industry’s leading annual report. Fill out the State of API Integration 2019 Survey and receive $25 to the Cloud Elements store.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}