Let me begin with the admission that my knowledge of Service Oriented Architecture (SOA) is largely theoretical. It stems from a composition of IT articles and war stories shared by other developers. All this to say that my opinions in this post may be naive, but I'll toss them out there anyway.
SOA, in many circles, is something of a holy grail in software development. After all, a group of applications that're fluent in XML to gracefully synchronize with a central message bus makes for an enticing proposal. Suddenly no single system is a lone island, but every application has to work together. Existing redundancy between systems can be eliminated, alleviating maintenance. If an application could be likened to a single-cell organism, then SOA enterprise architecture would represent a complex multi-celled creature.
But how do businesses get from point A to point B? It's unrealistic to pretend that the transition will happen all by itself. It's my opinion that if an enterprise decides to pursue an SOA architecture it will have to drive it home with a top-down mandate from leaders within the company. Anything less will equate to a lukewarm infinite loop of high expectations, varying degrees of commitment from developers and resulting projects that fail to consistently communicate with the message bus.
The first application to transition to a service may be the biggest challenge. It may consist of several identifiable resources each needing to be dissected into a smaller subset of unique services. This process will take time, burn money and require a business to be fully on board with the new architecture.
No comments:
Post a Comment