< Back to Blog post Romania

Perspectives from Ness’s CTO – Common Business and Technical Challenges

As Chief Technology Officer of Ness Digital Engineering, I have the opportunity to meet with many customers and potential customers who operate in a variety of business domains, e.g., retail, financial, education, healthcare. This affords me a unique perspective on the kinds of business and technical challenges these companies face, and the ways they are dealing with those challenges.

Each company may think their problems are unique, but it is truly remarkable how many of these problems are shared across companies and across verticals. To paraphrase Tolstoy, unsuccessful companies are highly similar, while every successful company is successful in its own way. In this article, I would like to describe some of the common challenges and themes that I have seen over the past few months across multiple companies and domains.

Explainable AI

Artificial Intelligence has arrived and is being touted as the solution to many enterprise challenges and bottlenecks. But, at the end of the day, it is people, not algorithms, that are responsible for any decisions that are made. If something goes wrong, just doing what the AI algorithm recommended is not a very convincing defense. So, if enterprises are going to base mission-critical decisions on AI algorithms, they need to understand why the algorithm recommended what it did and what the underlying logic was. Not only does this build trust in the system, but it also helps flag inaccurate or otherwise problematic recommendations.

The problem today is that many AI algorithms like deep learning base their recommendations on patterns they discern in large volumes of training data. In many cases, they are based on statistics rather than on any human-understandable logic, so the results may contain hidden bias or distortion. For example, suppose a company wants to analyze data to determine the salary level to propose to a new employee. The training data used to tune this algorithm, if based purely on historical wage data, may be biased to perpetuate unfair wages to women or minorities.

That’s why Ness ensures that any AI-based system we deploy is explainable, i.e., any recommendations it proposes can be explained and justified to a human being. This is based on recent technological advances that can help humans understand obscure statistical algorithms like Deep Learning, e.g., Local Interpretable Model-Agnostic Explanations (LIME).

There are many use casesexplainable AI can be applied for anything that impacts people’s lives and could be tainted by bias. This could range from determining admissions to a training program or university to deciding how much to insure someone for or whether to issue someone a credit card or a loan based on demographics

Respectful Platform Modernization

Some of Ness’s customers are engaged in a major platform modernization project, moving from a legacy mainframe system to a more modern cloud-based containerized architecture. The motivation may be a compelling event such as an end-of-life announcement for the mainframe, or may be motivated by a need to increase agility and reduce the time required to introduce a new business feature. Whatever the motivation, the transition must be carefully managed so that the business continues to run with no interruptions, and so that the entire company is ready to accept and use the new system at the end of the transition period.

Some of the common pitfalls we see in these modernization projects:

Cultural schisms between the legacy and the modernization teams. All too often, the company divides into the “old-timers,” who understand the existing business processes and technologies, and the “new kids” who understand the latest technologies and development methodologies. The result is a cultural schism, where the legacy team does not share knowledge with the modernization team because they feel left out of the process, and the modernization team lacks the deep knowledge of the existing domain and technologies that is needed to modernize them. One solution we’ve used to ameliorate this schism is to mix the teams, e.g., use legacy product managers to drive requirements for the modernized system. It’s also crucial to cultivate a sense of respect from the modernization team for the existing legacy system which, while it may be outdated, was probably state of the art in its time and brought the company enough financial success to fund the current modernization effort.

Over-optimistic scheduling of the modernization process, that fails to consider issues like:

– Availability of subject matter experts, who also have to keep the lights on, for requirements capture.

– Evolving requirements that get articulated only after users see a first version.

– Time required to capture and implement non-functional requirements for later-stage operations such as parallel-run and mainframe retirement.

– Teething pains in setting up a functioning development environment.

A big-bang approach that does not provide any short-term business wins. A multi-year timetable for a product that gets deployed in one go at the end of development is doomed to failure, because business decision makers will lose patience long before the product is ready. At Ness we have learned to identify “cut points” where portions of the new system can be deployed within a few months and can start providing tangible business benefits that create an appetite for more.

Intermixing of modernization and other goals. It’s tempting to accomplish other goals while you are modernizing the entire system anyway, e.g., improve business processes that appear broken, or transform the organization’s way of working from a waterfall model with infrequent deliveries to a more agile model. In Ness’s experience, this is a mistake because it opens up too many battlefronts at once. Who says a new process defined by the modernization team is any better than the existing process used by the legacy team? Who says your product’s users would prefer the frequent releases that agile development could enable? Modernization is enough of a challenge all by itself and should therefore be funded and tackled all by itself.

Read more about Application Modernization: https://www.ness.com/application-modernization-one-size-does-not-fit-all/