 |
 |
 |
|
10.07.08 What It Takes To Deliver A Service-Oriented Architecture  By
Mike Kavis
There is no shortage of advice on the web of the do's and don'ts for tackling SOA. One topic that I don't see discussed much is the assessment of a company's IT skills as it pertains to the ability of a company to comprehend and actually deliver on the promise of SOA. This is part one of a series that addresses the many skillsets required to deliver a Service-Oriented Architecture. I have mentioned in the past that companies that have not invested in enterprise architecture may struggle as they shift from software development to software engineering. Here are the wikipedia definitions of these two terms: Software development- is the translation of a user need or marketing goal into a software product
Software engineering- is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. There is a major difference between the two. Software development is the creation of software regardless of the means used to accomplish the task. Software engineering involves using a defined set of processes, procedures, and standards with the goal of improving the reliability and maintainability of the systems being built. So for companies that don't take a software engineering approach to software development, they may have huge challenges doing SOA with their existing staff. Throughout this series I will make reference to the shift from development to engineering as a key aspect of each skills assessment as I discuss SOA evangelists, architects, developers, testers, and many others. When kicking off an SOA initiative, companies should perform a readiness assessment to identify areas of concern and create action plans to address them. For this series of posts, I will focus on internal skills in the IT organization. First and foremost, a SOA Evangelist is critical to the success of any SOA initiative. This person must understand SOA inside and out from the perspective of both IT and the business. From the business standpoint the evangelist must understand the business drivers, the financial impacts and ROI, and can speak to the business in their language. From the technology standpoint, the envangelist must understand all aspects of the archtiecture in order to communicate effectively to developers, testers, security professionals, architects, network and infrastructure personnel, project managers, business and process analysts, and management. The evangelist should promote SOA and importance of governance and should help establish the Center of Excellence (CoE) needed to provide oversight and enforce the principles of software engineering. I have seen and read about several instances where SOA initiatives that were successful quickly turned to chaos upon the departure of the company's evangelist. In one case, the company quickly lost sight of the business drivers and began to debate on technical issues like whether the services should be done in .Net or Java. These are the unfortunate consequences that happen when SOA is left to those who don't have a full understanding of the technical and business benefits of SOA and focus on software development as opposed to software engineering. Characteristics of an SOA Evangelist Continue reading this article. About the Author: Mike Kavis is a veteran Chief Architect with over 23 years of IT experience including distributed computing, SOA, BPM, data warehouse, business intelligence, and enterprise architecture. Read Mike's blog at Enterprise Initiatives. |
|
| ||
|
CTOupdate is brought to you by: