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

Designing Enhancements

07.04.2013
| 5035 views |
  • submit to reddit

Software architecture is needed for enhancements too

We're enhancing one of the software systems that I'm involved with, where we're adding new functionality into some of the existing use cases. If you imagine that these use cases are implemented by the users working through a number of pages in a web application, we're basically modifying the final step across a number of them.

So then, the system is being modified from the user's perspective because they are going to see some changes in the way that they use the system. While this itself isn't architecturally significant, we are interfacing with a brand new system behind the scenes. Typically, system enhancement projects require a very light architecture touch but this one needs slightly more because of the nature of it.

Interfaces are usually one of the more risky elements of software projects, particularly when you're consuming an interface that you don't have control of, as is the case here. Furthermore we're doing something that hasn't been done in the existing architecture, which is interfacing with a third party over the Internet. From a coding perspective it's easy because we're just opening up a HTTPS connection and throwing some XML data down it. Where it starts to get tricky though is with our deployment infrastructure because our servers need to punch through the firewalls to reach the outside world.

Although an enhancement to an existing system, this is one of those projects that benefits from some architectural input. Rather than dive straight into the code, it's important that somebody steps back to look at the bigger picture elements such as:

  • Design and how best to integrate the new functionality.
  • The definition of the interface and whether it's synchronous or asynchronous, the protocol, the message format, etc.
  • Confidentiality of sensitive user information and ensuring service credentials remain secure after deployment.
  • How the changes affect the existing infrastructure from a security perspective.
  • How the new functionality will meet existing audit requirements.

This is no different from what you'd do at the start of a software project, but it highlights that architecture is often necessary at other stages during a system's lifetime. Next time I'll discuss how we phased the delivery of this enhancement to evaluate our architectural decisions early.

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.)