The move to Service Oriented Architecture (SOA) is more than 10 years old now. The technology makes sense. It is rooted in the plug-and-play sort of mind set that is essential to businesses that want options with their platform solutions. No longer is integration direct. The integration strategy of SOA is based on web-services calls between systems. The promise of SOA is that with integration at the services layer, you can replace systems without having to stress out over where in the code all the integration points might be. Additonally, with a clear integration layer, organizations avoid the pitfalls of direct database access across systems. Services are distinct, clear and easily found and maintained.
All good. By all accounts everyone pretty much has arrived. Note: If your company isn't there yet, "plan to party like it's 1999," because you pretty much aren't living in this millenium.
There are a few things that are often overlooked in SOA implementations. I'll list them in summary here, and we can delve into them below:
- Take the opportunity to architect in a "Vendor Broker" solution for third party providers.
- Make sure accountability for SOA maintenance is well defined.
- Avoid synchronous traps.
Here we go!
Vendor Broker Component
So, what is this Vendor Broker Component? Very simple. Its a tailorable component that governs how much business you give to third party providers. This is nothing more than a traffic cop directing traffic that you can instruct. A vendor broker is a key component to keeping your business operational costs down.
Why? Well, if you want to keep your costs down, and continually drive them down, it's a good idea to treat your suppliers as comodities providers. Lets say you get data from "Data Provider A." You have a great relationship with them and have done business with them for years. But now they inform you that they are going to raise their rates. You're stuck. It might take a few months to integrate to another provider, assuming you can get through legal in a short period of time. You don't have the leverage you need to keep them constrained.
A services Broker component puts the leverage squarely in your hands. The broker directs requests to different providers. You configure it so that you can route business to the provider you want to get the majority of the business, and if you change your mind, you can change it immediately.
Now, lets replay that meeting with Data Provider A. He wants to increase rates. You respond, with, "Wow.. I don't know, I was hoping you were coming in to lower rates." (I love it when this happens!)
They hold their ground. They know it will take you months to locate and implement a replacement provider. They're banking on the fact that this exercise would not be strategic for you. You probably don't have the resources available at this time to work on the new migration. They're banking on the fact that you have more important things to do than migrate away from them. They believe you are joined at the hip with them and they can get away with the rate increase. It's a small increase, anyway...you love their service, and you'll soon forget.
After the meeting, you immediately call Scotty in the engine room and tell him "Set the broker to only deliver 20% of the business to Data Provider A and give the rest to Data provider B." Minutes later, you're on the path to showing Data Provider A that raising your rates could really hurt their business.
Next Meeting:
Data Provider A: "Hey, we've been noticing your orders are down considerably this month."
You: "You guys are a bit pricey. We want to do business with you, and we'll continue to give you business, but you're going to have to do something about those rates."
They understand what's happening.
Tada! You get lower rates. You tell Scotty to turn up the thrusters for Data Provider A. Give it a few months, and the guy from Data Provider B will call next. Eventually, you get to replay the whole meeting with a new set of players (Data provider B).
Guess what, you're being fiscally responsibile to YOUR company by driving costs down. By the way, as a business person, its critical to not blow away any given provider because, if you do this right, you can leverage multiple providers over time and get unbelievably cheap rates. But to do that, there has to be competition for them. Take the time to do this right.
Accountability for SOA
If you are in a highly dynamic shop, where your employees are constantly changing maintaining and enhancing their platforms, its imperative that services ownership lives with the platform that built them. I know that sounds just too logical. However, I've seen (all too often) that the services build out is a "once and done" sort of event, and platform integration deteriorates as systems evolve. The key to SOA accountability is:
- Assign an owner for the services in the platform.
- Have them broadcast changes in the platform to all services consumers (other systems owners that use that platform's services) and
- Make sure services testing is in place each time a release goes out.
Seems simple enough, but often overlooked.
A Final Word: Avoid Synchronous Traps.
There are two ways to communicate with services: Synchronously and Asynchronously. While SOA is a great way to architect solutions, be careful to not become overly dependent on synchronous communication. For those who may not recall what these two terms mean, synchronous requires a response before moving forward... Kind of like your 3 year old asking you a question. They follow you around and don't let up until you give them what they want.
Asynchronous communications allow you to submit a request, and move on... The response will eventually come. Its critical in SOA to try to push asynchronous interfaces, or errors will start piling up when your integrated partners experience their troubles.
To do this effectively, build a timing feature into your Broker component, and tie that to a service level contract with your providers.
That way, when you need something that feels "synchronous" (i.e real time quick response) you don't tie up resources if a provider is "down" and can reroute an order to a provider that is "up." A common problem is that IT people tend to think of asynchronous communication for lengthy transactions. That's a common misconception: Aynchronous doesn't mean that you should have to wait a long time before a response. You can build asynchronous integration that "feels" synchronous (i.e. expecting a quick response), but you should design your system to effectively handle outtages that aren't yours, and allow for a rewarding application user experience. If you build in too many synchronous integration points, your users will feel pain when any of those have slow performance or are down and they get stuck in your app.
What are some of the strategies you've implemented and challenges with SOA in your organization? I'd like to know.
No comments:
Post a Comment