Why doesn’t Asset Management have an Industry Reference Architecture?

In my recent note, I explored how Asset Management firms can lay the right foundations for Enterprise AI—with Robust Data Strategy and Seamless Integration as the twin pillars.

But here’s the real question: Why, unlike Banking or Insurance, Asset Management never embraced a standard industry architecture (which would have made it easier)?

The answer is complex—and revealing:

1) Diverse Business Models

Asset Managers differ across:

• Asset classes (equities, fixed income, alternatives, private markets, (more recently) crypto)
• Client types (retail, institutional, sovereign, pension funds)
• Investment styles (active, passive, quant, ESQG, factor based)

A one-size architecture struggled to emerge because the operational value chain isn't uniform

2) Alpha Over Architecture

For years, technology was seen as a support function—not a differentiator. Investment IP, not platforms, was the moat. This mindset discouraged standardization, especially as the technology structure was perceived as a threat to alpha generation.

3) Fragmented Vendor Ecosystem

From OMS/EMS to risk engines and analytics, every vendor brings unique data schemas and integration patterns—making a neutral, vendor-agnostic architecture elusive.

4) Regulatory Lag

Unlike banks, asset managers faced late digitalization and real-time reporting pressures, delaying the push for standardization.

5) Function Over Form

Industry efforts defined what functions should exist, but not how systems should integrate or share data.

6) Legacy Complexity

Mergers, bespoke systems, and proprietary platforms built behind closed doors have left a patchwork of architectures.

So, is it time for change? Absolutely.

Today, the industry faces fee compression, regulatory complexity, data explosion, rapid digital expectations from clients, and—most importantly—AI-driven disruption. The need for a capability-driven, standardized architecture has never been greater.

A modern, loosely coupled Industry Architecture can unlock:

• Cost and margin optimization
• Seamless interoperability to share data, context & intelligence
• Standardized “plumbing” setup suited for innovation
• A solid foundation for Enterprise AI

Watch this space for how a capability-based reference architecture could help drive innovation, efficiency, and readiness for the AI era.

Original post on LinkedIn - here.

#ArtificialIntelligence #AssetManagement #DataStrategy #Integration #EnterpriseArchitecture #AIAdoption #FinTech #Innovation #Leadership #CTO #CIO #EnterpriseStrategy #IndustryArchitecture #ReferenceArchitecture

AI in Asset Management: Stop Chasing #FOMO —Start Building the Foundation

 Before Jumping on the AI Bandwagon: Why Asset Management Needs Strong Foundations.

AI is everywhere—#FOMO is real. But in asset management, rushing into AI without the right groundwork is like building a skyscraper on sand. AI is not a magic wand. Without solid foundations, you will get fragmented insights, not true enterprise intelligence.

AI Adoption is a strategic journey, not a race. There are fundamental foundation elements that need to be implemented to have the house in order.

Why this matters in Asset Management

The asset management industry is inherently complex, characterized by diverse asset classes, intricate processes, stringent regulatory requirements, and evolving client expectations. AI initiatives that focus solely on individual business capabilities may provide short-term benefits, but without a strategic and well thought-through base, they risk becoming isolated solutions. Sustainable enterprise-wide intelligence can be achieved only when AI is holistically embedded across the organization.

Before enabling AI, ask yourself:

• Do we have the right data strategy? (Think enterprise data models, governance, interoperability)
• Do we have a flexible integration strategy? (So, data flows seamlessly across systems and capabilities)
• Are we risking skipping the foundational elements by implementing AI to serve isolated individual business capabilities that may eventually create more silos instead of breaking them?

Foundational steps for success:

• Develop a flexible, at the same time comprehensive data model.
• Establish a robust integration framework to ensure seamless connectivity across systems.
• Implement strong governance practices and promote interoperability throughout the organization.

With robust data and integration strategies in place, AI can deliver consolidated intelligence—empowering organisations to shift from reactive operations to initiative-taking, insight-driven decision-making.

Ready for the Next Step?

Getting your data and integration strategies right is only the beginning. Once a solid foundation is established, the question becomes:

How can you unlock AI’s full potential to deliver enterprise-wide intelligence in asset management? This will be a journey “From Foundations to Future: Building an AI-Driven Asset Management Ecosystem.”

By moving beyond foundational readiness and embracing a holistic, strategic approach, asset managers can realize the transformative value of AI across the entire enterprise.

Enterprise Architecture 2.0 is rapidly emerging as a transformative evolution of traditional enterprise architecture. Rather than serving solely as an IT-centric discipline, EA 2.0 is now recognized as a strategic enabler for digital transformation and business strategy alignment natively.

EA 2.0 can empower organizations to unlock the full potential of AI in facilitating the alignment of enterprise data, standardising business capabilities and processes, optimising the integration strategy, and seamlessly and natively aligning Business to IT by building a platform to drive enterprise-wide intelligence in asset management.

As we continue this journey, watch this space for essential topics such as moving from data chaos to AI-powered clarity, the role of EA 2.0 in Enterprise AI, and most importantly the impact of EA in building a modern Asset Management Industry Architecture where the true transformation is imminent.

Original Post on LinkedIn - AI in Asset Management: Stop Chasing #FOMO —Start Building the Foundation | LinkedIn

#ArtificialIntelligence #AssetManagement #DataStrategy #Integration #DigitalTransformation #EnterpriseArchitecture #AIAdoption #FinTech #Innovation #Leadership #CTO #CIO #CDO #EnterpriseStrategy #IntegrationStrategy #EnterpriseAI

Blockchain - The latest disruptive hype : A different perspective

Every few years, a new concept (be it technology, be it an execution methodology, or a business process, or even a deployment strategy) comes around and everyone in the tech industry gets super excited and wants to be the first one to take it mainstream. 

Having come from a programming background at a grass root level, depicting what and how blockchain works was fairly straight forward. The concept is very good. Like everything else, it is another "option" to consider if there is an absolutely genuine use case to solve a problem.

As of today at the time of this writing, there are extremely very few such ones in the world which cannot be addressed by anything else other than blockchain.

The problem we face is this - Instead of trying to find a solution to fix a particular problem, we tend to find a problem which can be fixed with an available solution. It has become a style statement to say one is doing a lot of research on blockchain these days. Not many of them are technical enough to understand what does that mean. It is one of the modern flashing hobby to do something on blockchain and brag about it. It is a new buzz word which right from the CTO to a programmer are excited about it and I think they are all quite valid. The issue comes when we overdo it.

The same sort of thing happened multiple times in the past. Not all of them were for a specific technology though. A few of them were concepts. In short all of them were so called "disruptive trends".

I remember in the early 2000s, every other IT person I met used to be a "DOT COM consultant". Their job was to sell or guide start ups to go the .dot com way. Then came a burst to show us all the mirror of reality. The world wasn’t ready for digital and connected experience at that time. Now is the time for it and clearly we can see the success of it.

Then there was an era of Open source. Soon, every software, people wanted to build wanted to be open source and the image that was portrayed was, there is no alternative to open source. Then the extremism eventually faded and the industry has now struck the right balance of what can and needs to be open source and what is best to be a packaged or a product solution.

The same happened some time ago with Document based DB / NoSQL. Suddenly when versions of document DB started to go around, people started to believe, RDBMS is dead and it was a big mistake that it even existed. Soon quite a few of them wanted to include NoSQL in everything they do rather than thinking about the right use case, purely because they perceived it as the trend.

Then came Agile. For a few agile fanatics, every problem in the world can be fixed by Agile. I am clear in my mind, AGILE is a solution to a problem which shouldn’t have existed in the first place. 
More on this in my next blog :-)

The point here is not to demean any of these trends. They are fantastic trend changing technologies and are intended to stay. Same is with Blockchain. It is a fantastic concept and a breakthrough technology. But my worry is with the fact that we tend to take these to the extremes.

These are tools (not in literal sense, in some cases, yes) for the architects, business analysts and organisations to consider when trying to fix a business problem. The fundamental point here is - what is the business problem? If the business problem can be resolved by a simple spreadsheet, let's do it. There is no need to build an application to do that. It is a good thing to know (like any other technologies) and keep it in our back pocket to be used when the right scenario arises to put to use. There is never a one size fits all.

I am an architect by profession. Been one for more than a decade, and prior to that more than a decade long of core application and system development as a programmer. Blockchain is a superb invention and a beautiful concept and I am sure I would like to get my hands dirty on it too.  

I am fairly sure, I may not be the only one with this view. I found a few of such articles on the web and providing it here for some additional reading :
https://thenextweb.com/hardfork/2019/02/07/why-hype-is-killing-blockchain-technology/
https://channels.theinnovationenterprise.com/articles/why-blockchain-hype-must-end
https://cointelegraph.com/news/report-companies-dropping-the-term-blockchain-due-to-hype-around-technology
(There are quite a few more, just Google it, to read more)

I suspect I am going to end up ruffling some feathers and I expect quite a few reading this, who advocate Blockchain for everything will try and prove me wrong and so say the least find me completely ignorant on the subject :-).

All I would like to tell them is to look for both side of the coin and wait for the right commodity to spend it. My intention is to suggest them to think and wait for the right use case rather than trying to use it everywhere. There are a few genuine use cases currently and there will be more that will land in the future. Till then, I would hesitate to call it really disruptive.

Disclaimer: All the views expressed here are solely personal views of the author and does not reflect in any way whatsoever the company the author is associated with. The matter expressed here is AS IS with NO WARRANTY explicit or implied.

C++/CLI

In relation to a couple of my previous blogs on C++/CLI
(https://sultanate.blogspot.com/2009/08/ccli-alternate-way.html
&

https://sultanate.blogspot.com/2006/12/c-in-or-out.html), 

I am tempted to put this whitepaper I wrote long ago which details the need and benefits of C++/CLI.

C++/CLI

Better late than never :-)

Hope this is useful to the programming community.

Migration from Java to Microsoft.NET

Introduction

Java has been around for almost 15 years now. It was a complete paradigm shift and Sun Microsystems' (Now Oracle-Sun) initiative to move away from a conventional platform based programming model to a Runtime based programming model which would allow us to run the same application on different platforms without any code change.

.NET initiative was Microsoft's strategy to confer competition to Sun's J2EE or more famously the Java Technology. Microsoft.NET has been in place for almost 7 years.

This paper is not intended to depict the fundamentals of these two technologies. This paper is to throw light on the ways and means of porting a Java based application to .NET.

In theory, both the technologies are the fundamentally similar. Both are architected in a similar way and both serve the same purpose. There are just two fundamental differences though, between these two competing technologies:

• Runtime for Java (called as JVM or Java Virtual Machine) is available for all the platforms such as Windows, Linux, Solaris, Mac OS X, Unix etc. On the contrary, Runtime for .NET (called as CLR or Common Language Runtime) is available (as of now) only for Windows. Although there are few open source initiatives to build a runtime for the other platforms too. One of such initiative is called “Mono Project” (http://mono-project.com/Main_Page).



• The language used for developing applications in Java Technology is confined to only one, i.e. JAVA language, whereas there are quite a few languages that can be used to develop a .NET based applications, such as VB, C#, C++, J#, Perl.NET etc.

There are more differences between the two technologies, but they are not very significant with respect to this article.

Need for Migration from Java to .NET

The most common need for migrating a Java Application to .NET (or even vice-versa) is Platform consolidation. Companies & ISVs are constantly trying to reduce the cost of maintaining their products or software, by keeping the skill sets required to maintain all the products to be common so that they take advantage of a smaller team specialising in “one” technology. And since Java &.NET are architecturally the same, the migration from one another is quite straight-forward.

This article will focus on converting Java applications to .NET.

Types of Migration

There are two types of migration available for converting Java applications to .Net:

• Upgrade to Visual J#.NET

J# is one of the languages that can be used to develop applications targeting to the .NET CLR. The syntax for J# is same as Java. The reason for existence of this language is to provide a faster migration path for Java developers to learn and start writing software for .NET.

Upgrading Java applications to J# is the fastest and easiest way to port Java applications to .Net. Java developers are instantly productive on J#.Net because the syntax and set of class libraries are similar to Java.

Visual J# .NET consists of a Java language compiler and the required class libraries designed to provide the functionality equivalent to most of the JDK level 1.1.4 packages. The classes in the java.util package support functionality equivalent to JDK level 1.2 class libraries and classes in the Microsoft Supplemental UI Library for Visual J# provide much of the functionality as described in the Java 2 JFC Swing specifications. It also consists of a tool to upgrade compiled Java byte code to MSIL—useful for upgrading libraries to a form that can be used from .NET Framework-based applications. In addition, like other .NET-compliant languages, J# too has full access to the .NET Framework, and includes designers for building Windows Forms and ASP.NET Web Forms based applications.

In many cases, essentially where business logic preservation is a goal, upgrading to Visual J# .NET is the easiest and quickest way to move Java applications to the .NET. With a familiar syntax and set of class libraries, developers can leverage their existing knowledge of Java, and become productive on the .NET immediately. The upgrade is very quick, and developers can begin to add features with the .NET Framework and Microsoft extensions to the Java language.

• Converting Java code to C# using a Tool

Microsoft developed a tool called the Java Language Conversion Assistant that can be used to convert Java applications to Visual C# .NET. Code that calls Java APIs is converted to comparable C# code that uses the .NET Framework. Because of the complexity of the conversion, not all Java APIs are converted. The Java Language Conversion Assistant converts about 90 percent of JDK and J2EE version 1.3 calls, EJB, JAAS, JCE, JMS, JNDI, RMI, and JAXP, and emits issues in code for the other 10 percent. Each issue is linked to a topic with guidelines for what modifications are to be made and code needs to be written manually.

Although converting to C# is generally more labour-intensive task than upgrading the code to Visual J# .NET, it offers more flexibility to the software because the application is converted to use the native .NET Framework APIs. Hence the converted code will immediately take advantage of all the features of the .NET Framework.

The next section provides a like-to-like mapping of the Class library, components and its implementation in Java & .NET

Migration Mappings

• Like to Like Components

Java Technology	Upgrade to Visual J# .NET	Convert to C#
Java language	Java language	C# Language
Applet	Supported via J# Browser Controls	Windows Forms control
JavaBean	JavaBean	System.ComponentModel System.Windows.Forms.UserControl
ActiveX control	Supported via J# Browser Controls	ActiveX control
AWT frame	AWT frame	Windows Form
WFC form	WFC form	Windows Form
Compiled library	Compiled library	Not converted
Resource file	ResX file	ResX file
CORBA	Not Converted	.NET Remoting System.Runtime.Remoting;
RMI and RMI IIOP	Not Converted	System.Remoting System.Security System.MarshalByRefObject
DHTML	Not Converted	System.Web.UI.WebControls
Enterprise Java Bean	Not Converted	System.EnterpriseServices
Java Authentication and Authorization Service	Not Converted	System.Security
JavaBeans Activation Framework	Not Converted	System.Windows.Forms.DataObject
Java Mail	Not Converted	System.Web.Mail
Java API for XML Processing	Not Converted	System.Xml
Java Cryptography Extension	Not Converted	System.Security.Cryptography
Java Database Connectivity	Not Converted	System.Data.OleDB
Java Messaging Service	Not Converted	System.Messaging
Java Naming and Directory Interface	Not Converted	System.DirectoryServices
Java Server Pages	Not Converted	ASP.NET
Java Transaction API	Not Converted	System.EnterpriseServices
Microsoft Transaction Server	Not Converted	C# Class (Serviceed Component)

• Individual Packages vs. Assemblies

Package	Upgrade to Visual J# .NET	Convert to C#
com.ms.awt java.awt	Java.awt	System.Windows.Forms
com.ms.com	com.ms.com	System.Runtime.InteropServices
com.ms.dll	com.ms.dll	System.Runtime.InteropServices System.ComponentModel
com.ms.dxmedia	Not Upgraded	DirectAnimation
com.ms.fx	Not Upgraded	System.Windows.Forms
com.ms.io	com.ms.vjsharp.io	System.IO
com.ms.lang	com.ms.lang	System Microsoft.Win32.RegistryKey
com.ms.object	com.ms.vjsharp.object	System
com.ms.ui	Not Upgraded	System.Windows.Forms
com.ms.util	com.ms.util	System System.Collections System.Diagnostics
com.ms.wfc.app	com.ms.wfc.app	System.Windows.Forms System.Globalization.CultureInfo Microsoft.Win32 System.Environment.SpecialFolder System.Threading System.DateTime
com.ms.wfc.core	com.ms.wfc.core	System System.ComponentModel System.Windows.Forms.Design System.ComponentModel.Design System.Resources
com.ms.wfc.data	com.ms.wfc.data	ADODB System.Runtime.InteropServices RDS System.Globalization System System.ComponentModel MSDASC System.Resources
com.ms.wfc.data.adodb	com.ms.wfc.data.adodb	ADODB
com.ms.wfc.data.ui	com.ms.wfc.data.ui	System.Windows.Forms System.Data System
com.ms.wfc.io	com.ms.wfc.io	System.IO System.Globalization
com.ms.wfc.ole32	com.ms.wfc.ole32
com.ms.wfc.ui	com.ms.wfc.ui	System.Windows.Forms
com.ms.wfc.util	com.ms.wfc.util	System System.Diagnostics System.Collections System.Runtime.InteropServices System.Resources System.Globalization
com.ms.wfc.win32 com.ms.win32	com.ms.wfc.win32 com.ms.win32	Converted to PInvoke calls
java.io	Java.io	System.IO
java.lang	Java.lang	System System.Threading
java.lang.reflect	Java.lang.reflect	System.Reflection System
java.math	Java.math	System.Decimal
java.net	Java.net	System.Net System System.IO
java.security	Java.security	Not Converted
java.sql	Java.sql	System.Data.OleDb System.DateTime
java.text	Java.text	System System.Globalization System.Resources
java.text.resources	Java.text.resources	System.Resources
java.util	Java.util	System System.Collections System.Globalization System.Resources System.Configuration
javax.swing	javax.swing	System.Windows.Forms

Retirement of Visual J# & JLCA tool

Microsoft has retired the Visual J# product and Java Language Conversion Assistant tool starting Visual Studio 2008. The J# language and JLCA tool will not be available in future versions of Visual Studio. To preserve existing customer investments in J#, Microsoft will continue to support the J# and JLCA technology that shipped with Visual Studio 2005 through to 2015.

Way forward

As mentioned in the Section 5, although the two (automated) methods of converting Java code to .NET are retired by Microsoft, they are still available to be used to convert 90% of the conversion to make things easier for complete conversion.

The decision to automate the code conversion or to rewrite / re-architect the product is based on 1 governing principle – “How well architected is the original Java System”. If the Java system is very well architected and does not need any architectural change, then using the tool / converting it to J# makes more sense since the framework for java and the Framework for .NET is more or less similar and most of the features have a like-to-like mapping with each other.

If the process of migrating a Java application to .NET is initiated due to an existing poor design of the product, then the best option is to completely re-architect & re-design the product from ground up taking into account the best practices of Microsoft.NET. In this case, use of automated migration may not provide the best solution.

References

http://msdn.microsoft.com/en-us/library/ms973842.aspx