Drag Racing vs Rally Racing

Some of you that know me outside of my Uptime Blog posts know that I am a fan of Rally Racing. In part it is because I drive a Subaru so I was drawn to watch. (Yes, a blue STi with the handle on the back so that God can reach down and shake me when he thinks I am doing something dumb is mine.) But also I like Rally racing because it takes a real world car (granted, they gut the interior and up the strength a bit on the components) and drive it like fiends through corners, over dirt roads, through snow and over jumps. It is a real test of driver abilities and a lot of fun to watch or even play on a game console.

So what does this have to do with technology? It has to do with optimization and how optimized you can make a system, either people or computing. If you take the example of a Rally car they need to have horsepower yes, but that is not enough. You need to have torque, suspension flexibility, handling adjustability the ability to turn and to stop is just as important as the ability to go. In one stage you may be racing on a mostly strait asphalt road, in the next over a switch-back 180 degree turn infested gravel road through a forest. The ability to handle that change is very important to build into the car. Conversely if you look at a drag race car the need for handling, turning, even suspension decrease. What you need is horsepower and pure strait line speed (and hopefully the ability to stop, though if you look at some of these cars a parachute is what is used). How boring.

I maintain that business is much more like a Rally race than a Drag race. You never know what curve a competitor is going to throw at you next. The ability to handle those curves, stop on a dime, turn in the other direction and then go full bore ahead again is critical to business survival.

Sometimes though we seem to optimize our ability to go fast and go strait. We focus only on the immediate goal in front of us. Cut out items that are not critical to our achieving that strait ahead goal. We optimize our "people load", "trim the fat", etc. to keep everyone as utilized as possible moving towards the strait line goal. Then a change comes up... and we discover we can't turn as fast as when we started and we are surprised to find we even have a problem changing our direction simply due to momentum.

This is why things like Non-Functional Requirements are critical to a project and a companies long term success. They maintain the ability to turn and stop and give the slack necessary to allow a shift one step to the right. If we are all pushing so hard to go forward in a strait line even adjusting slightly to the side is difficult. In planning this is Risk Management. It's accepting that planning "if all things go right" is not going to really get you there.

Getting the right strategy means you have to assume your competitors are damn good, or at the very least as good as you are, and that they are moving just as fast or faster. When it comes to peering into the future, you just can't be paranoid enough.

- Jack Welch

A Link, A List and a Quote

Not a big post for today. Just a simple one.

Mark Coulston recently published an article in Fast Company that is worth checking out. It is entitled, Don't Mess Up. IT lists the 10 things that smart leaders do to help them cope with stress that are actually destructive.

1. Avoid confrontation
2. Hire advisors, but don't listen to them
3. Don't accept when they're wrong
4. Avoid dealing with reality
5. Wait too long or not long enough to cut their losses
6. Focus too much on strategy vs. execution
7. Trust analysis over instinct
8. Trust instinct over analysis
9. Practice favoritism
10. Minimize the importance of what they don't understand

Mark also shares a quote and we all know I love quotes so here you go.

"Everybody here has the ability to do anything I do and much beyond. Some of you will and some of you won't. For those who won't, it will be because you get in your own way, not because the world doesn't allow you."

- Warren Buffett speaking the University of Washington

SOA reduces integration costs

Many times business applications typically reflect a software vendor's opinion of how a business process should be performed. Since vendor opinions and real-world processes often do not match, many systems fail to support actual business operations. Easy examples of this can be seen in the big ERP systems that are implemented and "customized" for many millions of dollars only to need more rounds of "customization" with every new release.

One of the goals of Service Oriented Architecture (SOA) is to change the way enterprises deploy applications to support business processes. Using things like Orchestration and Business Process Management technology teams pull together the needed connections to components with a business flow based on how business is performed. Then when business changes (I know, I know.. that never happens...) you simply change the wiring. Of course, that is the goal... in order for it to be a reality some things need to happen. For a list of some of what I think needs to change look at my previous series on SOA changes.

What do you get for all of this effort?

Essentially, you get reduced integration expense. There are of course other benefits, but from a business POV this is what you get. It could be as simple as a reduced integration cost with other systems and future systems, or changing systems. It could be increasing reuse of assets; always a good thing to use something that exists vs build it from scratch each time. Increased customer responsiveness in the ability to change and modify business process more dynamically. You even get a reduction in risk, both business and project level risk, because you are dealing with smaller components that may already exist and allow for localized changes. But, as I started this paragraph, it all boils down to lower integration costs that enable all of these things.

Zapthink recently published an interesting article on the REAL costs of integration as part of their justification for SOA. The most valuable think in the article for me was the picture of integration costs by phase. Go check it out.

The REAL costs of integration - ZapThink