Enterprise Integration Zone is brought to you in partnership with:

Simon lives in Jersey (Channel Islands) and works as an independent consultant, specialising in software architecture, technical leadership and the balance with agility. Simon regularly speaks at international software development conferences and provides consulting/training to software teams at organisations across Europe, ranging from small startups through to global blue chip companies. He is the founder of "Coding the Architecture" (a website about pragmatic, hands-on software architecture) and the author of "Software Architecture for Developers" (an e-book that is being published incrementally through Leanpub). He still likes to write code too, primarily in .NET and Java. Simon is a DZone MVB and is not an employee of DZone and has posted 33 posts at DZone. You can read more from them at their website. View Full User Profile

Evaluating Enhancements

07.10.2013
| 1055 views |
  • submit to reddit

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.


Published at DZone with permission of Simon Brown, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)