eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
There are fairly common mistakes to avoid when implementing an SOA project, and best practices are starting to emerge based on successful, enterprise-wide deployments. To follow are the 10 most common mistakes companies make when implementing an SOA project. Recognize and avoid these potential pitfalls to successfully get your SOA initiative off the ground.
1. Taking a Shotgun Approach
When attempting to move to an SOA, companies often take a shotgun approach and don’t take into consideration which services are actually being used, often times Web-enabling more than is necessary. Service enabling everything is costly and may not be necessary.
2. Failing to Involve Business Analysts
Business analysts are critical to the success of an SOA project. Instead of involving them from the start, companies tend to focus heavily on implementation, such as generating Web services, rather than focusing on what needs to be enabled to meet business needs. To best counteract implementation-focus tendencies, business analysts should be involved from the very beginning of a project.
3. Spending More Time on SOA Products Than SOA Planning
Companies tend to focus more attention on SOA products—such as tooling, integration engines and SOA software offerings—than on discovery, planning and project preparation for SOA initiatives. Consideration of products should be undertaken only after a careful plan is in place.
4. Tackling the Largest Projects First
The most practical approach to an SOA is to start with the smaller, lower risk projects that are less visible. While most companies tend to begin by tackling the larger projects first, this is high risk and often leads to failure. Beginning an SOA with smaller projects provides for a better learning experience and a base of confidence from which to build.
5. Forgetting that SOA is a Business Problem
SOA is a business problem disguised as a technology problem. When the technical focus supersedes the focus of the business, the entire SOA project can veer off course. It is important to understand the goals of SOA, and that the business problem should be the primary, not secondary focus.
6. Treating Identity as an Afterthought
Companies have a tendency to commence a project, and then wait until the project is mid-stream before considering identity implications. An infrastructure should be put in place to handle log-ins by proper credentials. Identity needs to be given high priority during the SOA planning process, instead of being treated as an afterthought.
7. Buying New Products When Existing Investments Suffice
Companies seeking to realize the benefits of SOA often believe they must buy new hardware, software and SOA-specific products to do the job; however, that is usually not the case. Many SOA initiatives can begin with a company’s existing hardware and software with minimal additional investment.
8. Misunderstanding Company Key Players
Often times the person leading the SOA project does not know who the necessary players are or who ‘owns’ the data within the company. Beginning a project without a full understanding of which departments affect which services, and vice versa, can doom an SOA project from the start by creating roadblocks to project acceptance.
9. Expecting the SOA Project to Spread Quickly
Many companies expect the quick spread of SOA projects from one business unit to another and become frustrated when it does not happen. However, moving forward incrementally and carefully ensures the most reuse across all organizations, which leads to a more efficient SOA infrastructure.
10. Lacking Necessary Elements
Many smaller companies do not have the necessary in-house resources or expertise to implement an SOA project. This lack of necessary elements can yield missteps and mistakes. However, small businesses can achieve significant benefits by moving beyond inflexible and costly integration methods to implement loosely coupled Web services for SOA.
About Paul Callahan
Paul Callahan is the Director of Technical services for NetManage, Inc.
Paul has 15 years of experience working with IBM Mainframes, AS/400, Sun, Microsoft OS and Dec Vax. He specializes in host integration and TCPIP Networking. Prior to working for NetManage, Paul was the technical account manager for FTP Software and taught Networking, PC Hardware, UNIX, Novel and Microsoft certification courses at Boston University.