I remember (vaguely) when I was in kindergarten, playing with my classmates, learning to make things out of clay and paper, and generally enjoying that sneaky introduction to education. Little did I know that my teacher (I forget her name, it was a long time ago) was grading my performance, checking off boxes on a card with phrases like "plays well with others" or the now infamous "Runs with Scissors."

As an adult and a technologist, I've grown to appreciate just how important that innocent-sounding "plays well with others" actually is. Yesterday I was having a discussion with some colleagues regarding how well we make systems work together. Interestingly enough, I found that I wasn't in favor of making everything seamless; I've come to believe that isn't necessary or beneficial.

People typically want their IT systems to be thoroughly integrated. That's not a bad thing, if those systems would just remain static and unchanging for many years. The challenge is that new technologies are continually emerging and clamoring for inclusion in the portfolio of applications.

Service-oriented architecture is designed to make it easy to arrange and re-arrange applications (well, services really, but in the end they get built up into some sort of application). In theory everything should integrate seamlessly. At the infrastructure level, that's been successful.

Where we still see the warts and ugly underbelly of IT is in the semantic interaction level. Being able to exchange a set of data regardless of transmission protocol, chip architecture, or implementation language has been a panacea for software developers, one which has resulted in a brand-new problem - now that connectivity and communication is ubiquitous, we find that we underestimated the semantic barriers to integration.

Even further, although the BPM vendors will say otherwise, we neglected to truly take into account that software is a living thing. It's born, it matures, it ages, and eventually it dies. When we look at portfolio management we begin to see that a static view of software is shortsighted. Ask any major corporation how large their portfolio of software is and you'll get a single answer - too large. Triage and retirement of systems are inevitable.

Technology shifts, including software as a service and cloud computing, have further blurred the line regarding how integration is achieved. Mashups are the poster child for just-in-time integration, and for just-enough integration. What we've evolved to, and what few people yet realize, is a move from monolithic long-lived applications to smaller, more mobile, more transient pieces that are assembled (or not) according to individual taste, rather than group, department, or corporation mandate.

This concept is the reason I don't necessarily support a full bore approach to application or even service integration. We have a much more dynamic environment today, one where consumer and commercial software blend to the point of indistinguishability. In such an environment, building hardened, long-term interfaces and integration is counterproductive. We use something if it's good enough, and when something better comes along with additional features, we drop what we've used in the past and move to the next set of functionality. I see this trend all the time - I used to see everyone on Yahoo! mail, for example, but now it seems that most people use Google, which offers added features and a better set of functionality (in my opinion).

These changes happen all the time. In many cases integration is unnecessary; in others it only requires a superficial layer to achieve what is desired (the old "lipstick on the pig trick"). We no longer need deep integration; what we need is "plays well with others." Just like in kindergarten. Now I have to figure out what to do about "Runs with Scissors."