Paint Yourself Into The Corner pattern

Here's how it works. Typically, a new CTO or CIO gets hired/promoted and after a couple of days declares that, "We are now an 'X' technology/platform shop."

I'm going to start calling this the Paint Yourself Into The Corner pattern. You read it here, first. This is similar to the "Fire, Ready, Aim" pattern. It starts out with a CTO (or CIO) declaring that a certain technology or platform is the new standard before understanding what all of the problems are. This decision is usually made on the alleged cost savings to be achieve through standardization, alleged efficiencies to be achieved by having similarly skilled staff in a matrix organization and is largely based on the CTO/CIOs own past skill set (familiarity). Sound stupid? Well, it is. However, why do I see it happening all the time? I've seen people put more thought into what kind of car they want to buy than the time they spend figuring out what types of technology are best for their business.

Enterprise, or any other kind of "technical" architecture is not all about technology. CTOs in particular often forget this. Architecture is about devising manageable solutions that will actually get used to solve specific business problems. It's not about "simplifying" the toolset to make the tools more manageable! Some of these solutions will be very complex but, complexity can be managed. Managing complexity can also be applied to the toolbox.

Tired of The Same Old CRUD?

One of our customers has a very large robotic storage system and we have been asked to propose a new control system. This meant I needed to do some research and dust off some very old skills. I have always seen robots and software agents as cousins. As I was doing some research, a few patterns started to emerge ...

The first time I had a chance to program (virtual) robots was back on an Apple II with a game called Robot Wars. That may seem pretty humorous but, it taught some difficult lessons: real-time systems, event queues, interrupts, and programming on vastly resource-constrained systems. The developer only had 256 lines of code in which to build their virtual robot. Little did I know at the time this was actually a reasonable training ground for learning how to write embedded systems.

Then, several years later after the PC was invented, Crobots was released, that opened up some more possibilities but robots were still limited to 1000 instructions. There were legions of budding developers and engineers at campuses around the world designing virtual battle-bots.

C++robots broke that 1000 instruction barrier, 10 years later. I don't know much about the evolution of the Crobot genealogy because by the time C++robots came along, I had picked up this new language called Java.

Since we just love re-inventing the wheel robot in this industry, a decade after Crobots some Java devs at IBM were helpint to create Robocode as a way to teach the Java programming language. This turned out to be extremely popular and even spawned international robot leagues. Robocode grew to be very sophisticated, very quickly, including technologies such as swarm intelligence, blackboards and even genetic algorithms. This is very similar to the types of technologies being embedded into software agents for tasks like remote monitoring and supply-chain optimization.

In what appears to be more deja vu, Microsoft has recently released RoboChamps featuring their Concurrency and Coordination Runtime plus the Decentralized Software Services. Why is this important, you ask? Well, most importantly, it's a way to learn about concurrency and distributed systems without killing anybody! Mistakes are safely made in the virtual arena. It also shows a degree of maturity in the .Net platform if it can now be used to solve some of the more difficult computing problems out there.

Anyhow, back to the patterns. Aside from the obvious (4 virtual robot games), I delved into the bios of the authors of RoboCode and RoboChamps. The source of the patterns quickly emerged. All of the authors have substantial and impressive backgrounds in distributed systems, autonomic computing, software factories and a bit of AI. What are some of the major patterns here?

1) Programming robots is a fun way to learn a new programming language
2) Robotics is hard work compared to a web-app
3) Robots have contracts and SLAs with their operating envioronments
4) Robots are autonomous
5) Robots can be employed in co-ordination with other robots to perform more complex functions (loosely-coupled, composition, aggregated processes)
6) Robots can work in parallel (linear scalability)
7) Robots are to a large degree, event-driven

Hmm ... this smells a lot like a service in a SOA, doesn't it?