For a business to be sustainable today, it must be supported by a truly sustainable architecture. This type of architecture must have built-in agility and reusability. To be able to support the disparate end-to-end transaction components involved in converting leads to cash, this architecture must be sufficiently free form in its inter-business process communication. All businesses require this, whatever the business model. This openness in communication needs to permeate down through the layers of the organization so that reuse is standard - and considered a strength, rather than a lack of precision.
Imagine a business introducing a new product line. It not only builds an external marketing message, but also internal messaging to inform the underlying teams and business processes how to sell and deliver the new product, to whom, and 
for how much. No rebuilding of business departments or lines of business required. It's the same deal for those impacted by the credit crunch, where the only way to maintain revenue is to reduce operating cost.
This principle can also be used when organizations adopt service-oriented architectures (SOA). SOA is changing the way companies integrate existing business systems across the enterprise. The ability to integrate lead-to-order-, order-to-production-, production-to-delivery-, delivery-to-invoice-, and invoice-to-cash-oriented systems means organizations can hold onto their investment in staff knowledge, process, and procedures, and IT tools - specifically hardware and software. And they can do it while making the kinds of company-wide systems improvements needed to support diverse initiatives including e-commerce, B2B, and global economic trading.
Distributed computing has been around for many years. For some, SOA appears to be just hype on the same theme, but as a paradigm for developing an enterprise-wide architecture, it does have advantages. Today's distributed systems have a service-oriented focus, operate using loosely coupled components, are responsive to business transaction events, and support integrated as well as internally built solutions. Critically, they are designed around the data by which revenue-generating transactions are underpinned, and they make extensive use of existing infrastructure and software.
SOA offers independence across platforms and physical server dependency and represents a good opportunity for IT departments to streamline their infrastructures and squeeze more value from existing networks and systems. SOA enables dynamic use of available services via messaging and authentication, and is not prescriptive in the way system components interface with each other. When coupled with the use of software patterns - where knowledge is encapsulated within reusable service components - SOA can significantly improve reliability. From a service deployment perspective, this means a reduced need to buy new hardware and infrastructure software for each new line-of-business-driven project. Instead, organizations can benefit from standardizing, consolidating, and virtualizing server and software application environments, while focusing on additional cost reduction through skills consolidation and knowledge sharing when building communication interfaces between different technologies.
The nirvana resulting from pursing the SOA paradigm includes lower overhead costs in managing the underlying infrastructure, composite application construction and hence lower risk, and decision making based on the here-and-now - having data from across the enterprise available from a single application interface. To achieve this, organizations work toward integrating multiple systems and data sources to establish a single data taxonomy that delivers consistent views on that data - resulting in a shared service-oriented architecture up and down the supply-chain that the organization forms part of.
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.