Step 1 - Stake in the Ground
Step 2 - Education
Step 3 - Organizational Governance
Step 4 – Evaluate Your Infrastructure
Hopefully by now you will have found an SOA champion, identified resources for the COE, defined some initial processes and created a general messaging profile. Now it is time to start thinking about your infrastructure.
STOP!
Before you go out and start evaluating various SOA infrastructure products, you need to consider the following:
- You do not need to build out your entire SOA infrastructure at once.
- You will not know what you need or want until you actually go through some pilots.
- You will be easily swayed by vendors unless you understand the implications of various features or the lack there of.
Typically the first piece of infrastructure that people go after is the registry. We’ve read and heard about for years how the first thing you need in your SOA is a registry. This approach however has two practical problems. First, most registry vendors no longer offer JUST a registry but rather an entire automated design-time governance solution. This is great on paper, but shouldn’t you actually establish some governance processes before you start automating them? If you don’t, your governance processes will essentially become whatever the product you choose supports. Second, why do you need a registry for services when you don’t even have any services? This is equivalent to Alexander Graham Bell selling a phone book before anybody had phones.
This may sound slightly against the grain, but I don’t believe that a registry is the first product you should add to your SOA infrastructure. There is nothing wrong with starting out with some manual governance as you walk through the initial phases of your SOA initiative. Your first consumers will most likely not be using UDDI to discover your services, negotiate contracts and bind to your endpoints and you certainly will not be evolving so quickly that you need to deal with things like version management or dependency tracking. Everything can be taken care of with good old fashion communication, especially in the controlled environment that you will be working in initially. It just doesn’t make sense to start automating something you haven’t even done yet. If you do, you will be trying to learn how to automate and how to govern at the same time. Rather you should be focusing on learning about service types and layers, how to identify reuse opportunities and how to model your domain along with how to govern at design-time.
Remember, the theme is “Keep it Simple”. Think about what you need right now and not what you THINK you MIGHT need or what vendors TELL you you’ll need. Think about the goals: interoperability, platform independence, reusability. This boils down to 2 things: XML and HTTP. Since you should have already thought about some other requirements (remember the messaging profile), you may have further refined this to include things like SOAP and WSDL (or maybe not, it all depends on your NEEDS). If security beyond SSL is required (for example encrypting portions of a message for persistent stores like auditing and logging or for end-to-end security through intermediaries), WS-Security enters the mix. What about reliability? Do you have business drivers that require guaranteed delivery of a message? If so, then WS-ReliableMessaging and maybe even JMS come into play. Given all of this, you should evaluate your current toolset and determine whether or not it can support your immediate requirements. If not, then that is where you need to start.
I can’t stress enough how important it is to take an “as needed” approach. If you go out and purchase management, monitoring and governance products before you have designed and deployed a single service, you will constantly be under the gun to utilize and show return on those investments (which will be significant) not to mention overwhelmed with a slew of new products that no one knows how to properly utilize. Add to that the fact that ROI is sometimes hard to quantify (often coming in shorter maintenance cycles, better accommodation of change requests and less headaches overall) and you may be so far behind the eight-ball that you have no chance of succeeding.
You must let the game come to you. As your knowledge and overall organizational maturity increases, so will your ability to strategically add pieces to your infrastructure that make sense and satisfy a need. The best way to start out down this path is to identify some of those needs. This means finding a pilot project. Once you identify a pilot project, you can use it to determine (or validate) what your requirements are and from that determine what if any products you need to acquire. Remember, this step is about evaluating what you have against what you quantifiably need. As such, building out your infrastructure doesn’t necessarily mean buying products. It might simply mean re-appropriating existing tools.
As mentioned above, a pilot project is a key piece to this step. As such, the activities described here will overlap with the next step which is of course the pilot project. Much like education, this step is one that will be ongoing throughout the life of your SOA for there will always be new requirements, new challenges and new solutions.
____________________
Next Up: Pilot Project
No comments:
Post a Comment