As part of a casual conversation a few weeks ago I started thinking about how I’d go about programming a large scale distributed AI. In the scenario being discussed the AI would be running the combat simulations for a starship. This was one of these, “How would you create this piece of SciFi tech?” conversations.

Now let me start with the caveat that I’m not an AI specialist. I toyed around in the space some years ago, but there are certainly those in the world who know much more about this than I. In fact what I’m going to talk about has almost certainly been detailed out in someones masters or doctoral thesis, and I have no illusions that this is anything original.

So with all of the disclaimers out of the way, lets jump in and take a look at what this type of SOA/NN AI might look like. This will be at a high level and really talk more about commonalities in order to intertwine the two concepts. Afterwards I’ll delve into some possibilities of why we might want to create such a beast.

I think that the number one thing that even makes this a possibility is the autonomous principle of SOA. Each node of a SOA should encapsulate all of it’s logic and be call-able for a single function/purpose. This simple concept can be seen in the node of a neural network. In a neural network a single node takes an input, analyzes the data and passes on an output to the next node. Once the output is passed on, the node is completed. Now there are some differences. For example, it’s generally expected that a node in the higher levels of a SOA may need to call into the lower level services in order to complete it’s function. Think about a piece of business logic that needs to call down into the application layers of one or more applications in order to get the data needed for the operation. This isn’t the norm for a neural network node, which instead expects that all data needed for the operation be passed in as inputs. While there are obviously other differences let’s look as one possible way to bridge these two concepts.

Now in order to bridge some of the gaps between the two, what if we created a series of services that lived behind our normal SOA services? This extra dimension of our SOA would serve to facilitate more organic processing. In practice this is just a special implementation of the synapses in an artificial Neural Network. The purpose of which is to use a set of weighted parameters in order to pass the outputs of one service (node) to the next in the chain. Now, at first I had thought of this as just a more detailed orchestration layer, since one of it’s major jobs would be to usher the inquiry through the process, but then I realized that it didn’t really act the same as a SOA orchestration. An orchestration sits above the worker layers of the SOA, and calls down into it. What I needed was something that filled the gaps between the lower level services.

Another factor that would probably be needed, are some specialty services that might wrap around normal SOA services in order to plug them into our synapses properly. Think of it as a hidden layer of dark matter that allows our universe to balance. In fact that’s exactly what I’m going to call it, the “dark matter layer.”

Now at this point hopefully I’ve painted a picture that allows you to accept the premise of an artificial Neural Network that can be based on an existing SOA. I may explore more details of the technology in future posts, but for now I’d like to talk about why we’d ever consider even doing this.

So, we have our existing SOA, and we’ve setup a framework to attach an artificial Neural Network onto it. What could we do with something like this?

The most common use might be to create predictive models based on real time data derived from the corporate SOA. Using AI for predictive modeling is not a new concept by any means. However, these are traditionally programs the chunk through extremely large amounts of data stored in a data-warehouses, and are designed to track trends over longer periods of time such as months and years. What if instead we looked for predictions of what a workload might look like over the next few hours, based on realtime data. An AI routine like this might be running in the background all the time, constantly updating the predictive model.

With the above node in place we might then create another AI system that would be a consumer of this model ,and would take some form of action based on it’s results. For example a complex routing system might utilize the predictive model in order to determine the most efficient way to route work. Now instead of a simplistic First In First Out (FIFO) work queue, we now have a much more dynamic queue, that will assign work based on the predictive model and perhaps job priority. The assessment of job priority might in and of itself be a neural network that is basing it’s judgements on realtime data.

While this might not be a good approach for all situations, it is a viable way of thinking about enterprise systems and SOA’s for any company that wants to not only be able to react to changing situations quickly, but wants to have an infrastructure that can react for them.

Thanks for indulging on this one, and as always, keep thinking malignant thoughts.

OR… question = (2_architect | !2_architect);

I just posted to a thread on linked in about whether or not you should blow out a full architecture on a project to let the design evolve over time. I’m reposting and expanding may response here because I think there are some important elements to the topic worth consideration.

This is a topic that I’ve seen pop up again and again since I’ve started doing Agile.

The basic premise is that if you’re using sound design principals/patterns, and have a solid understanding of what the customer wants, (Remember you’ve gone through release planning with the customer, and have hopefully developed a solid product backlog) then you can allow the architecture to evolve iteration after iteration. Using techniques, such as refactoring and strangulation, you can keep the code base moving forward without ripping things out and starting over.

At this point let me point you to an article that Martin Fowler wrote back in 2003 called, “Who Needs an Architect?” (I told you this debate has been going on for a while.) In the article he describes the role of the architect within an agile project, and even has a section towards the end called, “Getting rid of software architecture.” Whether you agree with him or not, it is an interesting read, and one of the best arguments I’ve ever heard for not doing a lot of architecture up front.

Personally I always try to do as little as I can get way with up front, in order to allow for future scenarios I can’t see today. I always have an over-arching architecture in my head, but I don’t want to make it real until I need to. That way if new requirements pop up later, the project has not backed itself into a corner that might cause major overhaul. “What do you mean we’re going to deploy all the services as workers in the cloud? We just spent two weeks setting up an application server farm!” is something I hope never to hear because wrote something down on paper too soon.

When I look at the times where I “Over-Architected” a solution, it was usually because I had to have the full architecture documented before the team could write code. As a consultant I don’t always get to do things my way, and this includes the use of Agile. In these situations it can be easy to overthink things, as there tends to be pressure to “Get it right up front,” and “Account for all eventualities.” In my humble opinion this is one of the top reasons projects fail. In cases where requirements are simple, or very well defined, it’s ok, but oftentimes customers don’t really know what they want up front. A good indicator of this is when you start getting conflicting requirements.

If you’ll allow me the metaphor, I like to think of the software architecture as a collaborative art installation, and the role of the architect as one more of chief artist. As chief artist I select the medium we’ll work in, wood, canvas, marble, etc. If we’re working on canvas I will usually step in and take the requirements of the customer and begin to paint in the larger areas. I may lay down a patch of azure across the top of the canvas for the sky, and then work with the other artists to begin painting clouds, birds, balloons, or whatever else is needed. As we reach stories that involve a landscape or ocean, I may decide the placement, size and/or shape. Again blocking the pieces in, then working with the team to fill in the detail.

Now there is a place where this metaphor begins to break down for me, and that is in regards to the customer. In our metaphor the customer is exactly that, a customer, and our installation piece begins to be a commissioned piece of art. The reason that this bothers me is that commissioned works of art tend to be seen as somehow lacking in quality in comparison to art created for the sake of the artist’s own vision. At it’s worst I think this type of commissioned art can be equated to purchasing a painting to hang in your living room that matches your couch and curtains. In our tech metaphor this might be buying off the shelf software, or utilizing inexpensive labor. You tell them to draw a line, they’ll draw a line, and it will be mostly straight. While there is certainly a place for this type of art it leaves me wanting more. So lets see if we can’t fix our metaphor to make it more appealing.

So what if our customer is more than our customer? So what if instead of our band of artists creating just any type of art, we are instead are focused on creating sequential art? We can still keep our artistic mediums open. For example instead of sequential images that tell a story we might install a series of life-sized dioramas along a park trail that reveal the story. By making this simple change we can now put our customer in the role of writer. Our customer has now magically been transformed from patron and bill payer to an integral and active member of the artistic team. Now we’ve got a metaphor we can really work with, and in true agile fashion we’ve gotten there through iteration and a desire to keep our customer integrated with the team.

Next time I’ll explore the metaphor further and see if we can’t iterate against it even further.

Until then, keep thinking malignant thoughts.