The four pillars of digital modernization (Corporate Blog)

 Digital Transformation Part #4

Please refer original post at

https://atos.net/en/blog/the-four-pillars-of-digital-modernization

Three tips to maximize the impact of your digital modernization program (Corporate Blog)

 Digital Transformation Part# 3

Please refer original post at 

https://atos.net/en/blog/three-tips-to-maximize-the-impact-of-your-digital-modernization-program

Measuring your company’s digital readiness with the NICE framework (Corporate Blog)

 

Digital Transformation Post#2

Please refer to the original post at

https://atos.net/en/blog/measuring-your-companys-digital-readiness-with-the-nice-framework

A guide to embarking on an evolutionary and successful digital modernization journey (Corporate Blog)

Digital Transformation Post#1

Please refer Original Post at

https://atos.net/en/blog/a-guide-to-embarking-on-an-evolutionary-and-successful-digital-modernization-journey

Sales Operations - The backbone of growth strategy

 

In the last few months, I have met many leaders who have been responsible for Sales Operations in their respective organizations. It brought me to a realization that Sales Operation is one of those functions, of which every organization has a different view. It differs for the type of organization and its customers. For example, a B2B organization would have different expectations from Sales Operations than would have a B2C organization. These expectations also reflect in other functions like Sales, Marketing, and Finance for these organizations. However, there will be a few things that are common to a Sales Operations function regardless of the nature of the business OR type of the organization.

Also known by other names like Sales Enablement and Sales Support, Sales Operations is essentially a corporate function that not only runs the sales engine but also helps the drivers i.e., Sales Heads decide the right direction in which vehicle should go. This team also manages all vital metrics of the Sales vehicle by leveraging tools like CRM.

While in many organizations, a Sales Operations (SOps) manager may just become the Executive Assistant to Sales Leaders, in mature organizations, a SOps leader is meant to play many hats simultaneously. In her primary role, a SOps leader would play the role of COO of the Sales organization, laying out tools & processes for sales, and also enforcing their use. In secondary roles, she would be a Sales Strategy Partner and at times, also the Chief of Staff for Sales Leadership.

However, one aspect of this role that most organizations miss is that a SOps leader should also become a Sales Person and always work towards hitting the numbers. In fact, if possible, a SOps leader should have quotas aligned with the organization's sales targets. She may not go and sell the products or services by herself to end clients, but having a sales-linked incentive will ensure that the role is fully aligned with the sales team.

With respect to duties related to Sales Strategy, a SOps leader is either solely or with other functions’ leaders responsible for Account Classification, Target Account/Consumer selection, Sales Alignment with Strategic needs, and also Go-to-market (GTM) strategy for each of the products and services. In addition, she should also give inputs on Quota Setting, Multiplier/Accelerators setting, and Commission Payout.

A Sales Operations team has to have tools and capabilities in analytics, strategy analysis, and internal communication. This is one team that has to work in tandem with almost all the corporate teams – Finance, HR, Product or Service management, and Marketing - of the organization.

So, in all sense, this team has to be good at numbers, while also understanding organizational dynamics, account/customer-specific marketing initiatives, and technical aspects of products and services to ensure the sales team is able to execute the sales strategy. It makes your Sales Operations team truly an all-rounder team.

So, if your organization has a Sales Operations function, you may want to ask where it falls on the role spectrum of Sales Operations.

#SaleOperations #SalesStrategy #Sales #MISReporting

Why SOA was killed while Microservices are thriving?

Yesterday, I was in the Microsoft Azure Boot camp event in Toronto. And one of the things that came for discussion was the Microservice architecture. Later, over the discussion when we were discussing legacy architecture patterns, one of the participants asked me how SOA is different from the MIcroservices. This is not the first time when this question came to me, a big fan of SOA in my architect days.

However, today I also asked myself another question - why SOA, the hot topic of last decade, got vanished as fast as it came into the limelight. As I dug deeper I realized there were several reasons that contributed to the SOA’s downfall. These reasons ranged from the unavailability of the right ecosystem, SOA’s inherent technological flaws, to not having the right proponents.

I’ll explain each of these later, but before that, let me briefly explain the differences between SOA & Microservices, as many of us, early adopters of SOA but not in Architects role anymore, may still be looking for the answers.

There are four major differences between SOA and Microservices –

1. Messaging Protocol: Although SOA was technology-neutral, it was largely implemented with SOAP/HTTP while WSDL being the service contract between Service Provider and Service Consumer. Microservices use REST/HTTP as communication and transport protocol
2. Database inclusion: In SOA, the database was still kept one, though business services were refactored to realize the principle of Separation of concern. In Microservices, even database tables are supposed to be refactored to ensure all the vertical components of services are self-contained without any dependency on the components of one or another.
3. Orchestration Layer: SOA prescribed to have an orchestration layer, which mostly got implemented in BPEL, though there was no technology prescription in terms of technology. BPEL was great for Long-running processes but extremely slow in executing online transactions. At times the same logic implemented in BPEL was 100 times slower than the one written Java.
4. Service Discovery: For Service Registry and Discovery, SOA brought the concept of UDDI (Universal Directory and Discovery interface), while Microservices are managed through API Gateway – concepts are similar but there are implementation differences

• the response has to come in microseconds while Microservices remote calls over HTTP add substantial distribution tax on the end-to-end performance
• business changes are rare and scalability is not required as happens in standard processing of batch files
• SDLC methodology followed is still Waterfall with no or limited adoption of DevOps best practices.

Now taking it from here, let’s understand what went wrong with SOA that caused its phenomenal crash from being the darling of many enterprise architects in the last decade.

The first reason was the availability of the right ecosystem. Although SOA was an architecture for distributed applications, the infrastructure available was mostly on-premise with its own capability & scalability limitations. The Cloud computing and advanced DevOps ecosystem were still coming up. The impact of this was that Services conceptualized in SOA architecture got implemented and deployed through a traditional monolithic deployment mechanism and the experience was not great.

The second reason was that as SOA was publicized as being synonymous to web services, mistakenly though in the same way the Blockchain was assumed to be the Bitcoin platform, most of the implementation got done through SOAP/HTTP messaging and communication protocol. Running over traditional infrastructure, these services experienced substantial latency, making them unviable for high-performance applications.

The third reason was its perceived conflict with Object-Oriented Architecture & Design (OOAD) in which Data & Methods were encapsulated together in one class/object, while SOA recommended keeping services segregated from data. To a large influential community of Java professional, it was the iconoclastic behavior from new technology. Many of these Java developers and architects couldn’t accept the SOA as an alternative and it became extremely difficult for SOA proponents, who mainly came from integration programming background like webMethods, Tibco, WebSphere integration, etc. to influence the decision-makers to adopt the SOA.

With other nails in the coffin as explained above, SOA couldn’t realize its full potential, and ultimately paved the way for its light-weight offspring – Microservices. By this time Cloud computing is at the forefront across the globe, Advanced DevOps tools & Processes are in place at most of the organizations, and having REST protocol over HTTP helped eliminate the verbosity and performance issues up to a large extent.

Although Microservices architecture inherited many of the SOA problems like distributed logging & debugging, distribution /latency tax, managing hundreds of smaller services, it weaved itself very well in the existing technology stack and it was complemented with scalable cloud architecture, agile DevOps tools & practices, and Log aggregators - three items extremely critical for its success.

However, now as it happened in the case of SOA, Microservices are also being touted as the panacea of all global IT problems. So, it is extremely crucial to understand cases where a typical Microservices would not be the right architectural solution. These include, but not limited to, business use cases where

• the response has to come in microseconds while Microservices remote calls over HTTP add substantial distribution tax on the end-to-end performance
• business changes are rare and scalability is not required as happens in standard processing of batch files
• SDLC methodology followed is still Waterfall with no or limited adoption of DevOps best practices.

In nutshells, although Microservices architecture pattern got the benefit of the ecosystem and organization readiness, potential uninformed decisions by lazy thinkers will push it on the path of SOA. So Architects need to be extremely thoughtful when accepting or adopting Microservices as an alternative to their existing architecture.

#SOA, #Microservices, #Architecture, #AzureBootcamp, #AzureBootcampTO