I keep seeing questions/requests around the NSO GUI. We have a very small GUI development team, and I would like to solicit input from this forum on how we can get maximum impact.
How do we think GUI impacts our sales? Our theory so far has been that our users don’t and wouldn’t use an NSO GUI for order entry. Can we validate that theory? Do we know of any NSO customers that don’t use some other system in front of NSO? How would such a customer be characterised? Certain size? Certain segment?
We could address our effort towards a number of audiences, e.g.
IMHO, I don’t think a self-service portal should interface with NSO – this scenario would require order management functionality, but I’d be interested in your views on this.
We have a small SP in Israel that purchased NSO last year and, at least for the time being, intends to use it directly.
The current GUI cannot really be used, as some basic functionality is not really working (at least the last time I checked).
For example, the topic that was discussed few times here before: If you have a yang model with leafrefs to device names and ports on these devices – the list of interfaces according to the selected device is not being populated, so the user cannot see a drop-down list in a manner similar to ncs_cli.
I think similar issues exist with leaves/containers conditioned by when-statements, but am not sure about it.
Anyway, I think that some small customers might want to use the GUI – it doesn’t have to be pretty, but I think they might want it to be able to provide the basic stuff that ncs_cli provides for service activation.
I also think that during pre-sale / poc we should be cautious not to raise false hope that the provided gui can provide service-activation capabilities similar to the ones that the cli provides.
Telstra Ops and Cisco IT has requested a useful NSO Web UI for templates
*Real* users, hurray, not “just” Cisco sales
Daniels team put something together to get them through a POC:
In my opinion, the best return for investment would be to improve the auto-generated GUI. This will immensely help pre-sales. With pre-sales, there is a certain audience type that only see the value-proposition if it is communicated to them via some decent GUI.
It can also help post-sales admin/operators for small and/or initial installations - at times customers (network engineers) are looking for an out-of-box portal. That is after they finish building the service-packages, they would like to try it out in production on a small part of their network. Building just the service-packages is a steep learning curve for them and then having to build a useable portal on top can be a big turn-off. Once they have successfully done initial deployment and want to expand, the organisation would be more willing to invest in a full blown portal solution.
I’m not convinced that “Example external GUI portal” would be of much value. There is a whole web-app industry out there, no point re-inventing the wheel.
Some of the line-items I’d like to be explored for improvement to the auto-generated GUI:
Agree with Bilal on auto-generated GUI being most impactful. Additional points to add:
If by “example external GUI portal” you mean a portal that is manually build to demonstrate one specific use case, this is certainly very useful to demonstrate that particular use case, but it might need to be modified to demonstrate other use cases.
Hope this helps.
I’ve been contemplating my response today. But no need as the ones below clearly capture our Advanced Services Mobility needs as well;
Working Gui to do POC, testing of new developed services, introduction of NSO to the customers without need for custom NB portal.
+1 for using GUI for POC’s and demo’s to customers who don’t have a NB portal.
It would be nice to have a stable GUI with enhanced look & feel and proper error handling with user-friendly messages.
I think it depends what you’re trying to sell. If you’re trying to sell NSO as a platform, then the generic operationally-focused GUI is fine. It’s a UI for NSO.
However, if you’re trying to sell (i.e. demonstrate or PoC) a very specific use case, then I think that a very lean and tailored UI is required. This will allow the customer to clearly see how NSO enables them to solve the specific operational issues or business outcomes they desire. Disclaimer: this is the approach that my team has taken in the construction of a PoC Web UI for NSO in APJ, so I am biased.
Our approach was presented at the previous SEVT (at the 1:21 mark): http://vtshare.cisco.com/p.jsp?i=2484
A video demonstration of our Layer 3 VPN use case portal for NSO: https://cisco.box.com/s/srcgrgbfi55rphxcijplnvihme1bp9dd
We are currently working as part of the global Agile Development Team in GSP to create a common portal framework for GSP pre-sales PoC’s and demonstrations.
.:|:.:|:. Richard Wade
Thanks for the link and great work on a portal framework.
One important question: Why are you using the REST API and not JSON-RPC or NETCONF? I worked with the EMEA innovation edge on a couple of project where we used NETCONF in Java (Tail-f open-sourced the client code) and it works great. With NETCONF you win transaction support and notifications. Notifications are a requirement when you use reactive fastmap.
My view is that we need to continue with the two side strategy:
- Best in class Self-rendered GUI with the target to be a tool for developers and operations (although the latest is a longer-term goal).
- Best in class JSON-RPC API for custom portals such as the Itential toolbox.
Now, I think the BU should think about a couple of areas:
1) We need to make usability a top priority. There are plenty of consulting firms that could help our developers to be way more user-friendly. I asked once, “why our GUI lands in the device-group page”? These sort of questions have very precise answers when you have a user-centric development strategy. Kalyan mentioned in an internal email that the new Juniper Orchestrator invested more than $1M in the GUI with a contract with a specialized user-experience company, that is the new competition we are against.
2) The issue with the examples' GUI is that it represents an “exception”. It is a modification of the NSO GUI that we cannot perform for other projects as we need an external portal to do so. As an exception, it is hard to set the correct expectations to the customer on what they can/cannot do.
I recently did a Proof of Concept for LG in which we automatically turned up internet and VPN services on ASR1k and ISR4k from a customer portal.
We used Itential Pronghorn as GUI on top of NSO. http://www.itential.com/oss/
It has auto-generated GUI (update yang wil automatically update the form) but can also federate information from multiple sources (IPAM, CPE shipping, Billing) before triggering NSO to orchestrate a service.
If information from multiple departments is required, it will also support workflow templates with work-queues in the operator portal.
The customer was very impressed and me as well.
We've captured the screens while executing the PoC and I'm working on creating a video showing the provisioning process end-2-end.
When it's done I plan to upload it internally.
Met vriendelijke groet / With kind regard,
Dirk-Jan van Helmond
Thanks everybody for your input – keep it coming.
Roque – see below
From: "Roque Gagliano (rogaglia)" <firstname.lastname@example.org> Date: Wednesday, 7 September 2016 at 08:25 To: "Giri Venugopal (givenugo)" <email@example.com>, "Julie Ann Connary (jconnary)" <firstname.lastname@example.org>, "Khay Kid Chow (khchow)" <email@example.com>, "Bilal Alam (balam)" <firstname.lastname@example.org>, "Yftach Herzog (yfherzog)" <email@example.com>, Kjetil Rossavik <firstname.lastname@example.org>, "service_orchestration(mailer list)" <email@example.com> Subject: Re: NSO GUI requirements
When the competition is a management system with a flashy interface, an auto generated UI will never be good enough. It’s cumbersome and easier to navigate those features through the CLI.
I would suggest we make it easier to build custom UIs by creating and documenting a framework and providing prebuilt widgets which can be reused an extended. Example widgets could be for topology, device views, VNFs, service chains, resource pools, alarms, rollbacks, plan view etc. In the same way we have a library of NEDs, we could have a library of widgets.
It would also be good to have something like the Ui Designer from Prime Fulfilment which is a graphical form designer. This means we can choose which items to display, in what order, the kind of input box to use etc. These forms are quick to build, and will always look better than something auto generated from the underlying yang model.
With this in place it gives us something credible to sell rather than saying it’s a throw away demo UI which has been built for a particular POC. We can say it’s a toolkit / library which can be bought and customised for production use. And where the customer is not interested in a UI, it will still enhance any demo where we say we are simulating / stubbing the system which would sit northbound of NSO i.e. portal / OSS / BSS.
In followup to this question of NSO API choice, could the NSO team comment as to what they would recommend as the “best API” to adopt given current NSO development roadmap? To be specific, this is for the development of a Web UI to present specific use cases based on NSO service models and workflow.
We currently use REST, but have hit some limitations when it comes to closer interaction with NSO for near real-time updates on device/config status. We have spoken with the EMEAR ADT who are using NETCONF, so are considering moving to that API. However, it would be good to get guidance from the NSO team with regard to future development plans, richness of the available APIs etc.
.:|:.:|:. Richard Wade
The simple answer is simplicity and it provides the capabilities we’ve needed so far. The team’s function is to provide rapid prototypes of applications or Web UI’s for demonstration or Proof of Concept to customers. Over time we may migrate to a different API, but at the moment a REST API provides us with a simple way of interacting with NSO which is independent of the language, libraries etc. that we develop in.