What is SOA?
To be ready for something you first need to understand what it is. SOA is often defined in technical terms about the composition of services. Whist technically correct this encourages people to become caught up in technologies and constraints very early on.
I prefer to think of SOA as a solution approach that helps IT solve business problems by sharing and re-using:
- Information and data e.g. user directories
- Functionality e.g. quote generation
- Know how e.g. this data lives here and is looked after by X
This is achieved by investing in sustainable system interoperability which allows you to:
- Consolidate your maintenance costs around a smaller number of shared services
- Reuse existing services and avoiding unnecessary development
The main benefit of this sharing and reuse is a reduction in your Total Cost of Ownership (TCO).
What’s the problem?
Since SOA is a form of solution it can only be effective if it solves the problem at hand. So the second step “in being ready” is to clearly understand the problem that you are trying to solve.
If your problems are things like:
- We have really useful data trapped in legacy systems that we would like to release to new user groups to increase customer satisfaction
- Our admin processes are manual, inefficient and costly as we continually re-key the same information in multiple systems
- We find it really difficult to get our existing systems to communicate with new supplier systems
- Our business systems cannot scale to meet our continuously growing user community
Then the SOA may well be appropriate for your organization.If on the other hand your problems are things like:
- We need to get a Web presence ASAP to support our sales staff
- We need to be able to change content on our website on a daily basis
Then the case is less clear. The solution to these problems may work well within an SOA context. But these requirements in themselves do not justify a SOA approach.
A rough rule of thumb is if your business problems are strategic rather than tactical in nature then SOA could well play a significant role in IS delivery. If your business problems are short-term in nature then SOA is unlikely to represent a value for money strategy in that time span.
How will SOA impact me?
Most of the basic tenets of good requirements gathering, system design and implementation are just as true for SOA as they are for OO, web or procedural development. However, a SOA approach is unique because of its emphasis on cross organizational sharing. Consequently, it does challenge an organization to change how it thinks, communicates, delivers, supports and manages. Understanding the impacts of these changes is an essential step in being ready.
Organizational Change
SOA requires people to share information across the business. This requires people to change fairly significantly in how they think and operate. People tend to think that if they share they will:
- Gain dependencies and become less effective
- Lose control
- Become redundant
Change is likely to be opposed both explicitly and covertly as people look to protect their interests. People will only embrace this change when they feel there is a clear benefit for them. A significant amount of education will be required to achieve this.
Communication Channels
An organization will have to invest in both informal and formal communication channels to promote information sharing.
Governance
SOA will initially require a Governance function as you will not achieve business wide coordination without some degree of control. The challenge here is the same with any management function. Keep it at the right-level and mentor your stakeholders so they become self-governing as much as possible.
Budget
Sharing information and processing across an enterprise means a single initiative may involve multiple departments. A budgetary approach that allocates budgets on a departmental basis may struggle to encourage the level of collaboration necessary to deliver an optimised solution.
Business Process Re-engineering
SOA enables business process re-engineering. Your analysts must be skilled in gathering business requirements so they can analyse a process and remove redundancy. This is very different to taking a list of features and implementing them on a SOA friendly technology stack.
For example, a legacy process may have a sales team selling using system A and an admin team processing using application B. The newly optimized process may have the sales team also completing a large amount of the admin tasks at the point of sale via a single interface so rendering application B redundant.
SOA and Messaging
Messaging is at the core of SOA. It should become the new single enterprise wide language for your systems. At a minimum this requires your team to be proficient with:
- Messaging standards, technical and industry
- Messaging patterns
- Message versioning
- XML and XML definition language
It is unlikely that your team will have all these weapons in their armoury on day one. This must be addressed through formal (e.g. training courses, enterprise message repository) and informal (weekly meetings, best-practice workshops) means. Otherwise, your SOA initiative will flounder as it grows.
Building Services incurs costs
Services offer an alternative interface to GUI applications for accessing business functionality. Consequently, the following costs will be incurred:
- Implementing and supporting a Service Registry to publish and manage your services
- Implementing and supporting a security layer to secure access to your services
- Implementing remote invocation, error handling and transaction handling mechanisms
- Implementing message validation and translation layers at each client and service
- Providing the necessary bandwidth to minimize latency issues in accessing your services
Some of these are up-front costs which can be borne over the life-time of a program. Others will occur repeatedly. The right choice of tools can help to minimize some of these. But, implementing a function as service will always prove more costly than implementing a function as a local library.
Services have technical limitations
All technologies have limitations and services are no-different. The principal limitations of distributed services are:
- Transaction control
- Exception handling
- Latency
If your designers and developers do not understand these they will end up implementing services that do not function or ‘fail’ gracefully. Moreover, given the natural latency of services and their 1distributed nature certain exception types are more likely to occur than with homogenous tightly coupled systems.
XML development requires specific expertise
XML is complex and has just as many pitfalls as any other form of development. Many XML based applications end up being significantly re-written because of crippling performance or quality issues. A vast array of XML development tools exist, each suitable for a different problem. It is essential that the development team is appropriately skilled in these technologies.
SOA Platforms & Tools
SOA isn’t short of feature rich platforms and tools. Typically these are expensive and functionally rich. Unfortunately, the teams that use them are often not adequately trained in their usage. As a result hacks are introduced and wheels re-invented at great cost to the overall implementation and subsequent maintenance.
Services require testing
Testing a programmatic or message interface is often alien to traditional QA teams. It is unsatisfactory to rely on user-interface testing alone to validate a service as fit for purpose. Also, services require very specific types of concurrency and disaster recovery testing. The QA team must be up-skilled to provide this function; otherwise system maintenance will prove expensive.
Client applications require repeated Testing
If an interface affecting change is made to a service then all client applications with a dependency on that interface must also be regression tested. Automated testing needs to be adopted early and systematically. Otherwise, the test effort will start to inhibit the ability of your organization to react to change.
SOA Deployment
SOA encourages separation of concerns and partitioning. Consequently, you will initially invest in more hardware and software than a traditional architecture. The upside of this investment in computing resource is a real ability to scale to meet increased business demands. If the ‘ability to scale and grow’ is not a real requirement then this investment may not be appropriate.
Services need Maintenance
New services will tend be deployed on a new technology platform. This will require support staff to be trained in its maintenance and support. If old systems are not-deprecated in tandem with the release of new systems the overall TCO will increase.
Vendor Lock-in
SOA (and ESB’s) ability to offer loose coupling between systems is often promoted as a way to avoid vendor lock-in. In reality, the various applications and services that comprise a SOA will still need to be vitalized on a regular basis. Also, every ESB on the market today has a finite support life time so they in themselves just provide another lock in point.
Vendor lock-in is unavoidable in any enterprise IS. The best strategy is to pick the vendor that best suits your profile, adopt popular industry standards where possible and try to be smart about how and when you upgrade.
So are you ready for SOA?
Being ready for SOA means you have defined your problem and understand the costs, benefits and limitations of this approach.
SOA does have upfront costs and does encourage an ‘economies of scale’ mindset. But the good news is that you can and should embrace SOA incrementally.
In all likelihood you will have already delivered some services in your business and can probably look at re-using these more. If not, integrating with a specialist service provider is a reasonably low-risk way of introducing services into your enterprise.
1 Often a service may be provided by an external supplier or different department to the client application. As a result they will have different support windows and/or may not be as reactive as desired in the event of a system malfunction.
