[SOA World] is your App Infrastructure based on a the Postal Service’s Model?
Article written by Rob West
This is a thought-provoking article from LORI MACVITTIE on SOAWorld Magazine that poses an interesting point-of-view:
…the US postal service doesn’t determine whether postage may be due or not until the package arrives at its destination. If the addressee isn’t willing/able to pay that postage due, the package is of course returned via the delivery service, which incurs round-trip costs of transportation and handling at every point along the way.
If this sounds anything like your application infrastructure architecture, then you might want to reconsider how you’re handling the delivery of applications and where you’re applying policies that may affect the delivery process.
There are tons of inefficiencies in every IT organization (not yours, of course!) but what this article sparks in the mind is that sometimes, it’s necessary to examine the whole structure – end-to-end, and to work toward a design in your vision, especially in the most taxing of areas: application delivery.
Too often, apps live in a vacuum in terms of how they are supported and connected on the back-end, but live together in the minds of their users. We do stuff to data before considering workflow: as MacVitte points out —
Why apply compression to data on the application server when that data may need to be examined by other components in the architecture on the way back to the user and may, in fact, degrade performance rather than improve it? Why not apply compression at the last point possible; at the strategic control point that sits between your infrastructure and the “rest of the world”, i.e. the user and their network. Why are requests not examined at the first possible strategic point of control for validity? Why allow what is potentially a dangerous and malicious request pass through the infrastructure so it can be processed by every component in the architecture and potentially wreak havoc throughout the data center? Why not examine the request at the first possible point and accept or reject it before the costs associated with that processing and the risks are incurred by the organization?
Completely engaging read, and worth passing around at that next Steering Committee meeting.
