Monday, June 25, 2007

SOA, I could just K.I.S.S you! - Part 4

Welcome back. If you missed the first three parts of this series, please follow the links below to start at the beginning.

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

Friday, June 15, 2007

Thinking Inside the (Black) Box

I will get back to my K.I.S.S. plan soon I promise. But first I wanted to put this out there.


When you order a book from Amazon, do you really care what happens between the time you click the Submit button and the moment the book arrives at your door?

Besides the confirmation and shipping notification emails you receive, your interaction with Amazon (for this transaction) ends once you hit that button.

What would you say if I told you that when you click that Submit button, a piece of paper prints out and a buzzer goes off that signals a monkey to grab the paper and run it across the room and put it through a slot in the wall? Would you care?

What if I told you that on the other side of the wall were scores of high school track team members decked out in full running gear that took the piece of paper and sprinted out of the building, down the road and into the warehouse where they put the piece of paper through another slot in a wall? Would it bother you?

What if I told you that on the other side of that wall was a series or ordinary but organized white boards that neatly listed the exact quantity and location of each and every book in the warehouse and that someone quickly located the book you ordered and wrote it on the paper and slid it through another slot on the opposite side of the room? Would you lose any sleep?

What if I finally told you that someone on the other side of that wall picked up that piece of paper, jumped on a forklift, found your book, wrapped it up and dropped it in the mail? Would you ask for a refund?

Barring the mistreatment of animals (I can assure you the monkeys are well taken care of) or the existence of child labor (all the high schoolers are of age), your answer has to be a resounding "No! I don't care"

The bigger question is: Why don't you care?

You don't care because HOW it happens is not important. What's important is the fact that it happens and furthermore that it happens in the expected amount of time.

This is of course the easiest possible example to give, and while this is certainly NOT Amazon's order fulfilling process (at least I hope not), it is of no consequence because Amazon is operating as a black box. What does that mean? That means that we only care what goes in, our order, and what comes out, our book. What goes on behind closed doors is irrelevant to us.

This is neither a new concept nor a unique one. You probably encounter such a situation about 100 times a day. Where does your food come from? What about that coffee? Do you even know how your mail gets to you other than a person drives it (or walks it) to you? No you don't and ultimately, other than natural curiosity, you don't care.

So what then is the big deal? Well the big deal is not the big black box. The big deal is what is in the black box.

Many processes are written as a single black box. Input comes in, gears turn, lights blink, data is processed and output returns. While this is still of no consequence to the consumer, the owners of this process, the ones that do know what's in the box, are saddled with one giant machine. When that machine is working, life is good, but when that machine stops working or needs new parts or is due for an upgrade, the whole operation is affected. The only solution to avoid down time is to have two giant machines and take them down one at a time. Not exactly the end all, be all solution.

What then can be done? Well, for starters, let's explore this black box concept a bit more. What makes the black box so appealing is the independence that is achieved between the consumer of the process and the process itself. As long as the rules of interaction don't change, the consumer is unconcerned with the inner workings of the process. This independence provides enormous freedom to the consumer as well as to the provider since the process can be changed freely as long as the interaction contract is upheld. Even if the contract requires alteration as part of other process changes, the consumer need only be concerned with the changes that directly affect them, and not what's going on inside the box.

Well this sounds like a nice situation to be in. Freedom to make a change without notifying consumers (we're talking technical changes here only). Even our "two giant machines" approach works here since one can be brought down, changed and then brought back up followed by the second one. The consumers have not been impacted (with the obvious exception of performance), and the process has been upgraded.

But what if the upgrade only applies to a very small portion of the process and is a very minor change? Does the whole process really need to come down for such a minor change? Will the business owners understand why the entire system is affected by something that by all accounts is minor? And what of this minor change? Is it really as minor as it seems or are there other dependencies that have not been identified? The process is one giant machine. The designs for the machine are still available, but have they been updated with every minor change that has happened since it was first built? How many minor changes happened before it was even completed?

Perhaps this change, the one that seems so minor, is not so minor after all. Perhaps it is major. Perhaps it is beyond major. Perhaps a thorough audit of the process is necessary to evaluate the impact of the change before the change is even planned. How long will that take? What's the ROI of such an allocation of resources? And what about the new features that were planned for the process? Will they now have to wait until someone figures out how to make this "minor" change? Suddenly that giant machine, excuse me, I mean both of those giant machines, have lost some luster. Suddenly things have come to a grinding halt. And why? Because you wanted to make a minor change. Try explaining that to your boss.

Ok, so what then? Well the answer lies within, so for once, I will tell you to think inside the box. The same freedom gained by the first black box's isolation can be expanded. Think of a Russian Stacking Doll. From the outside it looks like a doll. But within each doll is another doll. While this is a fairly rudimentary example, the same can be done with black boxes.

Let's look at the fictional Amazon process closer. We have already established that when you enter your order, you don't care where it goes or how it gets there. Your order has thus entered a black box. When the order prints out and the buzzer goes off, the monkey has no idea where the order came from nor does he care (assuming he would even understand but these are Amazon monkeys remember). You may have submitted it from home on your laptop or perhaps on a train with your wireless. Heck, for all the monkey knows, you could be on the other side of the wall tapping out your order in Morse code. So while you don't care how your order gets fulfilled, nor does the process care where your order came from or where it is going (of course it must know where it is going so it can get it to you and who it is going to so it can bill you, but these are simply points of data not permanent relationships).

The interesting thing here is what happens next. The monkey takes the order and slips it through a slot in the wall. At this point, the monkey is done with his job and can go get a treat. So not only did he not care where the order came from, he didn't care where it was going other than through the hole in the wall. So in essence, the tasks of printing the order and delivering it is its own process and has itself been created in a black box. This is important but let’s keep going.

Now the order comes to the high school track team members. Once again, the students have no idea that a monkey has just hand delivered this order and once again they don't care. Their job is to take the order and run to the warehouse and slip it through the wall. That's it. Job done. Get some water and walk it off. Again, black box.

The order is now in a room with hundreds of white boards all delicately spaced to avoid the accidental butt erasure. Those in the room have no idea and no time to worry about how the order got there. They need to pick it up, find the book, write down its location and get it to the other side of the room as fast as possible. Black box.

Once there, the warehouse worker has no idea that this order has passed through the hands of a monkey, a high schooler, and a slightly loopy (from all the dry erase markers) clerk. But once again, he doesn't care. His job is clear. Get the book from the location on the order, package it and mail it to the address on the order. You guessed it, black box.

We could keep going with the mailman picking up the package or the mail processor routing it correctly all the way to your friendly mailman who delivers it to your door, each one not knowing or caring exactly how the package got into their hands. Black boxes, each and every one.

So what? What have we shown? Instead of one black box, we showed several. Big deal right? Right! It is a big deal because the very freedom that once existed only between the consumer and the process now exists within the process itself! Each black box has very specific (albeit simple) interactions, namely a slot in the wall. The input? A piece of paper. The output? For all but the final step, a piece of paper. What if the monkeys become belligerent? What if they start passing their poo through the slot instead of the order (I've seen code that actually does that)? Do you shut down the whole process until you can find more monkeys? No. Simply find some well trained dogs, put them in another room, and start routing the orders to them instead. The high schoolers still get the orders and have no idea that anything has changed (although the saliva might give them a clue, but they're high schoolers so their use to that right?).
What about when all the high schoolers are taking the SATs? Do you need to shut things down? No. Simply go grab some kindergarteners (with parent approval) and buy a bunch of candy. Trust me, they'll go for hours and hours and hours and...

Don't look now, but if you haven't already noticed, no where in their little process here has Amazon actually billed you for your order. Oops! The solution? Yep, you guessed it, buy a bunch of parrots and put little colored visors on them. Have the orders from the monkeys (or the dogs if the monkeys have already started throwing poo) go to the parrots' room. They can process the billing and then pass the order through their own slot to the high schoolers and off they'll go.

The monkeys and dogs have no idea any thing has changed and neither do the high schoolers (although they are starting to ask questions about the feathers now stuck to the saliva). So just like that, the process has been upgraded and no other portion of the process was impacted.

One more. Amazon has decided that it can save time and money on white boards if it uses them to track only inventory and a sophisticated rolodex system to track the locations of the books in the warehouse. So a new room has been created to house the rolodexes. The clerks in the white board room now need to verify the availability of the book and then pass the order to the rolodex room to get the location. The rolodex operators write down the location of the book and returns it to the white board room where the inventories are updated, and the orders are passed on to the warehouse floor.

High schoolers: unaffected. They still deliver the orders the same way. Warehouse workers: unaffected, orders are still delivered the same way with the same information. The only ones affected are the white board clerks who must now perform three tasks: Check the inventory, pass the order to the locator room and then update the inventory.

The point of all of this is simple. Why create one giant process when you can create several independent processes that work together to form that giant process. In fact, many of these processes are so simple that you can hardly call them processes. Instead, let’s call them services.

I know, I could have just said that from the beginning right? But that is exactly what we've created here. Services. Each one focused on a specific task and each one using a mix of processing and other services to accomplish their work.

I know what you are thinking. "Amazon, monkeys, dogs, parrots, high schoolers; this is all cute but the real world is not that simple."

Ah, but isn't it?

I'll grant you that your black boxes will not be so easy (or fun) to design and build. It takes time and perspective to see all the pieces and to decide which of those pieces belong together and which belong apart. But don't let time and effort be the deterrents that prevent you from accomplishing the end goal.

But what exactly is the end goal? That can best be answered by returning to the single black box we described earlier. Remember that minor change that turned out to be not so minor? How much money would ultimately be spent trying to make that small change? How many person hours would be wasted? How much revenue lost because you had to delay new features that new sales were depending on? It all adds up and it all adds up quickly. It won’t be long before your competitors either catch you or surpass you in features and sales. Soon you will be the ones playing catch up and all because it takes an enormous amount of time, effort and money to make simple changes to your process.

But, perhaps your process is not like this at all. Perhaps your process is nice and clean and can be changed easily and was designed to be flexible. If this is the case then I commend you. But what about other processes in your organization? Does your process rely on any of them? Are they designed as flexibly as yours? If not, your process is at the mercy of those not so flexible processes. Maybe your process is self contained and does not have dependencies. Great, but do any other processes do similar tasks? How much time and money could be saved if those similar tasks were combined and shared?

I am not going to tell you that this is an easy thing to do. There is no magic bullet and no product that will do it for you. It takes time and it will take money to create processes and systems that are capable realizing this vision. But what I will tell you is that time and money spent now will have huge returns down the road, and if you truly commit to the plan and see it through, then those returns will not be as far down the road as you think.

Wednesday, June 6, 2007

SOA, I could just K.I.S.S you! - Part 3

Welcome back. If you missed the first two parts of this series, please follow the links below to start at the beginning.

Step 1 - Stake in the Ground

Step 2 - Education

Step 3 - Organizational Governance
This is where the rubber starts to hit the road. But again, realize that you still are not ready to hit the highway yet. This step involves getting your resources, processes and policies defined. In addition, you also need to begin thinking about funding strategies.

Resources
This is the time you need to identify who will be part of your SOA Center of Excellence (COE). This group will bear the burden of SOA for the initial phases and be responsible for defining the processes and policies and driving the effort forward. The idea here is that a small group can learn and evolve much faster than a large group. The goal should be that the members of the COE will eventually disperse into the enterprise and share their knowledge. As such, this group should be made of a diverse group of people from different areas of the organization.

Processes and Policies
It is important to remember here that you need not solve all the problems on the first pass. SOA is an evolutionary process and as such, you should focus on getting some best guess processes and policies in place. For processes, focus on strategies for identifying, requesting and evaluating services. For policies, focus on things like security, message exchange patterns and messaging profiles (e.g. WS-I Basic Profile and Basic Security Profile). Identify who your consumers might be. This is still early, but taking the time to think about this will help you identify the types of service interaction you need to consider moving forward as well as some educational topics you might want to consider (do you know what REST really means?).

Funding Strategies
This is never an easy task and there is no one way to go about it. The proper funding strategy for your organization is dependent on a host of parameters. Some of those parameters include: existing project funding model, existing infrastructure funding model (if any), willingness of project managers or budget owners to contribute to the effort, C-level support or mandate etc. In the end, you will find that this will be the biggest obstacle to your SOA effort. Without budgetary backing, all SOA activity will remain on the drawing board. Below are few possible paths to take, but again, these are nothing more than high level suggestions that should be adjusted to your environment:

  • Establish a Shared Services Budget - This approach represents a very communal strategy by setting up an environment that is conducive to success. The shared services budget is aimed at accomplishing two things. First, by setting aside money for build out of the shared infrastructure it allows the COE to lay some necessary groundwork and to continue to improve or maintain the common infrastructure. Second, by providing a community chest of sorts, it serves as a buffer to project teams who want to include either the utilization or creation of shared services in their project plans knowing that they will either spend less money (by utilizing) or have the costs (of creating reusable services) offset. A very important part of this approach is reconciling a project team's costs against contributions to or utilizations of the shared services infrastructure. Without doing this in a very visible and communicated manner, project teams may be reluctant to interact with the shared services for fear of coming in to far under budget and having subsequent budgets reduced as a result. This may sound counter-intuitive (that project teams don’t want to save too much money), but it is a reality in many organizations. Inevitably the goal IS to reduce the budgets across the board but it must be done in such a way that project teams do not feel as though they are being targeted for downsizing.



  • Create Incentive Programs - This approach represents the carrot. Offering incentives to project teams to create or use shared services will motivate people at a very real level. It’s very difficult to convince employees that operational efficiencies and budgetary improvements will translate into monetary savings that will trickle down to them. Instead, offer them short term incentives for suggesting, creating, driving, promoting and utilizing shared services. These incentives can be both team oriented (a long weekend, a nice dinner, recognition on corporate internal network) and personal (commendations, bonuses, raises, promotions). There still needs to be some general funding for the creation of the common infrastructure as well as periodic maintenance, but this money will be exclusively used for those purposes and not allocated to teams as they contribute. A key part of this approach is to recognize and not penalize project teams for going over budget if the extra money was spent contributing to the shared services. Obviously these efforts need to be coordinated and planned, but project teams need to be encouraged to think about the bigger picture and know that they will not be penalized for their efforts.



  • Create SOA Mandates – This approach represents the stick. Creating mandates to contribute to or utilize the shared service infrastructure will force project teams to make reuse a part of their process. Optional tasks are often the first ones to go when the schedule and/or budget start to become a factor. By creating, communicating and enforcing SOA policies and procedures for the project teams, they will have no choice but to alter their process to incorporate them. Obviously a very important step in this approach is to create clear, strategic and aggressive policies regarding the incorporation of the shared service infrastructure. The reason the policies need to be aggressive is to account for the natural learning curve of the organization as a whole. The organization will inevitable fall short of what ever policies are put forth initially, but by making the policies aggressive, you ensure at least a certain level of success and at the same time the organization will learn what is expected. The key here will be to slowly ramp up the enforcement of the policies or more specifically, to slowly increase the penalties for non-compliance. Initially, the enforcement should take on a mentor’s role where teams are warned rather than punished and shown how to succeed rather than penalized. As time goes by and the maturity level (or expected maturity level) increases, enforcement will become more penal.


Continuing Activities
Don’t forget that this entire process is cumulative. This means that the support you got in the beginning needs to continue to be there and continue to be communicated. Monthly updates or a recurring newsletter from the SOA champion (with contributions from the COE) will keep the effort in the fore front and help ensure that this isn’t one of those initiatives that gets hype in beginning and then forgotten about (The company may be used to that unfortunately).

In addition to continued support, there must continue to be education. This will include both continued education for the COE, continued enlightenment of the SOA champion and the beginnings of education outside the COE for people such as key business owners, interested project leads or anyone else who comes calling. The key here is to provide interested and key parties with the information they want or need, but not to hijack them and force them into day long learning sessions. Eventually such sessions will be beneficial, but for now, focus your efforts on those who want to be a part of the effort and those who are essential for success. If you make the effort public enough and get consistent reinforcement, you may be surprised to find how many people come to you.
_________________________________

Next Up: Evaluate Your Infrastructure

Monday, June 4, 2007

SOA, I could just K.I.S.S you! - Part 2

Welcome back. If you missed the first part of this series, please follow the link below to start at the beginning.

Step 1 - Stake in the Ground

Step 2 - Education
Now just because the name of this step is "Education" does not mean this is the only time that education will be taking place. In fact, it is safe to say that the entire process is about education as much as anything. But here in this step, education is the primary task.


****WARNING****
This is a typical place where things start to go wrong. Instead of taking the time to become educated on the various problems, possible solutions, vocabulary etc, many companies go right out and start implementing services or buying "Service Oriented" middle ware only to realize in time that they have no idea what they are doing. Of course then they will have invested time and money in some product or some group of services and stepping back away from money spent is a hard thing to do for any company. The natural tendency then becomes to push forward and make do with what you have. This results in more consulting fees, more product acquisition and more time spent going sideways or backwards. It won't be long before SOA is a four letter word and all hopes of achieving it are gone.


Before going down this road to despair, you need to start learning what SOA is, what problems it solves and what the challenges are regardless of whether you think you already know or not. You will undoubtedly find at least one thing that you weren't aware of or perhaps find that something you thought you knew was wrong. Any bit of knowledge gleaned from this is a success because you are progressing down the path.


One tidbit I'll offer is this: SOA is not a box of new ideas. In fact, you will find that SOA emphasizes many of the same concepts that have always been good ideas (Information Management, Governance, Business Process Management etc).


At each step, you will find that continued support from the top is important. Facilitate this by having regular updates with the SOA champion so they can see the progress you are making. Try to educate them as well as you educate yourself. Take care not to focus on the technical aspects to much when doing this however. Their main interest is how it affects the business. If you can continue to show how the business will be improved through your efforts, then you will continue to get support.
_________________________________

Next Up: Organizational Governance

SOA, I could just K.I.S.S you!


No I'm not a weirdo with some software fetish. By K.I.S.S of course I mean the tried and true "Keep it Simple, Stupid" method. Now I am not saying that SOA is simple so let's get that out of the way right now. I've been doing this long enough to know that it is far from simple. In fact, I've been doing this long enough to know that it is actually quite complex. Of course like most things in the software architecture world, we over complicate it to the point where we either paralyze ourselves or paralyze the very people we are trying to help.


Show of hands:
How many of you have sat through an SOA lecture or webinar and come away with a headache?


That's what I thought.


Of course we also have the opposite problem at times. Some people like to make it SO simple that all you have to do is buy their product or implement their program and voila, you're service oriented. How many of you have gotten that presentation?


Like most things in life, the answer lies somewhere in the middle. Yes it is complex and yes it will take time and commitment to achieve ultimate success. But SOA is not something you just do. It’s not a project you assign to someone to tackle. SOA is an iterative process that involves the entire organization and there are successes to be had along the way. It is the culmination of these successes that ultimately results in overall success of your SOA initiative. Taking on too much at one time or trying to big bang or fast track your way to SOA will ultimately lead to failure. So again I say, "Keep it Simple, Stupid".


In a series of posts I will lay out a simple plan for achieving iterative success. Don't take this as a recipe to follow exactly or as your definitive guide to SOA. Instead take it as a blueprint of sorts; a series of checkpoints and milestones that can be tackled iteratively. Each one comes with its own success, some small, some big. Remember, something doesn't have to end world hunger to be classified as a success. Sometimes it might be nothing more than knowing more today than you did yesterday. As long as you are moving forward down the path.


Step 1 - Stake in the Ground
We'll start right off with one of those simple successes. It may not seem like much, but simply making a decision to address your issues is a success. Of course this needs to be more than 1 person making the decision. It has to be a top down decision stating that the efforts to address the issues and work towards a SOA will be supported both verbally and financially.


A key piece of this step is also to understand the issues at a high level. This understanding has to go all the way to the top. You don't need to know or understand each and every issue in exhaustive detail or how to solve it though. That will come in time. Simply recognizing that there is a problem is a big step that is often overlooked and the decision to support an SOA initiative has to come from that recognition and not from some charitable management offering (e.g. "Well IT wants to play around with some new stuff so let’s give them just enough leash so they'll go away").


A formal speech or email from the CIO (or equivalent) that expresses the commitment and support of the effort is an important milestone. This will not only express the top down support, but emphasize that it is not a passive or low priority initiative. This will go a long way in motivating everyone to participate or at the very least not hinder the effort.

_______________________

Next up: Education