Wednesday, June 27, 2007

Disruptive Technologies that make you go hmmmm

Two separate events in the past few days have made me consider disruptive technology and it's impacts. While fun for those standing on the sidelines it has to also be a terrifying event for those who are in the middle of what is being disrupted.

Disruptive Tech 1: The iPhone. Yes, the often referred to Apple foray into the cell phone business (in some cases referred to as the "Jesus Phone" it's PR is so big) is a great example of a disruptive technology. It is already wrecking havoc with phone manufacturers and not because it is the worlds best phone, but it is slightly off from today's phones. The NY Times put out a great article late Tuesday night as the phone was hitting the general population with the compelling headline "The iPhone matches most of it's hype". Gizmodo posted a good summary of "Finally Confirmed: What the iPhone doesn't have" [Songs as Ringtones • Games • Any flash support • Instant Messaging • Picture messages (MMS) • Video recording • Voice recognition or voice dialing • Wireless Bluetooth Stereo Streaming (A2DP) • One-size-fits-all headset jack (May have to buy an adapter for certain headphones) • 3G (EV-DO/HSDPA) • GPS • A real keyboard • Removable battery • Expandable Storage • Direct iTunes Music Store Access (Over Wi-Fi or EDGE)]

That's quite a list for something that is still going to change the phone world. It has a controlled UI and OS. You can't load things on it and Jobs has made no bones about confirming that will remain the case. But it has a paradigm changing interface, consolidates devices for those with iPods and Phones and PDAs, even smart phones. As eloquently stated by David Pogue in the times article "It’s substance; it’s style. It does things no phone has ever done before; it lacks features found even on the most basic phones."

Personally I am going to hold off getting one. I recently purchased an 8525 (YAY I get to skip my Blackberry across a lake) and I have been quite happy with it. (heck I have already customized the snot out of it and have my Yodeling cow ringer going) But the geek in me covets parts of the iPhone and I may end up with one when I next need a phone... when it uses the faster Edge network and apps to get to business email are actually available. In any case, the reactions from the "old school" cell phone makers is going to be a blast to watch.

Disruptive Tech 2: Google Applications. I have to admit that when Google first rolled these out I thought to myself "ok... that's nice... why do people even try to beat Microsoft in this space?" Well a quiet little post on the Google blog made a light bulb go off for me. Google isn't trying to hit Microsoft at the desktop (well not right away) they are hitting them squarely in the admin.In the blog post Google indicates how they are going to give free access to advanced features of the full Google office to schools. The standard package for individuals is free already but a Premier Edition, targeted at companies is also available for $50/user. Now the Education Edition also includes the ability to integrate with existing facilities, conference and resource scheduling and other premium services.

Educators want to educate. They don't want to run systems for email etc etc. Now, they can get email, integrated chat and other niceties for free. This is where giving it away starts to make sense. It's not just about giving it away to the individual consumer in hopes of pushing ads. It's about pushing it into corporations... wow, now that has to be a scary thought. As with the iPhone, it may not truly change the world, but the potential is there and it will be fun to watch. (By the way, although corporate email isn't available via the iPhone... if you use gmail you are good to go... hmmmm)

Tuesday, June 26, 2007

Every integration point created WILL fail and Scalability

I have two things for today's post.

1. I received a note this AM from my "FYI- Jana RSS feed" (A good friend that works with me that sends me email) that I had to pass on to everyone. Read the article because the quote below is SOOOOOOO true.

“One of my recurring themes in "Release It"
is that every call to another system, without exception, will someday try to
kill your application. It usually comes from behavior outside the specification.
When that happens, you must be able to peel back the layers of abstraction, tear
apart the constructed fictions of "concurrent users", "sessions", and even
"connections", and get at what's really happening…”

Agile, Architecture and
the 5am Production Problem
- by Michael
Nygard

2. This weekend I attended the Seattle Conference on Scalability. It was sponsored by Google and it was GREAT. Over the next few weeks I will digest what I heard and saw and report it back via blog. At the moment though I have to admit my dueling day jobs are getting the better of me so I haven't had time to couch my ideas into pithy post prose. I promise it is coming though. I will however let you know that Google recorded the presentations and they should be available by the end of the week on YouTube.

Monday, June 25, 2007

Enterprise Architecture is not technology selection

Now that I have extolled the virtue of standards like muscle building and listed our current set I wanted to post a bit on why I believe having a consistent Enterprise Architecture is important.

First and foremost on the list of why an Enterprise Architecture is important is that for a company to be successful it needs must build IT Solutions, not IT Capabilities. What is the difference you ask... (or even if you didn't I am going to tell you anyway) Capabilities can survive in non-integrated verticals but Solutions require integration. An End to End view of paths and functions is required to get a solution. An IT Capability is something like storing a customer information record in a database. A Solution provides the customer with value because it can use that information and to customize a trip.

One of the fundamental rules of development is breaking things up into smaller, solvable pieces. At the individual system level this makes perfect sense. However, when you start to look at things at the enterprise level, things implemented in pieces build piecemeal solutions. Then, these piecemeal solutions need to be integrated. This is what I have referred to in previous conversations as the fiefdom effect. Essentially, this is where individual systems or areas have their own fiefdoms and protect their system boundaries and "control their own destiny". While this may be fine a micro level, the independent pieces work fine after all, at the macro level this increases the integration burden and decrease overall company agility.

This is where we get to what Enterprise Architecture is all about... Enterprise Architecture's (and Engineering, YAY Engineering!!) job is to take a long term view so that teams can build capabilities not just fulfill the short term order of the day. If we have a solid base upon which to build (and this is an art in itself, not building the Taj Mahal or better yet the Winchester House when an outhouse will do the job) we enable everyone to move much faster and make integration between components that much simpler.

Yet another argument for a seamless SOA infrastructure. Or at least that's what the vendors are touting as the latest Technology Software solution for this problem... but we will save that post for another day.

Tuesday, June 19, 2007


Monkeys down a fire pole

How many monkeys can slide down a fire pole in 5 minutes?

Ok, so this question doesn't seem to have a lot to do with technology or engineering when you fist consider it. But give me a little bit of patience and let's see where we go.

I have recently begun to undertake a personal quest for education and education provision to others about threading and how to do it well and efficiently. With the introduction of multi-core processors and processor companies no longer creating faster and faster single core CPUs with clocking, over-clocking and over-over-clocking, it has become more important to actually understand threads.

Even as recently as when Java first came out the only places that you really ran into threads in open systems was in Solaris (or other Unix) systems with big multi-CPU backplanes. These were usually reserved for big 'ol database boxes though so you could optimize your system to really what amounted to one big fire pole. If we imagine each processor as a fire pole and each unit of work to run as a monkey, we can start to use my fun little analogy.

Everything you did was about queuing up the monkeys efficiently then sending them down the pole as quickly as possible for each individual Monkey thereby maximizing your monkey throughput. Great schemes for keeping the Monkeys in the right order, keeping the pole clean during non-monkey sliding moments (Garbage collection in Java-land) and other similar optimizations were the wave of the day.

Now the fire poll manufacturers (Intel and AMD) discovered that they just couldn't build a faster fire pole without violating the laws of physics (and it's not that they wouldn't break those laws, more that they couldn't figure out how) and therefore decided the best way to move forward was to build a multi-fire pole firehouse in the same amount of space. It was a great innovation... but the monkeys were still optimized for a single fire pole. So in many cases (not all, but many) the fire pole (CPU) utilizations actually was very low even though other areas were slammed. Monkey lines (memory) and even Monkey storage (I/O) became bottlenecks with a low 25% pole usage.

The time has come to build education on efficient fire pole usage. We need more effective ways to slide those little monkeys down. There are some basic practices that seem to make sense. Sun recently explained how they are building better threading into Java and things are rolling out from there. That's a great start... but that is just a start. To really use the power we are now putting into machines we need to figure out better ways to feed the cores.

Help me save the monkeys... do you have any good tips, observations, sites or do you have any bad monkey practices that you have seen that should be avoided? This practice is, of course, not limited to Java but C, C++, Ruby and others. I would like to pull these together to be shared with everyone. If you have a good monkey tail please drop a comment. I would love to hear from you.

Monday, June 18, 2007

WARNING... FOR YOUR SAFETY...

Most home invasions come in through Windows...



Saw this come accross the wire on the Ubuntu site and laughed out loud after watching it. I thought it ranked up there with the Ruby Commercials. Of course it's a little simplistic since we all know there are vulnerabilities in Linux as well as Windows. Though the frequent target is certainly Windows due to the ABM (Anything But Microsoft) cooalition's distaste for the "evil empire".

Saturday, June 16, 2007

Build your Corporate Muscle Memory

I have posted before about the need for standards to allow us to focus on differentiating functionality and I have been thinking about this again since I have been working on a project in which standards are a big part.

Have you ever considered how as you learn something it become easier with practice, eventually become second nature? Watch a small child learn to walk and it is something that they have to really focus on at first. Then as we get older it is something that we simply take for granted. Does this make us expert walkers? Or do we just establish walking as a "dial tone" activity that we no longer need to think about?

Think about a chef. When they are first learning to do things they need to focus on every cut of a vegetable. But as they become an expert they no longer even measure a teaspoonful of salt. (BAM! Just watch an episode of Emeril Live and see how closely he holds to a written down recipe for an example.) A chef can do things without any concentration at all that many of us would require many times the time to do.

A runner or athlete is another good example. Runners develop muscles that work in very distinct ways. Their develop something called muscle memory that causes the muscles to introduce an actual change to how the muscles work. This change increases the level of accuracy and flexibility for running by optimizing the muscles for the repeated action. There is a trade off however, the muscles become very good at a certain set of items and less flexible for others. Because a runner is training to be a runner, not a gymnast this is a fine trade off.

Standards are similar in that we want to establish a Corporate Muscle Memory. It will require focus and concentration at first to do the new standard processes. It will also reduce flexibility to a certain extent in that there will be specific micro-processes that could become harder but the specialties become faster. But with the goal being to move as quickly as possible with agility towards the companies direct goals this is a trade off worth making.

Focusing our efforts on learning and optimizing according to standards allows is to build our Corporate Muscle Memory. We can then go faster and focus on differentiating functionality rather than dial tone. Just as with human ability companies ability needs to evolve over time and standards are no different. When the time comes to change a standard there will be a period of concentration required for us to develop that new Muscle Memory and for it to become second nature. But as we do whole new levels of speed and capability are possible.

Friday, June 15, 2007

Developers are Artists

In a meeting a little while ago I heard a comment, at the time said in a little bit of a flip way, that developers are artists. While not necessarily meant in a way that would suggest that Developers are right brain oriented, creative, canvas painting snobs the statement did get me thinking.

We were discussing standards. A topic that can be scary for people who want to forge their own way... artistically creating the next generation of award winning software... etc. (blah blah blah)

So off my brain went on a metaphor dive and it actually started to make sense to me. While artists want to be able to choose their own tools to ensure they get the right tools for the job there is a lot to be said for simplicity. Having the right brush size is critical... but it's still a brush. Certainly, there is a difference between the 10 for a dollar brush and the $20 brush but if you compare a $19 and a $22... is that really something an artist wants to waste their time doing? I mean really... there are people who are paid to do that... shouldn't the artist be creating... painting... utilizing their skills to make a difference.

Our approach to standards needs to be the same way. We will have people who specialize in brushes. Or in this case Database Platforms, Application Server platforms, Middleware solutions etc. We have a set of brushes sized appropriately for the job. Or in this case standard containers such as J2SE and J2EE containers both basic and fully enterprise capable... Tomcat, JBoss, JBoss with Clustering, etc. We want our artists to focus on painting the canvas with differentiating impactful imagery. Or in this case business logic that implements the vision the company has for functionality.

I realize some of you may be wondering just how deep my analogy rabbit hole is going to go but I will make a few more points and abuse it just a little more and then let you get on with your life. Just like brushes need to be replaced and a new canvas is occasionally needed so to do application and development standards need to be refreshed. Standards are just a representation of the best knowledge at a point in time. They are meant to be challenged, updated, and tuned. Without that effort and focus they become dated and slow things down rather than speed them up.

So as we set and roll out new standards as part of our efforts to accelerate development and increase stability and quality keep that in mind. Let's make it so that our artists can paint... but let's also challenge the status quo.

Wednesday, June 13, 2007

A case for the Designated Scapegoat

Have you ever considered why it is that when we consider systems we assign it attributes such as he or she or "misbehaving" or otherwise letting us down? I have. Why you ask.... darned if I know, I have a lot of random things float through my head and some of them are actually are entertaining. Hopefully this is one of those.

It seems that we as humans have a fundamental psychological need to explain things. So in order to explain them we put attributes either internal or external to explain why things happen. Maybe it is because from the age of "really small" we ask why? (and those of us who have children know the number of times we answer that question becomes numbing.) In psychology this is referred to Attribution Theory.

External attribution is things like "the devil possessed the machine and crashed it" or the ever popular "the data center is on a burial ground of some kind and it causes the servers to crash". It may not be true, but it helps us to deal. Or certainly to laugh at our misfortune.

Internal attribution is, in essence, blaming yourself. The easy example is things like "I am a sinner, please forgive me." We see this a little less in technology though it does pop up as well with the occasional person who perpetually places blame on themselves.

This fundamental psychological need is why I am suggesting the role of Designated Scapegoat on all projects. If a designated scapegoat is assigned at the beginning of any project we can simply move on to the fixing of problems since don't have to waste time in meetings deciding who or what is at fault. All of the posturing, political planning, set up, stonewalling, denial etc can cease and we can simply move forward. All blame can preemptively be assigned to the Designated Scapegoat and productive work can begin immediately. My experience with this role suggests that your Designated Scapegoat should be someone who is generally a good natured, understanding and who everyone knows in their hearts is beyond reproach.

Imagine how instead of a two hour meeting where people discuss why it is not their problem you start the meeting off with "Gee Chris, that was a mess up, I can't believe that you crashed the servers across the globe all at the same time." Chris then responds "Yeah, you know in Project Manager school we learned that the best way to crash a system is to push the button really hard, right in the middle." Then blame and attribution discussions are done and conversation can move to actual observed behaviors and problem resolution. What a time saver!!

So as a productivity aid for your next project assign a Designated Scapegoat up front, save yourself from Attribution Theory and all those unnecessary meetings. Focus on fixing problems, root cause analysis and long term fixes. Jump right past the blame game with this easy step.

Friday, June 01, 2007

Step 1... round up the lawyers

We have all heard the jokes and everyone has read the phrase before. The first step to improvement is round up the lawyers and send them to the bottom of the ocean.

If you have had your head under a rock or otherwise not seen any tech news lately you may have missed some of the latest fun with lawyers and the grand FUD they can churn up.

First Microsoft came out with a statements about how Open Source has violated 235 of their patents. Of course no details were provided on the patents themselves just a bit of churn and great press. Using their recent deal with Novell for patent sharing (Read my post on how when you wrestle a pig you both get dirty but the pig likes it for more info) as an example of "good" behavior they encouraged others to strike similar deals. Part of the real fun in all of this is how at the same time Microsoft was (out of another side of it's mouth some might say) calling for Patent reform due to suits from others against their own patent infringements.


Then the Linux foundation crafted a rebuttal. As would be expected they called out Microsoft on what the patents were. They clearly called out the FUD aspect and took a more offensive approach and begun to fund patent claims among other actions. Spinning from IBM, Sun and even Nokia releasing patents for Open Source use this approach seems to be gaining momentum.

Now the new GPLv3 is even including language that would cause Microsoft to loose rights to sue if the new Linux license terms in GPLv3 go forward. Further complicating this is how the deal with Novell may actually be what causes Microsoft to loose enforceability on the patents. Now even Novell is exploring patent reform. Even going so far as to fund "Patent Busting" activities.

Wow... I guess if you are a lawyer this would be fun or at least profitable. But as a techy I have to just sit back, pop some popcorn and watch the show.