In the continuing Baby Steps to SOA series, we follow Doug and the IT team behind BuyMyWidget.com as they take steps to renovate their digital asset architecture. In this final stage, the team moves to using an Enterprise Service Bus (ESB) to handle the inter-application communication. This step allows for an increased ability to manage the disparate systems and scale to an enterprise level while also removing tight coupling between the applications.
In the continuing Baby Steps to SOA series, we follow Doug and the IT team behind BuyMyWidget.com as they take steps to renovate their digital asset architecture. Up next is expanding the use of the new services layers to their other applications within the business. While focus is usually given to revenue-generating applications, the inclusion of other applications into this architecture permits all of the applications to interoperate, sharing data and functionality. This step allows for full leveraging of all business capabilities within the organization.
Around five years ago, I remember a lot of folks started getting into the hype around Service-Oriented Architecture. “This is the way of the future!” you would hear, or “All of our problems will be solved by moving to SaaS or SOA!” Take a moment now and consider your own workplace. How much of your business processes are actually sitting in a nice reusable service? Any? Alternatively, how many times have you had to make a bug fix in the middle of a bunch of hard-coded integration logic running SQL directly to a legacy system?
There’s probably one eager developer at your workplace (maybe even you?) that jumped on the bandwagon, built an ASMX or WCF service to serve up tombstone data from a legacy backend, and then gave up when nobody else adopted it. Adoption has been a huge problem in many organizations, especially small-to-medium businesses that simply don’t have the budgets to rebuild their entire infrastructure from the current spaghetti mess of interdependencies to a full SOA managed by an Enterprise Service Bus.
Application performance is heavily dependent on the performance of the communications between the primary application and all other integrated systems. Even the tiniest of changes in a connected system can suddenly cause a huge performance hit. For example, a small web service retrieving data about a user when they log in gets altered to return an extra field from a joined table, and suddenly the performance for users logging in bombs and you start getting timeouts.
When an application is built under one set of assumptions, the changes that will inevitably occur in any integrated system need to be monitored on an ongoing basis. This is where automation of performance regression tests comes in. Whether running an agile project or not, ensuring integrated systems are performing over time requires a solid regression plan. How can this be accomplished this cheaply?
In many of the projects that I have worked on, the application we’re building needs to integrate with a back-end system or a web service layer that is maintained by a third party or by another team. In these cases, we shouldn’t assume we’ll have the ability to ensure that the other group has set up an automated test bed to verify regression. Especially if that other system is having changes made to it to support the project!
This is where integration testing comes into play. There are a few things that you should be doing with your unit tests to ensure your integrations continue working throughout the lifetime of your project, and also that your automated tests are running efficiently so that your team is not slowed down waiting on expensive integration unit tests that are running for long periods of time.