The SDx Ecosystem

The term ‘Software Defined Anything’ (SDx) can be defined as the domain encompassing the SDN, SDS, and SDDC systems. Traditional systems have tightly coupled proprietary hardware and software, whereas a software defined system is based on abstraction – hardware and software is separated into a data plane, and a control plane, respectively. There are protocols defined for how these two components talk to each other, for example, Openflow. Virtualization of systems is a key driver for the software defined systems. A hypervisor layer acts as a mediator between the guest OS and the hardware and host OS, leading to a flexible and scalable architecture.

An SDx system is deployed in a data center and applies certain services to the data center. It lets you configure virtual services, appliances, networks, storages, and servers.

In a traditional system there are a limited number of configurations, like users, organizations and related forms. But in an SDx system, the number of entities and configurations are too numerous. Managing an SDx system involves tracking, monitoring, and configuring services (in 100’s), servers (1000’s of virtual machines), connections, and logging of all services for many organizations.  It has to be built to handle scale and complexity. Using the correct design strategy to simplify all this for users is a challenge.

The main advantages of SDx are scalability and cost effectiveness. You can add more virtual resources as needed (for handling requests or processing data). Their interaction is much simpler than in traditional resources. Also, separate evolution and management of hardware and software becomes possible.  However, the number of parts makes such systems very complex. When designing the management layer for this, simplification becomes a key factor.

A Management Model for SDx

Monitoring and managing SDx systems is critical due to size, scale, and dependencies. A good management model can come to the rescue when handling such complexity and scale.

The management model for the virtual infrastructure of SDx systems follows the FCAPS framework (Fault, Configuration, Administration, Performance, Security).clarice_SDN_UX

Simplification Process and Strategies  for the Management Layer

When creating the management layer for SDx, there is a risk of creating a UX layer that parallels the complexity of the underlying domain. When creating the SDx monitoring system, the primary need is to understand the complexity of the domain and  the specific product functionality, and present it in the most helpful way.

The design has to be in keeping with the domain characteristics, and give a holistic view of the entities being monitored and their inter-relationships.

We designed and developed a service and UI layer for a SDN management product that presented all the typical challenges of such a system.

clarice_FCAPS_SDN3

Some of the design  and development principles we used are outlined here:

Mental Models: Users of this product already had experience in running  networks and had built mental models of the underlying system. Our new design could not break the models already present in their minds, and we had to align our designs with them.  At the same time, if the existing mapping was too complex, the design had to stop deriving from existing  mental models.

‘Inside Out’ Design: To deal with the complexity, we identified high-level entities while creating the Information Architecture, and began the design process with their key relationships in mind. We started from the simple, and created detailed screens progressively. Information was also presented in levels, with progressive drill-downs.

Data-Action-Users Model: We analysed the domain using a data-action-users model, and used this as the basis for design. We came up with a design and navigation that kept these three entities in coherence and coordination. For example, in a server monitoring screen, we thought about what actions a user would want to take and made the actions readily available. This provided coherence and clarity to users while navigating through the product.

Templates and Defaults: As there were too many configuration parameters associated with any user task, we analysed and pre-fed the defaults for them. Wherever possible, templates were created. This improved speed of configuration and learnability for new users.

Innovative Visualizations: Visualizations offered a significant challenge for UI development. We had to  show complex information in a simplified way. For example, complex, numerous, and dynamic connections between organizations, servers, and networks had to be summarized in one visual.

Automating Repeated Blocks: In order to speed up UI development, we invested in a code generation engine that built repetitive blocks.

Scalability and Performance: Caching was used extensively to increase UI performance and scalability. Potential hot spots were identified and the responses were cached in a database. The caches were kept updated with various built-in mechanisms.

Component Based Design: We took a component based approach for both, UX design and development. This led to re-usability, repeatability, scalability, and allowed us to tackle complexity in a gradual manner.

In Closing

The  proven principles of UX design and UI technologies can be applied to any emerging domain like SDx with excellent effectiveness. They have to go hand-in-hand with understanding the domain and the users of the system, identifying the real problems, and prioritizing them.

Applying design innovations and using a suitable technology approach to match leads to a user experience that delights end users.

facebooktwittergoogle_plusredditlinkedinby feather

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>