The world would be a better place if everyone would just do the right thing. Unfortunately, doing the right thing is often easier said than done. Especially in business ideas that seem to have the most promise can actually yield the worst results.

For example, applying SOA "best practices" to a business can be tricky because these practices don't always relate to real-world situations or business models. Ideas that look good on paper are often not so good in practice. In fact, they may turn out to be "worst practices." Learning from mistakes is a valuable exercise; however, the learning process is even better when someone else makes the mistake.

In the following article, you will learn some of the most common mistakes that IT teams make as they begin a SOA deployment process. With any luck, this insight will teach you what not to do as you begin to implement your own SOA. This way, you can be assured that your organization is on the path to success.

Rip and Replace
Migrating an entire system to SOA in the short term is a recipe for disaster. Theoretically, it may seem like a good idea to jump right into a SOA implementation, ripping out and replacing all existing systems at once. SOA technology is new, exciting, and hugely beneficial, and it's easy to get carried away.

However, SOA can be overwhelming when you try to wrap your mind around it all in one sitting; especially when you begin implementating a massive project that involves thousands of components. The best way to sidestep this issue is to be selective. Start with applications that are not working - migrating or rebuilding these applications will deliver immediate benefits.

Doing too much too soon will overwhelm your IT team and lower their level of confidence in the project. SOA gives you the opportunity to use a best-of-breed approach, as well as to leverage open standards. A SOA implementation plan should cover migrating your entire system to a SOA, but remember this process can take years. Focusing on applications that aren't working properly provides an opportunity for immediate payoff while functioning applications continue to deliver value.

The strategy of every organization should be to only undertake tasks that add value to the organization as a whole. With this in mind, make sure that your SOA strategy focuses on leveraging the business processes that deliver the most benefits to the company.

Randomly Wrapping Services
Enterprises without a business strategy to dictate what services to wrap and how they should be governed end up with security and performance problems - both inside and outside the organization. Businesses have undertaken practices known as wrapping services to permit the flow of data from one source to another by allowing a client to send complete SQL statements in a request to the accessed data, such as a database. This protocol has left the relational database susceptible to SQL injection attacks, where attackers bypass the SQL statements defined by the Web server and input their own.

The IT team at one particular company faced this problem when its Web server endeavored to use an anti-injection attack feature already present in its current security bundle. The feature was meant to detect and sanitize SQL statements that were scripted to perform only destructive operations such as "Drop" or "Delete." While utilizing the wrapping concept in a Web-based service approach isn't a bad idea or dangerous in itself, the implementation must be more specifically defined than in the previous example where users can make "dumb" SQL requests. Wrapping services demands a tightly coupled approach and a requestor that knows the implementation details to make the SQL call.

Overall, this approach lacks a business context and makes the database vulnerable to problems such as bad data input to SQL statements and invalid or bad SQL statements. An IT team investing time in manufacturing a Web-based wrapped SOA needs to disallow the input of "dumb" requests by setting up rules that define who has a right to request to the SQL database and in what situation that's appropriate. This requires that the user be authenticated before being granted access. That prevents the database from giving out information blindly and thwarts destructive requests without having to resort to security software measures.

When communicating directly to the database, applications and processes have too much authority. By offloading policy management and governance, rules and policies are easier to manage. The SQL injection problems can be solved by applying SOA and Web Service standards. This approach helps to achieve reuse and integration goals quickly but must be part of an overall SOA strategy or there could be problems on the application level.

Tweaking Standards
Organizations that modify standards - for instance, an open language like SOAP - lose a lot of value. By splitting SOAP messages into more than one part, such as using an envelope and a body, applications that employ the standardized SOAP stack become incompatible with those in the unorthodox configuration and this creates a proprietary form of messaging.

By adding these proprietary "extensions," the system limits interoperability dramatically limiting the scope of the SOA effort and drastically increasing the cost of operation. Because of the proprietary nature of the SOAP stack, specific code must reside on both sides of the communication and all applications and software in use through the SOA must be customized. This also prevents the use of developer tools, which are designed to work with standard SOAP stacks, creating problems with versioning software that must then be updated later for an ISV's revised platform.

To combat this predicament, IT teams must design a SOA that avoids too many components, thereby adding to the load. Using a universal language and making sure that components are loosely coupled is the best way to accomplish this objective. In this way, appropriate information is able to reach its endpoint in significantly fewer steps.

Poorly Designed Firewalls
Organizations that do not take the time to understand all the interdependencies, as well as the potential business impact, of their firewall will encounter communication problems that frustrate customers and partners. The interoperability that SOA presents can be easily stalled by the misapplication of firewall technology. It's easy when implementing an SOA to confuse the performance and UI requirements of a firewall with those of the SOA. This can lead to a restriction on the data that the SOA seeks to make available to consumers and partners.
When building an SOA be sure to consider the specific reasons - based on business and IT objectives - for its implementation. It's also important to find a way to clearly communicate this strategy to partners and customers. Finally, be aware that interoperability is a requirement for SOA, but it doesn't happen automatically. It's important to take into consideration all the interdependencies between partners and customers, as well as any other business impact, since these factors all have a bearing on your SOA.

Reconfiguring Existing Applications
On the surface, cloning and reconfiguring existing applications may sound like a great way to reduce development costs and save on maintenance. In reality, doing so can result in numerous issues including replicating bugs, creating redundant infrastructure, and testing nightmares.

Some common misconceptions about cloning apps are that by doing so the organization will have more developers who are familiar with a larger percentage of the applications and will lead to the creation of simple architecture and make it easy to plan and compute future costs. What ends up happening is quite the opposite. For instance, if there's a bug in the core code, it will end up being replicated. If the code is altered when you clone an application and then customize it, often there's no history of the alterations in the code. Therefore, before a team can fix problems, it needs to spend time determining what caused the problem in the first place. Finally, by embedding rules or policies as code into the application rather than abstracting them, you can add to the level of redundancy and make changes even more difficult to make.

There are ways to reduce your maintenance and development costs that don't involve reconfiguring existing applications. For example, you can distill a small set of core applications from hundreds of duplication applications. You can then use those reusable services across applications and business processes, achieving greater operating efficiency and lower maintenance costs.

The beauty of an SOA is that it enables you to construct new business solutions faster than by cloning applications. That means you can spend more time customizing solutions for each of your customers, while leveraging your core set of services.

Sharing WSDLs
When implementing an SOA, you need to set clear guidelines about how services can and should be reused. By not doing so, you can open your organization up to serious security, privacy, and compliance issues. In addition, you can end up missing a crucial opportunity to show the measurable value of your SOA. Sharing Web Services description languages (WSDLs) may leave your IT department wondering whether the right departments are being supported, whether the data is protected or encrypted, and what the possible ramifications of a system failure are.

There's a happy medium that would allow services to be reused and guarantee that proper safeguards are in place. When implementing a detailed process regarding the reuse of service you should:

• Identify who in your organization will be using the service.
• Implement proper security measures that ensure that your IT policy is enforced and your business rules are applied.
• Put a mechanism in place that can help alert you to when a service is being used by unauthorized users. That mechanism should also be able to help determine whether there's inappropriate use of services.
• Set up management and runtime governance technology.
• Validate that the service is running as designed and meeting the business objectives for which it was designed.

Invoking External Schema Validation
While this may sound like added protection, invoking external schema validation may actually leave the Web-based server more vulnerable to attacks. It's generally easy for a hacker to gauge the external validation by monitoring the transaction response and then set up a spoofed IP and change the location of the schema check. The hacker can then initiate transactions with a dummy schema and have it verified with a fake schema validation set up at the spoofed IP address and cause legitimate transactions to fail. While the information present in the server was protected by the schema, business can still be gravely impacted by the wrong hands.

With two simple steps, the schema developed for the SOA can be safeguarded. First, provide the schema to partners directly since anyone attempting a hack would not have access to direct contact with your partners. Then put a schema validation on an internal table that's secured by traditional perimeter defenses and end-point security. This will prevent anyone from being able to track the responses through the transactions and keep the data flowing between only you and your business partners.

Judging Success by the Number of Services
Many organizations mistakenly associate the number of services they have with the success of their SOA. In fact, it's actually the opposite. Since one of the primary business benefits of SOA is reuse of services, a high number of services can be a prime indicator that your SOA isn't successful. The more services your organization has, the greater the likelihood that most of those services aren't being used.

When one organization researched the value of its SOA initiative, it learned that it had 25 services in production. However, out of those 25 services, only five were being used by other applications and other business lines. Most of the services were only being used as individual applications. I once heard someone give a keynote at a conference and tout the fact that his organization had 300 services and anticipated having 1,000 by the end of the year. That's not a measure of success; it's a train wreck in the making.

Not only is reuse a key benefit of SOA, it's also a useful tool for organizations looking to quantify the business value of their SOAs. By looking at reuse, you can determine how many times a service is being used, how many processes it's supporting, and the number of items being reused. You can use that data to calculate the costs savings for each instance of reuse, such as the saved architecture and design time and the saved development time.

Conclusion
It's easy to be overwhelmed when embarking on an SOA initiative. While there are pitfalls to be aware of, it's important to focus on the positive business and IT benefits a SOA can have for your organization. Being aware of the "worst practices" to avoid can help you create an environment where doing the right thing is easy. These worst practices can help you create a blueprint for the processes necessary to make your SOA initiative a success.