Blansh
Technologies
Targeted applications:
Broadband Network System Management
Retail Chain and Warehouse System Management
Manufacturing System Management
Our philosophy:
Simplicity
Modularity
Completeness of design and life cycle
Right tools
Portability
List of tasks we have done for your project
Partnership opportunity - marketing
Intranet-based Management System Framework documentation (these pages require log-in authorization from Blansh Technologies):
GUI Managed Elements Status Tree
Broadband Network Control Reference Implementation
Broadband Network Control : Modem Simulator
Simplicity
In the times of explosion of digital networks it is hard to keep up with the newest technologies. Especially if you are at the early stage of building a networked management system. Thousands of the off-shelf software tools offered to ease the pain of the growth more often replaces one hardship with another one: learning to use and incorporate tools into the system, finding a respective contractor who knows a new tool on the market and is willing to do a job for you for the amount you are capable to offer, to restructure all your initial design to accommodate a new tool, to replace your communication protocols or generate new message protocols from your existing elements so that a new tool could <understand> , etc...
It is not easy to estimate how much will it cost you to incorporate a wonderful CORBA package or a Network Management OSI tool or a powerful RDBMS? How does an off-shelf Web-based Database browser fit into your N-tier application?
On another hand do you always need those wonderful off-shelf products? A solution could be much simpler or if you do, then how much will it cost to incorporate a third party tool in your system in terms of time/staff/money?
Modularity
Based on our 24 year experience in the telecom, embedded systems and distributed applications, we at Blansh Technologies convinced that most of today networked Web-based distributed systems need a respectively simple elements of architecture ( consider them as a Lego blocks ) which fit most of the needs and still be flexible and customizable enough to merge with proprietary hardware, interfaces and databases. Even a typical internet distributed system architecture evolved into the same familiar patterns despite all the diversity.
We developed a framework to be used as a template for the most of the Web-based control systems and distributed applications . It contains complete servers, software packages and system elements for all the tasks which we found to be either mandatory or desirable in any such development.
Completeness
of design and life cycle
Many long term developers have known examples of the failed projects when millions of dollars were lost as a result of missing or incomplete elements of the design: missing scenarios, daemons or processes for operations synchronization. Same applies to the life cycle completeness (see below).
Also experience shows that a completeness of design is that <magic> which reduces number of needed third-party tools and, therefore makes overall project simpler (see discussion on the simplicity section). If the initial design ( overall system's framework ) is complete, the remaining stages of development are simpler.
As above, incomplete life cycle may lead to the failure. The most crucial to the project are missing or incomplete earlier stages. Following tasks are an example of what have to be addressed:
- When and in which order servers/processes are to be integrated and tested. Should any tools be developed for testing a server or a daemon?
- Should the Web applets and servlet files be tested before or after they are deployed? Does it make any difference?
- Do you need a back end ( Controlled modem ) simulator for testing or just use a real hardware instead ?
Right
tools
To do a job right you need right tools. Sounds like a typical heritage passed from the father to the son. In the telecom industry this is even harder. Our principles are based on the following:
- If a tool is extensively custom-friendly but intended for solving a narrow problem, no good because you will need many of such tools for different tasks and all come with a tag: learning to use it and each tool changes your system one way or another.
- if a tool is too flexible to do just about anything ( extreme example, a C language, sorry my fellow developers :=)) - it is not efficient enough for today fast growing market. You will spend too much time on developing the trivial things with it (and debugging your code too).
As it becomes obvious from the above, it is not easy task to find a compromise, this needs a lot of working experience with variety of the tools of both types.
Portability
Although we prefer our chosen platform, still owners of the developed systems sometimes have their preferences of servers, client computers and browsers. This adds another requirement to choosing the tools : they have to be cross-platform portable. This criteria adds another advantage : freedom in choosing different vendor supplied tools. Example: if we choose Microsoft proprietary tool for developing Java GUI , we would end up with final code which often uses Microsoft specific libraries which will not work on some Unix based browsers. On another hand Java tools developed by Sun corporation guarantee to be accepted by all Microsoft and non-Microsoft platforms .
