The Next Frontier for Collaboration

So why did I start on this?

After a long time, last weekend, I came across a pitch I used to take on our POV for Communications way back in 2007…I had predicted that something called “Air PBX” would replace all the then known Predominantly On-Premise Solutions by 2020…

Well I’m now in the start of 2019 and to me it looks like the concept of Air PBX is now prevalent as Cloud PBX from various vendors and is now the default start point of voice architecture. Only Laggards and some customers with genuine “Consistent” quality requirements remain on Legacy On-premise solutions. So much has changed in the Industry and I too have broadened my portfolio now covering the entire Collaboration Technologies. My outlook also has now changed and spearheaded by the frontline collaboration products…ahem…ahem… I’m referring to the Teams duo (WebEx Teams and Microsoft Teams) …

This weekend I was thinking what the scenario in collaboration in the next decade would be…and this followed…

Architecture Highlights for Collaboration in 2033, IMHO

Plenty of Architectures reviewed and Possibilities got analyzed in my head, and I settled on a few highlights that could define the Collaboration Architecture of 2033…

  1. All functionality of Collaboration Services would be available and consumed from Public Clouds.
  2. On-Premise solutions would exist but not as “Production” Equipment. On-Premise Solutions would be built and maintained to handle DR/BCP aka “Cloud Fall” situations
  3. PBX, Voicemail, SMS and ACD may be terms that will be found only in dictionary
  4. The Current Complexity of Multiple Products for Multiple Services will disappear, and Significant Convergence will happen on the Admin Front-End. Please do note that while “Services Endpoints” Collapse/unify, the “Consumption” Mechanisms will explode.
  5. The Diversity of “Communication and Collaboration” Management Teams will disappear and will be replaced by teams aligned to the prevalent vendors at that time. To Illustrate, the SME of vendor 1 will cover all technologies from voice, video, documents collaboration, messaging and the various modalities of consumption that will be normal by then…But this SME may not have any idea of how to get things done on vendor 2’s platform.
  6. Very few Enterprise SMEs will understand the backend complexity of the respective platforms and these too will be focused on managing the DR/BCP setups only.
  7. Identity, Privacy Policies and Data Protection used for communications and collaboration will be external to the vendor platforms unlike how it is tightly integrated currently.
  8. AI/ML based technologies will become utility and serve well understood services with full access to the user’s live and historical interactions. The Universal Policy Managers will ensure that Privacy is managed.

So how would the Collaboration Architecture of the Future look like?

Its Feb 2019 and things could change significantly both towards or away from what I believe will happen. I took a similar approach in 2007 when even Hosted PBX was not a normal practice. At that time UCaaS and Air PBX were terms with very few practical technologies available to make them a reality. But the market has moved in exactly the direction I predicted… I’m going to use a similar extrapolation this time… so here goes…

I believe the entire Architecture will be broadly clustered on four key Solution Units:

  1. Contact Service Providers
  2. Content Service Providers
  3. Security Policy Managers
  4. Consumption Technologies

Of these IT SMEs will have deep knowledge of only the Consumption Technologies. The rest will be of “Talkonology” grade and will be well versed only on the GUI/API based management. Only a few curious and ardent nerds will have knowledge of the inner workings, and their knowledge would be utilized in customer’s DR/BCP Build and management purposes.

Contact Service Providers

In the Current ecosystem this is led by the likes of Skype for Business Server Editions, Cisco UC Servers and similar IP PBX/UC Servers from multiple UC Vendors. IMO these functionalities will move to cloud-based platforms like Skype for Business Online, Microsoft Teams, Cisco WebEx Teams and similar platforms…. Slowly and steadily these will build tight integration with Content Infrastructures in the backend.

The Contact Services themselves will become simplified with Unified Interfaces providing access to all Channels of Communications for the Users. The back-end however would be significantly more powerful and feature heavy than current UCaaS solutions.

Content Service Providers

In current ecosystem this is led by Microsoft SharePoint, Exchange and the various Knowledge Management products in the market like Salesforce.

As mentioned above these would merge from being separate products to a unified product in the admin front-end. Please do note that in the back end they will continue to be different with each service doing what it does best. This Product will also be handling all the data used by the ML Engines deployed in both back-end and Consumption devices. Governance will be handled by Universal Privacy Policy Managers

Security Policy Managers

To be candid our current ecosystem does have several wannabes in this product group, but none may be ready to take the overall nine yards.

The products in this group will be universal in the sense that they will work independent from to the contact and content platforms. This group may not be covered completely by any single platform as well unlike the contact and content products…

Consumption Technologies

This will be the most interesting group which will flourish widely and be the target of time spent by the Architects and Administrators of the Future

If you’ve been in this side of business, then these shouldn’t be too new. The only major difference will be that by 2033 these will be normal and significantly less complex… Also, the Legacy pieces may remain in some Laggards’ IT Portfolio….

Finally

I wanted to write a lot, but time is short and hence kept to a minimum… maybe I’ll write a follow-up in future…

To get an idea of how I was doing the extrapolation… You can check out my earlier blogs https://julianfrank.wordpress.com/2014/09/26/the-ucc-infrastructure/ and https://julianfrank.wordpress.com/2014/09/19/thoughts-on-ucc-first-a-recap-of-what-has-been-happening-so-far/ .

Happy Reading -.

How could applications look like in the future? #2

This is in continuation to my previous blog with the same topic… https://julianfrank.wordpress.com/2018/01/21/how-could-future-apps-look-like/ … So why again??

One of my pet project was going complicated beyond control to the extent that I hardly remember why I wrote the code in a particular way :sigh: … Hence I’ve been looking for converting my tiny yet complicated monolithic application into a micro service application! Looked around and found istio a few months back and love the level of policed flexibility it provides. This is great for enterprise environments with relatively large teams handling the whole new stack… Sadly for my project that was way too much overhead and complexity for a relatively few features that I was trying to build…

Then I discovered moleculer. This is a nice framework that has all the fundamental features of micro-service ecosystem ticked and yet relatively small and less complicated for my weekend project needs…You can read about its features at a glance at http://moleculer.services/docs/0.13/ … I moved some services -> got into trouble -> cried out for help -> got support from @icebobcsi and others in its gitter.im/moleculerjs/moleculer channel -> now my app is back on track…. Very impressed!

To add to the benefits, the capability to merge and separate services across nodes means that I can code in a system with all services in one node… When deploying to production, I can split the services into separate nodes and make then run in separate container or vm instances… The Framework cares nothing about where you host except that they are able to reach each other over the network. To make things simple you can start with service discovery over TCP Broadcast! Of course for large scale deployment, other mechanisms like NATS, MQTT, Redis etc would be a better fit. My only quip was that this is locked to NodeJS. I Hope that in future, other cloud friendly languages like Golang is also supported…

Back to the topic… My idea of apps being Universally Discover-able is already a possibility Now!

What is left is the service (which I referred to as app in my previous blog) to be self-aware and adapt to work conditions as per needed….

Just imagine a situation where we got five services as part of our application: A, B, C, D, E

Now imagine a situation that the app is bombarded with two users with one user targeting A while the second user using a mix of services

A self-Aware application would in this situation split itself into multiple nodes, letting the first node focus on user 2 while creating copies to handle the high demand from user 1…

When the load is removed, the services move back to a minimal node instance back to original size….

Currently this is facilitated by K8S with careful engineering from IT. But in future I believe, the framework would take care of deciding how the service behaves and the process of mitosis by itself… Am I just day-dreaming?? I don’t know !!

DevOps Environment Architecture – My Thoughts

After writing about my thoughts on how application architecture might look like in the future, I have been now thinking about how CTOs would want to remodel their DevOps Environment to cater to the whole new multi-cloud ecosystem with completely new Jargons flying around… Lemme illustrate: Cloud Native / 12 Factor Applications, Multi-Cloud, Hybrid–Cloud, Micro-Segmentation, Containers, ChatOps, NoOps, PaaS, FaaS, Serverless, TDD, BDD, CI/CD, Blue-Green, A/B, Canary … You get the picture right…. All these were alien terms in the old Waterfall Model of Application Development but are now the new reality but retrofitting the waterfall style of governance on this ecosystem is a sure recipe for disaster!

So how can we approach this?

I see two dimensions by which we should approach the new estate

  1. The Environmental State Dimension – In this dimension we look from the context of the state of the work item in terms of modern agile Life-Cycle
  2. The Application Life-Cycle State Dimension – From this perspective we see the work item from a user experience impact perspective….

Let’s Explore the State Dimension…

I see four clear states that the code ultimately will go through in a multi-cloud CI/CD environment

Developer Station

  1. This is the environment that the developer uses to write, perform local tests, branch and sync with multiple developers’ s work
  2. This can range from a completely unmanaged BYOD environment to a hyper secured VDI Client
  3. A few Options in increasing order of IT Control I can think of are as below:
    1. BYOD Laptop/Desktop with Developer’s own tools and environment
    2. IT provided Laptop/Desktop/Workstation with mix of IT and Developer installed tools
    3. Virtual App based IT supplied Environment on Developers Device
    4. VDI Client Accessible from Developer Device

Test Zone

  1. This would be the zone where the code gets committed for Integration Tests and Compliance Tests against the bigger SOA / MicroServices Environment
  2. This typically would be cloud based to minimize cost as the load would vary significantly based on working slots of developers and commit levels based of application change loads
  3. Automation is inevitable and manual intervention is not advisable considering the maturity of testing tools automation available in the market

Staging Zone

  1. This zone would be a small scale replica of the Production zone in terms of Multi-Cloud Architecture, Storage distribution, Networking and Security
  2. The Aim would be to Test the Application in terms of Performance, UX and Resilience on multiple Cloud Failure Scenarios. 100% Automation is Possible and hence manual intervention should be avoided
  3. Observability Assurance would be another important goal post in this environment… Though I personally have doubts on maturity of automation capability… Unless Developer Adheres to Corporate Standards, Observability would not be possible for the given code and automation of this is doubtful and imo may need manual intervention in certain scenarios…

Production Zone

  1. I don’t think this zone needs any introduction
  2. This is where the whole ITIL/IT4IT comes to play from a governance and management perspective
  3. This also would be the zone where multiple clouds thrive in an interconnected, secured and 100% IT Governed manner

 

Now to the other dimension…

Application Life-cycle

I have already talked about this in a previous blog (Digital {{Dev}} Lifecycle) …

But overtime I believe there is more needed in an ever changing multi-modal enterprise environment… But that I leave for the next post … Till then bye!

An Approach to Cognify Enterprise Applications

I recently witnessed the setup of my brand new Windows 10 Laptop and was surprised when Cortana guided the installation with voice recognition! This was happening before OS is there on the laptop! … I wouldn’t have imagined this 5 years ago and set off imagining how the experience would have been if the setup designer decided to completely remove any mouse/keyboard inputs. Further, what if Cortana had matured to converse with me naturally without any Pre-Coded questions being asked in sequence! Instead of saying yes or no I dabble about how good the laptop looks and Cortana responds with affirmation or otherwise but gently getting me to respond to the key questions needed to be answered before the full blown OS installation could start… It sounds cool but in future releases this may be the reality!

Back to the topic of Enterprise Applications, Conversational experiences are being continuously developed and improved upon with the bots learning how to converse from both pre-built flows and historical conversation logs. In the enterprise context it now becomes important that CIOs & CTOs start thinking about how their Business Applications can be used on these Conversational Platforms. Enterprise Leaders need to think carefully about how this gets architected and deployed so that it does not become something mechanical and irritating like traditional IVR Solutions. To Succeed in the endeavor we need to look not just at the New Cognitive Platform but also the Services expected to be enabled on the bot and keep the experience exciting so it does not meet the same fate as IVR in terms of experience.

I see the following SUPER aspects of the Solution to be first Scrutinised carefully before project initiation:

  • Service – Look at where the Service is currently performed and check for viability of being able to Integrate with the Cognitive Platform
  • User Experience – Look at how complex is the service to be executed over Automated Interfaces like Phone, Virtual Assistants and Chat UI
  • Peripherals – Look for the peripherals where the services have been provided currently and check if the same can be reused or replacement would be required. Oversight here could lead to Urgent and Expensive replacement later and decreased User Adoption.
  • Environment – Different Services are performed in different work conditions and careful consideration should be made so appropriate services are not provided in certain conditions. For example, speaking out Bank Balance on a Loud Personal Assistant as Speech could embarrass users and lead to privacy concerns of a different nature.
  • Reliability – Here the Cognitive Platform itself should be judged in terms of fragility not just in terms of uptime but in terms of handling edge cases. This is where the continuous unsupervised learning capability needs to be looked at very carefully and evaluated to ensure that the Platform builds up cognition over time.

Here is an approach of how Enterprise Leaders can start moving their workforce to embrace Cognitive Applications

Step 1) Service Audit – Perform an Audit of Services Being performed and the related applications.

Step 2) Cognitive Index Evaluation – User the SUPER aspects to Evaluate the Cognification of each service.

Step 3) Build Road Map – Categorise the Services in terms of ease of introduction and ease of development and batch them in phases.

Step 4) Identify Rollout Strategy – Based on complexity and number of possible solutions and channels under consideration, one or more POCs may need to be initiated followed by bigger rollouts. In case of multiplicity of Business Applications needing to be integrated, then Business Abstraction Layer Solutions could be brought in to significantly boost Integration time.

Step 5) Monitor and Manage –  While the Cognitive Solution brings reduction in service tickets to IT, injection of capabilities like ‘Undirected Engagement’ could lead to monitoring and management of conversations in terms of Ethics, Privacy and Corporate Diversity Policy.

What do you think?