Reinventing the IT Infrastructure Configurator, or How We Drive the Drivers

Digital transformation has become the top-of-mind concern of today’s enterprise IT industry and there is a sound reason behind it. Proliferating automation, novel data science approaches, innovative systems — these are current market drivers determining bona fide leaders. Apparently, the importance of enhancing IT processes cannot be overestimated, no matter the company profile.

Doesn’t it seem counterintuitive that lots of specialists, who have been contributing heavily to the IT industry growth, keep using all the same legacy tools for the last, well, 10–15 years? Apart from a small cohort empowered with exclusive vendor-provided tools, the best part of architects, presales agents, and IT infrastructure designers use nothing special but Excel and Visio. This results in them having to keep tons of valuable data in mind and reserve enormous calendar time for solving tedious and regular tasks.

We cannot speak for you but what we can do is share our personal experience. By “our experience” we mean Miraworks team members’ over 10-year work at the system integrators and vendors — specialists who bear all these instrument deficiencies on their backs. Drowning in the ever-lasting processes of designing IT projects and developing equipment specifications, counting man-days (reflecting our employers’ money) that could be saved and invested in way more effective areas, we decided to create a tool that could lend a helping software hand to IT professionals at system integrators and enterprises.

Ambitious and thoughtful, this project turned more challenging than we expected; we got overwhelmed with the growth ideas. But now is the time when we are ready to tell the community about our achievements.

Basically, our solution is a SaaS platform that helps design an IT infrastructure featuring equipment from different vendors, automate equipment selection and specification generation — all with compatibility check algorithms and intuitive vendor-to-vendor conversions.

Our Expenses & Investments

Code lines written: 200 000

IT equipment added: Cisco, Juniper, Huawei

Equipment and software items added: 12 838

Total time investment: 18 months

We will share with you how we sought solutions for that multitude of tasks and problems we faced and carved out our platform.

How it all started

One day, our team came up with the idea of creating a multivendor configurator to provide infrastructure engineers with a systemic tool for handling specifications, no matter the vendor. We wanted to relieve presales engineers — who had to waste hundreds and thousands of man-hours on migrating data from Excel files to vendor-specific configurators, searching for datasheets to develop specifications with the equipment from vendors that didn’t have any configuration software in place, studying licensing specifics of different manufacturers, available models and their specs. You can imagine how hard it can be, considering the multitude of vendors in the market. What the presales deps craved is syncing operations of various engineers concerned with different subjects (networking, servers, data centers, etc.) or specializing in different vendors.

Features & Development

These problems were the pillars that helped us contemplate the features of our project:

1. One-window collaboration on various equipment types and various vendors; managing project access rights. That was the first and foremost requirement.

2. The product must help create multivendor specifications even if the user only knows functional requirements and has little knowledge of those complex licensing policies. This is what predefined the function that allows selecting equipment with a questionnaire: aware of the requirements, you can create full-blown specifications and, most importantly, compare different equipment sets. Again, this feature lets you collate not just individual items but equipment sets — selected based on your requirements. We also needed to ensure that the questionnaire allows creating a specification for any vendor, and comparing solutions formed with items from different vendors. Extremely hard to develop, this function is one of the platform’s core values.

In most cases, a presales specialist knows ins and outs of one vendor’s product lines. Some can tackle two vendors, and very few engineers have considerable expertise in the equipment of three or more vendors. And such gurus may think our platform could jeopardize their status — as it somehow “equalizes” the skills of juniors and experts. But our environment is never a threat: it’s a pure opportunity that can help a gifted engineer (1) handle complicated projects and morph into an architect; (2) expand their stack of vendors whose equipment they can deal with; and (3) invest their precious time in mastering new technologies rather than delving in datasheets and compatibility matrices.

3. The system has to allow importing an existing project. Just imagine you receive a specification and have to change something or recalculate the discount. Your tool must afford friendly and simple importing of new specifications. That was our third key requirement.

4. While discussing these vital features, we thought of discount management and exporting ready-to-use specifications as valid proposals. Going further, we enriched the collaboration environment with a history of changes so every project member can see who did what to the project or specification.

We also reminded ourselves of the growing popularity of BIM techniques in construction — the industry that experiences much the same problems. In fact, a building and an IT infrastructure share many things in common: in both verticals, there is a target object, and any loss of data may result in severe problems after an engineer tries to make changes or execute the project. Our search for similar projects that tried to solve the problem delivered zero results: apparently, object engineering never had anything to do with IT infrastructure matters. Realizing that was both scary and inspiring. As we expected, the main problem lies in people’s erroneous thinking: why would we bother building a highway when we already have an old — yet hummocky, suspension-torturing — road?

We’re moving further. If we have an object model, which encapsulates both object properties and building blocks of which it is formed, why not compliment this model with visualization? This is how we came up with the concept of Topology Editor, a graphical tool that is always synced with the specification. And this interfacing is crucial, since designing a network topology and developing a project specification always flock together. Earlier, we have no tools to correlate these two parallel processes, which entailed on-the-go problems (e.g. we have redesigned the topology but forgot to update the specification, or just lost a couple of switches).

One day we decided to integrate a well-known tool, Visio, but the whole idea failed. Such a combination could not deliver on what we expected from it: what we needed was not just draw some stencils and lines connecting them, but fusing them with logical content and syncing them with equipment objects, being able to edit a stencil’s model right in the visual editor. Speaking of, just lines were not enough. We are not connecting actual equipment with abstract lines, right? Instead, we use cables, sometimes we employ transceivers — selecting of which is affected by the cable length, type, bandwidth, etc. And since it was critical that we minimized the errors at that very phase, we decided to imbue those connection lines with real-life characteristics. With all this in mind, we conceived the Topology Editor that would offer automatic adding of transceivers based on the connection line properties, still caring about consistency and compatibility between equipment items from different vendors.

Unfortunately, we found out that there were very few ready graphical libraries with comprehensive documentation. On the other hand, diving into developing a visualization engine from scratch would lead us to a blind alley; therefore, we went with GoJS. This library has its nuances and specifics, but there should be a dedicated text for it.

A noteworthy and special product started taking shape, and the cherry on top — our last requirement — was the function that would allow converting equipment sets between different vendors; even if such sets were not created through a questionnaire. Naturally, if we know equipment properties, we can generate similar specifications, rebuilding the equipment set’s aggregate characteristics from its parts, and use them as inputs for generating a new set.

Our one-year-long development phase was initiated. What problems we faced will be the subject of our next text. Want to see what we turned out ideas into? Jump here

P.S. We are currently adapting the system for non-networking products: servers, data centers, UPS devices, and software — to become a multivendor and multiproduct platform.

This article was originally published on Medium