Note: name is still in progress, but I like it for now IBMimmix for the IBMi module for immix.
So, IBMimmix is really coming together. It currently integrates entirely with an existing IBMi authentication and security structure. This means management of immix access controls is as simple as adding existing IBMi users to proper groups; such as IMXUSR or IMXADM. We have a preliminary RPG report display and saving structure in place, and should have the ability to interact with spooled documents and printers right within immix, making it a lot easier to get PDFs or administer this area of immix.
Other features are coming which will allow for rapid integration of existing IBMi programs into a web environment. If you program on IBMi, you should keep your eyes on this blog for screenshots and details. This could make your life a lot easier with creating attractive and useful frontend displays and outputs for your clients without sacrificing all of the existing green screen work.
Some future features will be building a AERIS IBMi Appsuite into the framework so users of the advanced accounting platform will be able to interact with it using the immix interface, opening up a whole new world for those users.
A big problem I’ve encountered in business is the widening chasm between sales, marketing and IBM-style management folks and the new group of technical experts coming up. I’ve been in rooms where the marketing people have great ideas about a product and the technical people simply cannot understand or comprehend what they are saying or, worse, why it is a good methodology to sell a product. To them, it’s the technical structure of the product, the spreadsheets and data, not the human or “mushy” interaction with the wetware on the other side.
There are times I wonder if part of the reason techies spend so much time on futurism is the hope that by removing the wetware entirely, the system becomes much simpler.
However, it goes the other way around. Techies will describe what they are doing in terms that to them are simple, but to the sales and marketing guys are essentially another language. Many smart sales and management folks will usually retort with “ok, let’s pretend I’m an idiot, please explain this to me in language I understand.” I surprisingly polite, if somewhat demeaning way to ask for clarification. The issue though is when the techie “dumbs it down,” they resort to either simpler technological terminology, defeating the whole point of why the prototype they built is cool, or they change the terminology to a different field that they have less respect for (This is more common than you’d think.)
I confess, I’ve done both of the above. I’ve put on my sales, marketing and management cap and found it excruciatingly difficult to explain to a techie why the direction they are going won’t work. Why to sell the produce we need to do something more palatable, more refined. Why, at the end of the day, we need to have a product that actually works rather than the potential for an awesome product eventually. This is something I want to fix eventually, since if I put on my techie hat, I fall into the same holes as them. (Whoo, that’s cool, do that, don’t worry if it doesn’t work…)
I’ve put on my techie hat, went into a sales meeting and found myself discussing the more complex points of software engineering on a clustered system to an individual who only wanted to know why the algorithms on mutual funds were taking longer to calculate than he wanted.
Yet, ironically I’ve found when I’m not the one communicating, it has put me into an interesting situation. I can read over a paper on advanced clustering algorithms and explain to a manager of a small company why this is useful for their primary software product. I’ve also found myself in a technical development meeting explaining to techies that the sales manager is not demanding an entire rewrite, but simply a new field on a single screen.
So, while this is important and I enjoy playing this role. I realized that this is ironically what immix has become. The internet is full of 100s of APIs and organizations have likely thousands if not millions of different systems that have their own DBs, no APIs, no clean way to link to the old database and combine it with new systems in a clean fashion.
While more standardization of APIs is useful, that doesn’t give many businesses any ROI since they don’t want to throw out all of their existing work.
immix has become for many organizations an interesting middle man. It allows the various systems to communicate to it in their own way, and then through module building communicates what is necessary to other systems (including the nefarious wetware I mentioned above.)
It makes the software and hardware talk together. It creates a social network for humans, hardware and software.
The realization I had is that over the last 5 years we’ve encapsulated in software what I’ve been doing in business for a long time. we’ve built a technical translation system that allows normally incompatible systems to understand what they are doing and make more intelligent solutions, and this is important. The internet is overwhelmed with people talking to the wind, and many of the time with good ideas when you can understand the underlying logic. Adding things to the mix will just make it even more confusing, adding noise and not signal. Not because there isn’t signal, but because the things are all communicating slightly differently.
However, by having a centralizing IoT framework that repolarizes those signals all into the same frame, you can actually start to make sense of it all.
I’ve always felt like a jack of all trades because of my varied knowledge and personally worried that it put me at a disadvantage as I needed to read so much more to get the depth I wanted in all of the fields.
However, now it gives me an advantage because I can talk the various languages needed to build good businesses, and I can see how to build a framework that does the same thing electronically.
Goal for platforms for immix Release -1.0 to support.
Windows 2008R2 Server and up (WAMP and possibly WIMP) Already requests for this. We are definitely willing to do it with AMP, but nervous about doing it IMP and most definitely can’t do a fully .NET version without some more funding.
CentOS LAMP (Will build RPM for this) This should be as easy as Ubuntu, really.
Not sure if I’m going to bother trying to get other Linux Distros. Any suggestions on this front?
Mac OS X server , Not sure how hard this will be, but I can see having the ability to install it locally to work with to be wise. As well as use it as a “node” immix to send information to a central server.
IBMi Server (Will build SAVF for this) As well as create a new IBMi useful documentation repository I think. There is a lot of missing or diverse docs online that this could be immensely helpful on. Especially as I learn more about it. Personally, I like this since this gives an enterprise way to get immix right onto accounting and major operational machines without too big of an issue. Biggest problem we have right now on this is mongodb is used for some advanced features. Debating having it not available on IBMi, but looking at CouchDB and other alternatives to make this work better. If we get this running, there will be automatically a major accounting package that will be incorporated into immix, so that’s pretty spiffy.
Raspberry PI (This one is obvious, especially with the secure channels between immices working so well. This makes it easy to network a ton of separate devices without having to go the hub and spoke method.) When this is done, I hope to have basic modules in place so you can use it control heating, track baby movements, etc. The usual.
When Release-1.0 is out, this should be a solid list of supported hardware. Improvements will be impressive as we push 1.1 out, since it includes a fully operational live chat environment.
Future goals for immix clients (not server end)
Full Android, iPhone / iPad web support for back end. This is already in place in in the dev path, and we simply need to push it live after Release-1.0
iPhone native app, this will allow you to connect to all of your immix servers and collate them in a general stream, as well as push items from your phone back to the servers, if you want to.
Possibility of having immix clients have same functionality as servers with the ability to interact with each other without the need for a central server.
Should be interesting in the next few months. Especially as Steve Godin gets the formal documentation and knowledge base in place. I really am hoping to be able to get a few more external developers playing around with this and interacting with the API. As well, the code base should get documented enough to open up the possibility of having 2.0 built on a different structural code base (not PHP). We’ll see though.
Plus, there’s the whole opening it up eventually for other people to log into the central immix and play around. However, that’s more of a for fun internet of things idea than anything else.