 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > A view on building essential SOA skills |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
SOA is about flexibility and reuse. It grew out of the realization in the early days of Web services that software architects could build loosely-coupled standards-based interfaces yet still end up with hardwired, hard-to-maintain application integrations. Although compliance, governance and registries have been important drivers, the history of SOA to date has largely been a history of architects trying to get loose coupling right.
We recently spoke about SOA skills with Jim Green, CEO of Composite Software. At Composite, and at previous positions at WebMethods, Active Software and Sun Microsystems, Green has been among thought leaders in middleware and SOA. As he noted, the general trend over these years has been toward working on integration at an ever higher level of abstraction. One can guess that architects that can make those kinds of leaps are more likely to succeed. Along with others, Green recently created a book entitled "An Implementors' Guide to SOA: Getting it Right." The book looks at practical issues facing technologists charged to meet enterprise architecture issues. It provides a way of thinking about the essential skills of SOA. Being able to discern some fine and not so fine points in technology is a topic of the book. You must learn how to apply tools and technologies – to sort the transactional requirements from the data integration needs; the place for the ESB and the place where the ESB is overkill; the use of the repository, or registry, or the place where their use would be excess - that is an undercurrent throughout. Many architects, Jim Green suggested, buy products for the wrong reason - without understanding what the products do and what they don't do. A sense of the business goals, over technology goals, is important, Green indicated. "People sometimes argue about ESBs when they haven't figured out the requirements yet," he chided. "People may say 'we are doing SOA so we'll buy an ESB.' But, in fact, you use an ESB when you reach a certain complexity threshold." In the same way people decide to do a SOA, said Green, so "the first thing they do is buy a UDDI registry." But, he continued, more properly, that could be a second or third step. A take away: In SOA project management, as in other forms of management, the skilled practitioner knows that no one person has complete command of all the needed skills. "For example," said Green, "with transactional servers working with many clients, you are going to have to be a multithreaded programmer. Naturally, if you use an application server, the framework itself takes care of that, so your skill requirements are reduced. "With [data-integration-centric apps] you are going to have to be very good with query optimization. "There are a variety of skills required, and no one person is going to have all of them." Green emphasized that SOA practitioners may employ new technologies, but fundamentals do not change. "Whether it is SOA or not, it is important that people make sure their implementations meet the needs of the business," he said. Thus, he continued, the successful services architect is one who is not just a skilled technologist, but is also someone that can apply technology to meet business needs. Read an excerpt from "An Implementors' Guide to SOA: Getting it Right" entitled 'Designing Services.' Download the book in pdf. Find the book at Amazon.com.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
