#1: SOA is not a purely technical approach
It's important to understand that service-oriented architecture (SOA), when practised successfully, is not just a technology architecture. The SOA paradigm is really about modelling the business processes, which are not always supported directly by technology components. Ultimately, services may be implemented by technology components, but the business processes themselves are more important than the services that support them.
SOA as a technology is an enabler. The technology doesn't provide direct value. It's not necessarily less expensive to develop services on a line-of-code basis as compared to EJBs or .NET components. Instead, SOA technology should be seen as an enabler of other benefits, such as improved and broader reuse, better responsiveness to changing business processes, and better alignment with business processes.
#2: SOA doesn't have to mean Web services
A lot of technologists have trouble understanding that SOA doesn't necessarily mean Web services. Web services can definitely be part of an SOA strategy but are not required. Service definitions can be based on other standard protocols besides HTTP. It's more important to focus on the needs of the business processes and the services than on the technology that's used to implement them. Usually, the context of the service will help determine how it's implemented.
For example, for services that involve critical business transactions, using a Web service may be detrimental since guaranteeing transactionality across a SOAP/HTTP protocol is difficult. Also, many services may need to operate asynchronously. In these cases, messaging systems based on queues and channels may be a better candidate to implement the service transport. Payloads and interfaces can, of course, still be defined using XML.
#3: SOA can be built using existing infrastructure
Many organisations are surprised to find that they can build SOA using existing infrastructure. For example, both the .NET and J2EE platforms provide support for developing Web services, for parsing and generating XML, and for communicating with messaging systems such as MSMQ and JMS.
What's usually missing in the SOA stack is the process management or automation layer. However, many companies have existing investments in enterprise application integration (EAI) tools. Many of the EAI tools can function as the process automation and management layer, which can access services from existing applications or those built on .NET and J2EE platforms.
#4: SOA is an evolutionary approach (from components, objects, and so on)
Service oriented architecture is not a brand-new solution that came out of left field. Rather, SOA is a natural evolution of both architecture and technology. Systems architecture has been on a constant progression to become more aligned with the business. Architects and businesses have long understood the value of aligning technology and business processes, including better use and justification of technology resources and better support of the business.
SOA technology is partly evolved from enterprise architecture theory that has been in place for some time. Enterprise architecture basically evaluates technology but, more importantly, it looks across the enterprise and across the business and processes and provides a context in which technology decisions can be made. The SOA tools have evolved from a mixture that includes Internet technologies, such as HTTP and XML, and integration technologies, such as message busses, translation technologies and connectivity.
#5: Process automation is a key virtue of SOA
A lot of organisations and technologists mistakenly focus on the service enablement and delivery within the services architecture. Unfortunately, that misses the point. The real value of SOA is as a business automation tool. Ultimately, software and systems are about creating business or organisational efficiencies, which can be defined in terms of the processes or activities the organisation performs. The focus for SOA should not be on the services, but rather on the processes and how to improve them.
The services are, of course, necessary to help support the processes. But they're secondary to the goal of creating efficiencies and improvements. Services for services' sake have limited value.
#6: SOA architectures can be highly complex
From a certain perspective, SOA architecture can be fairly simplistic. For example, developing a business process flow and identifying the required services is somewhat logical and straightforward. However, leveraging the data and services in a way that is meaningful can be much more complex.
For example, let's take a scenario in which an order service allows the user to create an order in the system. This is fairly simple. But what if you want to correlate order data with data from other services? If all the services share a common data source, you can bypass the services layer, perhaps, and generate reports. However, if some data is in homegrown services, some data is in a legacy mainframe system, and still other data is in commercial applications (such as SAP), bringing all the data together can be significantly more complex.
#7: SOA requires a keen understanding of business data
Because SOA is focused on business processes, it's important to understand the data that's relevant to those processes. For instance, an ordering process has several key data artefacts, such as the order, the customer, the shipping information, the invoice, the payment and the receipt. What's even more important is being able to describe these artefacts in a standard way so each service that participates in the process can understand the data equally.
For organisations with an existing information architecture, this may not be a big issue. However, for large organisations with limited or nonexistent information architecture, this issue can be a show-stopper when it comes to implementation. Because large organisations have such a variety of data, it is usually recommended to take an evolutionary approach to defining the information architecture, as opposed to a big-bang approach. This means that instead of spending four years…
