There are a number of potential benefits that encourage companies down the SOA path. Tangible benefits include flexibility and simplified management, the ability to mix and match solution components, reduced development time, and standard interfaces that enable great reuse and interoperability. A few vendors also offer a complete SOA platform, but that may result in vendor lock-in for customers; many see one of the perks of SOA as the ability to pick and choose different components from different vendors. Many companies today probably already have some type of SOA infrastructure in place, even if they didn't make the conscious decision to go there. SOA is something universally appealing, benefiting large and small companies alike.

Increased agility to meet changing customer and market demands and cost savings resulting from not having to buy and maintain new technology are also usually high on the list. The promise of higher revenue and lower costs are also backed by the slightly less tangible benefit that comes from pushing management and business functionality closer to the coal face, while avoiding custom development costs and yet more technology purchases. It could be argued that the real value of SOA is non-technical, both in the business sense and from the perspective of architecting an enterprise-wide solution to integrate, present, and modify the transaction data a business is built on.

So it's surprising that most organizations pursuing SOA ambitions focus first on data models - the metadata for their organization - and the different views of this metadata that the organization will need. For example, customer data is common to all organizations, but within the confines of the different components of the business processes, attributes that need to be viewed by each customer are likely to differ. The invoice-to-cash process is likely to want to see customer payment history, while the lead-to-order process is probably more interested in the product order history. There will be further differences between industries. So before even embarking on the goal of building an enterprise-wide integration of disparate business applications, most organizations get caught in the treacle of trying to build a data architecture that seamlessly enables consistent quality and timely information transfer between business functions.

Next, organizations begin to focus on SOA-enabling technology, and begin debating the definitions and merits of the myriad options. Middleware, pattern-orientated software architecture, remoting, late binding, messaging/communications, containers, J2EE versus .NET component, services standards, identifying services through registries, parallels with the distributed world, business rules and how they fit, and service levels and what it means to have a truly service-orientation technology framework.

During all of this, many companies miss one basic fact: before they can begin down the road to SOA success, they first need to understand their existing architecture to ensure they'll be able to leverage something that is reuseable and agile. There is a significant amount of groundwork that needs to be undertaken before enterprises depart on an SOA and enterprise integration initiative. The obvious starting point for IT professionals is to understand how (and whether) their current infrastructure supports business critical systems and processes - and where they can make safe and cost-effective changes and integrate systems to benefit from interoperable services. As a first step, building a complete and up-to-date inventory of existing SOA-related technologies and mapping where they sit across the organization makes great sense.

Companies who want the cost and efficiency benefits of moving to an SOA now have a great opportunity to incorporate vendor-agnostic discovery and mapping tools that identify all components in their IT infrastructure and deliver accurate and comprehensive information on the critical dependencies between hardware, software, and applications. The quality of this data and the method by which it is extracted from systems, aggregated, and managed is critical to the success of an SOA. These discovery and mapping tools will play a key role in enabling IT teams to continue to develop distributed and high-performing architectures such as SOAs - and help monitor the performance and dependencies of applications in the SOA framework. They can also track components such as virtual machines (VMs) as they move around in the architecture, highlight interdependencies between all the moving parts and quickly examine the individual components of the overall SOA environment - often repaying investments in days or weeks rather than years. By understanding the current state of the existing architecture and being able to identify the extent of drift from the original design, companies can create the foundation for implementing safe, fast, and effective change.

In practice this involves architecture, development, and infrastructure support teams all working together to understand the current environment. They need to acknowledge that they need a common language with which to visualize IT today with all of the component relationships and dependencies mapped out, and that there is more to SOA success than just data models and middleware communication.

Automated discovery and relationship mapping tools make it easier to identify candidate business services for SOA treatment, and, of course, those that might be inappropriate. For example, SOA isn't appropriate for non-distributed systems that don't have a need for component integration, applications whose performance would be slowed by service-delivered data, applications requiring tightly mapped asynchronous communications, applications operating in an already common communications environment, and short-term interim solutions.

While mapping tools that demonstrate relationships between software components and packages make it relatively easy to map out all the underlying components of a business application or service, they also make it easy to spot where components supporting the SOA paradigm already exist in the application space. This knowledge may be useful in determining potential SOA pilot initiatives, but it's just one step. That knowledge then needs to be supplemented with a thorough understanding of the governance required for further successful SOA adoption. The flexibility and other benefits of SOA also bring with them the need to manage more and more things - and more and more relationships between those components.

SOA is about the way IT enterprise architecture allows for the loose integration of disparate systems using a corporate-, customer-, and partner-wide data taxonomy. In practice, it requires an in-depth understanding of the existing architecture, governance of how SOA will be adopted across the enterprise, considered data model design, and a careful eye on the need for any solution to support agility and reuse the established software services. Technology is an important consideration in the SOA paradigm, and the technology framework will be driven by the suitability of existing systems for adoption as SOA candidate applications. Leveraging discovery and dependency mapping tools can enable companies to assess their current architecture, establish the degree to which an organization has already adopted an SOA approach, identify candidates for integration, and measure the deployment success across the enterprise. SOA must support business needs rather than existing for the sole benefit of application development teams; as such, beginning with a clear business service view that provides complete visibility of the underlying technology is the logical first step.