At my firm, Infosys Technologies, I have come across several clients who are actively trying to explore, consider, adopt, embrace, or become completely immersed in SOA. Here is a typical call I've received, where our client rep says, "Ajit, we've got a very critical meeting with the CIO of company ABC. He is very excited about moving his entire organization toward SOA. Can you come and present our SOA capabilities to the client on Monday?"

Can I help here? Sure I can. As a principal architect in our technical consulting group, that is a part of what I do - what I'm paid for. However, to engage in a meaningful conversation and to really add value to that meeting, it's very important to answer the questions:

• How large is this initiative?
• What is the client's understanding of SOA?
• Do they know what type of a platform they are considering?
• What is the size of the application portfolio they are looking to "service-orient?"
• What LOBs (Lines of Business) are involved in this initiative?

For people who have been engaged in distributed development, enterprise architecture, component development, etc., SOA is not a new concept. In fact these participants in the enterprise will argue that SOA is the "Same Old Architecture." There is definitely a large degree of truth in that statement. SOA is not Web services. SOA is not necessarily Java, .NET, and does not necessitate the usage of the latest technologies. However, these are very feasible options for undertaking a new initiative to service-enable applications that were not service-enabled before.

The key concept behind SOA is the ability to bridge the business-IT gap and promote business agility. And the key to success around an SOA initiative is not just the architecture, but also the process - SOA governance, IT strategy, service definition, translation of business services to technical services, and so on. Accomplishing many of these requires substantial overhead, which can only be justified if there is a larger initiative that can realize the benefits of service orientation.

Does this mean smaller initiatives, LOBs, or organizations can't participate in SOA? That's not what I am saying. However, the most important factor to consider as you participate in such initiatives is to understand what the bigger picture is. Which SOA initiative are you a part of? What part of the business value chain do you participate in? If you don't know the answer, there is no point in service enablement, because you have not identified your service consumer.

On the other hand, if you have understood the bigger picture, then you are a participant in the governance process (because that part is handled in the larger service-oriented enterprise), your services are well understood (because you are working with the appropriate IT strategy team), and you will effectively plug into the right service-oriented architecture (because there is a team who is responsible for defining it). On the other hand, you may be a part of the governance, IT strategy, or architecture team in the larger business initiative. In these cases, "SOA in the small" can be implemented because the aspects of "SOA in the large" are already defined.