The ArenaCore platform provides a powerful product definition capability in which composable digital products can be brought to life as design time objects for consumption either by yourself and/or other individuals and organisations on the platform (according to access control rules that are under your management).
Alternately, many users / organisations will only wish to use the ArenaCore diagrammatic design canvas for their own design purposes, in turn taking advantage of product definitions created by others.
A key role of the platform therefore is to facilitate constructive interaction as is desired between those who are providing specific (and evolving) product set definitions, and those who wish to utilise those product sets within their design and management activities (and of their customers).
Logical Resource Management
The following screenshot shows an ArenaCore design session in which a set of logical resources are being edited (logical resources can be application modules, services, VMs, containers, storage volumes, network elements, etc):
The items seen in the diagram above are some example instances of various classes of logical resource product definitions. For example, product definitions may represent popular ICT or cloud type offerings, and/or customised infrastructure and service elements that have been developed on an internal basis within your own (or another) organisation. Commonly used commercial / open source elements may be freely associated with internally developed items providing that any associated compatibility rules are satisfied.
Product definitions will continue to be created on the ArenaCore platform that represent various manufacturer implementations of well-known ICT / cloud system elements. These are made available for use via publicly accessible Product Catalogs.
Within the ArenaCore design canvas environment, the product configuration UI forms, business logic and configuration attributes supported on any type of logical product definition can be created and customised by ArenaCore users!
The example screen below shows the result of a user double-clicking a ‘Gateway’ node in the previously shown diagram. As a result, a popup dialog panel has appeared above the design canvas surface (in addition to details that appear on the left hand side even for a single click selection).
Note that product specific attributes presented in these screen regions and how they function is not managed by ArenaCore itself:
The power of the ArenaCore product definition approach is that you as the developer of the product definition are in control of the UI and business logic elements that determine what attributes are presented, collected and processed during design activities!
Containment and Connection Concepts
Logical (and physical) resources can flexibly contain, be contained and be connected to other logical resources according to what are known as ‘Resource Roles’. These are described as part of the ArenaCore product definition process, and can be hierarchical (supporting backward compatibility, for example).
Resource Roles can support compatibility across product ranges, vendors & manufacturers.
Similarly as for product configuration UI forms, Resource Roles can be augmented with custom user defined logic in order to support context specific placement & compatibility rules!
Physical Resource Management
Management of physical equipment resource elements is a critical activity that is relevant for many large organisations even if they have moved off any remaining legacy ICT platforms. This is evidenced by the focus placed currently on ‘Hybrid Cloud’, which includes the important sub-class of ‘Private Cloud’ infrastructure.
The following screenshot shows a session in which the external and internal disk drive bays of a physical storage chassis are being edited. The storage chassis is itself located in a rack containing other compute, network, storage and power supply devices.
In this case the units shown are Open Compute type systems – hence the ability to fit a total of five LFF drives horizontally within the width of the rack unit.
The following screenshot shows a design session in which the internal CPU, memory, riser and mezzanine slots of a physical compute node are being edited:
Note that most complex chassis items (servers, storage arrays, switches etc) will usually have a detailed base ‘Plan’ dialog view (such as can be seen above) that enables internal items to be manipulated. Multiple child items (e.g. compute nodes) within each chassis may have their own Plan views.
Multiple plan views may be open simultaneously, enabling complex internal structures to be moved visually between machines (e.g. a drive bay containing drives, or a riser card containing adapter cards).
ArenaCore supports definition of ‘standard configurations’ at the Riser, Bay, Chassis and Rack level. This enables definition for example of standard configured server products or even ‘blocks’ of a number of pre-structured systems across multiple rack units, and from there up to fully populated racks and multiple racks – all defined as a single product.
As for all other areas of ICT & cloud management, management of Physical Resources is an ever-evolving domain. ArenaCore supports this evolution through structured inventory lifecycle management, enabling increasingly automated hardware management processes during the initial implementation, mid-life enhancement, fault resolution and decommissioning phases.
The Logical and Physical design screens shown above are relatively easy to use in terms of drag and drop type operations originating from pre-built Product Catalogs. For many designers and architects the ArenaCore page level design canvas is perhaps the only level of complexity that they will need or want to experience.
For those who are involved in the product definition process, it is necessary to travel more deeply into the Product Specification and Product Catalog definition layers of ArenaCore. This is all covered in more depth across other documents located on this community site.
In order to continue with this initial introduction however, please continue to the Going Deeper section.