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:
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:
This is achieved by investing in sustainable system interoperability which allows you to:
The main benefit of this sharing and reuse is a reduction in your Total Cost of Ownership (TCO).
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:
Then the SOA may well be appropriate for your organization.If on the other hand your problems are things like:
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.
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.
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:
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.
An organization will have to invest in both informal and formal communication channels to promote information sharing.
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.
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.
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.
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:
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.
Services offer an alternative interface to GUI applications for accessing business functionality. Consequently, the following costs will be incurred:
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.
All technologies have limitations and services are no-different. The principal limitations of distributed services are:
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 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 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.
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.
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.
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.
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.
David Conway is an independent Enterprise Architect who provides SOA Consultancy Services to Financial Services and Government organizations. For the last ten years he has held technical leadership roles with Bearing Point, Canada Life and Mapflow. During which, he has gained extensive SOA implementation experience on a range of J2EE and Microsoft platforms.
There are no products in your shopping cart.
| 0 Items |
|
|
Membership at DBizInstitute.org includes access to our other communities
