Every vendor provides some guidelines to asses your organizations SOA readiness. Once you have assessed your current architecture and deployment, these are some basic guidelines to move towards SOA.

• Use blueprint instead of starting from scratch. Do not reinvent the wheel. Build on other's experiences.
• Make sure the SOA project you choose for your starting point is well defined and well confined. Prove SOA successful with something that is small, is achievable in a short time, and will have a significant impact — then build incrementally.
• Stick to standards and standard interfaces. The proprietary software you build will be your own downfall. The sooner you part ways from evil temptations, the happier and healthier your software can be.
• Don’t Neglect Governance: SOA governance won’t happen by itself. Address it early. SOA governance is as much about the way you work and the processes you put in place to create a SOA environment as it is about any technology issues. So, don’t just go and buy a bucket full of tools labeled SOA governance. SOA governance is about leadership and thinking through how you are going to get from where you are today to a well-coordinated approach that conforms to your corporate goals and objectives.
• Pay close attention to the security implications of exposing business services.
• SOA makes a lot of sense for a lot of things, but not for everything. If you have an application that is so specialized that it is isolated from other aspects of the business and works just fine, leave it alone. At the same time, when you find the software that is appropriate for SOA, you need to prioritize, scrutinize, and make sure you’re looking at the right level of granularity. For example, if you make each service very small, you might end up with thousands of little pieces of code that are hard to find and hard to reuse. The bigger the reusable service, the easier it will be to find and reuse. And some things need never, ever be exposed as services.
• Don’t Postpone SOA: SOA is a long journey. The sooner you begin, the sooner you’ll get somewhere.
• SOA is an architectural style that has been around for years. Web services are the preferred way to realize SOA.
• SOA is more than just deploying software. Organizations need to analyze their design techniques and development methodology and partner/customer/supplier relationship.
• Moving to SOA should be done incrementally and this requires a shift in how we compose service-based applications while maximizing existing IT investments.
  
  
  

SOA Maturity Levels
A complete overnight realization of SOA is not a viable solution. Implementing SOA is a five step process.



Level1: Initial Service - In the first stage companies service-enable their applications using standard APIs. The costs are modest.

Level2: Architected Service- In second stage companies use SOA services to build new or refractor existing integration points. The company should establish visibility into the entire service list and their consumers. It becomes feasible to reuse services because more thought is put into policies that services must adhere to, such as security and uptime requirements.

Level3: Business and Collaborative Service - Third stage involves the introduction of business-oriented services, such as business process management (BPM). With a focus on the partnership between technology and business organizations, Level 3 optimizes the flexibility of business processes, allowing IT to respond quickly to changing business requirements.

Level4: Measured business services - Level 4 provides continuous feedback on the performance and business impact of the processes implemented at Level 3. The key focus at this level is collecting data and providing that data to business users, enabling them to transform the way they respond to events. It could involve logging and monitoring service health constantly.

Level5: Optimized business services - At this final level, business-optimization rules are added, and the SOA becomes the nervous system for the enterprise. Automatic responses to the measurements and displays of Level 4 allow an organization to take immediate action on events. A Level 5 project can take the request messages entering the ESB and route that information to an event-stream processor. This service correlates the behavior of all traders across multiple execution venues and identifies important patterns. This information might be used to execute new trades or stop a rogue trader who is out of view of compliance officers.