~SparK~ in the cloud...

You Automated 25 Steps. You Never Asked Whether You continue to need all the 25 anymore?

2026-09-29T12:44:13.870+01:00

Why the next wave of value is capability re-imagination, not agent proliferation

Almost every one I speak to, is building agents. Budgets are approved, pilots are running, and the results are genuinely encouraging. But look closely at how the work is being scoped, and a pattern emerges that should worry us.

Let's take a simple case. Assume, a business capability with five processes, each with roughly around five steps. Twenty-five steps in total. Teams are diligently working through them, asking: which of these twenty-five can AI do faster, cheaper or better? They find eight or nine, build agents for them, and report a productivity gain.

The question nobody is asking is whether, with AI in the mix, the capability still needs five processes and twenty-five steps at all.

Many of those steps exist for reasons that AI has just made obsolete. They exist because information had to be re-keyed between systems, a human had to read a document and classify it, or a handover was needed between two teams who could not see each other's context. Since the control was manual, a checkpoint was inserted. Those steps are not business logic. They are scar tissue from an era of constrained software. Automate a step that should not exist and you have made waste efficient. That is a productivity gain. It is not optimisation.

Productivity gain versus structural optimisation

A genuine re-imagination might conclude that the capability no longer needs five processes of five steps. It may need three processes of six. The headline number barely moves here - twenty-five to eighteen, but the handovers, reconciliations, queues and control points that consume real cost and real elapsed time fall away. That is where the economics change.

Why this is an architecture conversation, not an AI conversation

Here is the uncomfortable part: many organisations cannot re-imagine a capability even when they can see the opportunity. The process shape is fossilised in the application estate. Steps exist because a package demanded them. Sequence exists because of a nightly batch. Ownership boundaries exist because someone bought the system in 2014.

Composability is the antidote to that fossilisation. If a capability was assembled from a discrete, set of independently owned building blocks, each with a clear contract, its own data boundary, and no assumptions about who calls it or in what order, then the process shape becomes a choice rather than an inheritance. This allows re-sequencing steps, may be remove a step entirely, or let an agent collapse three into one, because nothing downstream is structurally dependent on yesterday's arrangement.

If the estate is monolithic, re-imagining the capability means a re-platforming exercise; where as when it is composable, re-imagining the capability is just a re-wiring exercise. The difference between those two is usually eighteen months and a business case nobody wants to write.

This is exactly what loosely coupled, domain-driven, composable architecture was always meant to solve, and it is why the principles matter more now, not less:

Model the capability, not the screen. Bounded contexts should follow business meaning, not the seams of the packages you happen to own.
Make the process the composition, not the code. If your process sequence is hard-coded across six systems, you cannot redesign it. If it is orchestrated above services that expose clean contracts, you can.
Contract-first, replaceable components. A capability you can re-shape is one where any component - including an agent, or a model can be swapped without a migration programme.
Events over integrations. Asynchronous, re-playable domain events remove the queues and reconciliations that generate most of the steps you are trying to delete.
Isolate the legacy, do not enshrine it. Wrap it behind an anti-corruption layer so that yesterday's system does not dictate tomorrow's process design.

Composability is what makes re-imagination physically possible. Without it, you can only decorate the existing process with intelligence.

So, What good looks like

The recommendation is deliberately unglamorous:

An AI-native capability application built on conventional enterprise application architecture, with bounded agentic intelligence embedded where ambiguity, reasoning and language understanding create measurable value.

Read that carefully, because both halves are load-bearing.

Conventional architecture still holds the spine. Process state, sequencing, transactions, entitlements, segregation of duties and audit belong in deterministic code and workflow, not in a prompt. A regulator will not accept probabilistic evidence that a control was applied.

Bounded agentic intelligence goes where determinism has always been weak: interpreting unstructured documents, reasoning over ambiguity, synthesising across sources, drafting, explaining exceptions. Scoped agents, typed tool contracts, explicit workflows, human approval at the points that carry consequence.

Agents are a component type in your architecture. They are not the architecture.

The tooling has caught up

The encouraging news for CIOs and CTOs is that - this no longer requires an exotic skill set. Development framework or libraries like the Microsoft Agent Framework gives you abilities to build custom agents, explicit workflows, tool calling, memory, checkpointing, human-in-the-loop and observability natively as first-class constructs in .NET and Python. Additionally, MCPs for governed tool exposure, durable workflow for the deterministic spine, existing API and event platform, and a modern SPA or Teams surface for the human in the process. In other words all that is required is already in the current application engineering capability.

Where to start

Pick one capability that is expensive, slow and evidence-heavy. Do not start with the easiest.
Map the current processes and steps honestly, then classify each step: business-essential, control-essential, or compensating for a system limitation.
Delete the third category on paper first. Design the target shape assuming reasoning is cheap and abundant.
Decide what must remain deterministic, and draw the boundary explicitly. This is the single most important architectural decision.
Build the composable spine and embed agents inside it, with evaluation, tracing and audit from day one.
Measure capability economics: cost per outcome, cycle time, exception rate, rework. Not agent count.

And a closing thought for my fellow software engineers

If the last two years have made anyone nervous about their profession, this is the reassuring part. Someone has to decide where the deterministic boundary sits. Someone has to design the bounded contexts, the tool contracts, the event flows, the failure modes, the evidence trail, the fallback when the model is confidently wrong at two in the morning.

AI made reasoning abundant. It did not make architecture optional. If anything, it just made the architects and engineers who can think in capabilities rather than components considerably harder to replace.

We are not automating ourselves out of a job. We are being handed a much more interesting one.

Legacy vs. AI in Asset Management: The Real Battle Is Not About Technology

2026-04-15T17:14:00.001+01:00

Asset management firms are talking about AI everywhere - in investment research, client servicing, compliance, operations, and software engineering. Yet the real constraint is not ambition. It is the architecture and its legacy. Many firms are still trying to introduce AI on top of fragmented legacy environments, siloed data, and operating models designed for a pre-AI world.

Ideally, the conversation should not be framed as Legacy vs AI in simplistic terms. Legacy is not merely old technology; it is complexity of technology accumulated over decades, due to pouring budgets into “run the business” activity, leaving only a tiny appetite for a timely enterprise-wide digital transformation which has led to disconnected systems, duplicated processes, partial data lineage. To add to it, there are instances of modernization programmes which has never fully decommissioned the legacy. Many firms continue to carry fragmented technology stacks across asset classes and functions, creating complexity that consumes time, money, and management attention.

And this has now come to bite us, because AI is not just another productivity tool. If used well, it can reshape the economics of the industry. Generative AI, and agentic AI could unlock efficiencies with impacts across distribution, investment processes, compliance and also largely within the Technology units like Software Development. Firms can realize early gains in compliance, risk management, and IT operations, and soon can expand into client-facing and front-office use cases.

But here is the catch: AI does not erase weak foundations. It amplifies them. If data is poor, governance is immature, workflows are broken, or systems do not integrate well, AI will expose inconsistency faster than we imagine. The main barriers to AI value in asset management are cultural resistance, poor data quality, talent gaps, and system integration challenges. Firms increasingly recognize data as critical, yet many still struggle with fragmented systems and outdated processes even as AI adoption moves beyond pilots.

This is why firms should not be approaching AI as a collection of disconnected experiments. They need to treat this as a perfect domain transformation agenda. The outcomes will be stronger if the approach is shifted away from isolated use cases realisations and turn towards moving away from legacy, by embarking an end-to-end redesign of the functions and capabilities to align with the AI world. Long-term advantage of doing so will come from moving beyond superficial adoption and embedding AI into core workflows, governance, and decision-making.

In practical terms, that means three things.

First, modernize the data foundation.

AI cannot operate effectively if firms still rely on inconsistent golden sources, manual reconciliations, and disconnected front-to-back platforms.

Second, redesign workflows - not just tasks.

Real value lies in workflow rewiring and domain-level redesign, not fragmented automation. The biggest returns will not come from deploying copilots in isolation. They will come from reimagining end-to-end processes across research, portfolio construction, onboarding, compliance monitoring, and service operations.

Third, treat governance and workforce readiness as strategic enablers.

Regulatory and compliance complexity will remain if concerns around privacy, accuracy, and external data use remain widespread. Hence the governance structure and workforce readiness needs inclusion at the outset rather than as an afterthought.

So, will AI replace the legacy in asset management? No - not overnight. The debate is not about its replacement. Core platforms still matter for books of records, controls, accounting, transaction integrity, and regulatory confidence. But legacy can no longer be the centre of the strategy. Firms that continue to spend much of their technology energy preserving yesterday’s architecture will struggle to realize tomorrow’s AI value.

The winners will be the firms that do both at once: rationalize the legacy core and build an AI-enabled operating model on top of a modern data and governance foundation. That is the real shift. Not from old technology to the new one, but from fragmented technology estates - to intelligent, integrated, and adaptive enterprises.

Replicated from LinkedIn. Original LinkedIn post - here.

#AssetManagement #AI #GenerativeAI #EnterpriseArchitecture #DigitalTransformation #InvestmentManagement #DataStrategy #OperatingModel #LegacyModernization #FinTech #CIO #CTO #AIAdoption #EnterpriseStrategy

Unlocking AI Value: Why Asset Management Needs an Industry Reference Architecture Now

2026-01-28T18:01:00.001+00:00

Further elaborating my previous note, where I touched on why Asset Management industry never embarked into aligning itself to a capability based standard Reference Architecture, here is an attempt to put this into perspective as to why the need is arguably more now than ever.

Asset Management stands at a strategic inflection point. As AI, regulatory scrutiny, and cost pressures converge, the absence of a standard Industry Reference Architecture (IRA) is no longer a technical gap—it’s turning into a business risk and more fragmentation at exactly the time when firms need clarity, consistency, and interoperability.

A well‑defined Industry Reference Architecture (IRA) becomes a force multiplier for AI adoption, regulatory resilience, operational efficiency, and vendor alignment.

Here are some of the strategic advantages - especially relevant when the industry is pivoting heavily into AI, LLMs, and data‑centric operating models

1. AI requires standardisation of data, workflows, and controls to scale

AI does not operate well on fragmented architectures. A capability driven reference architecture provides:

Common data domains (securities, positions, orders, benchmarks, ESG, alternatives, reference data)
Standardised process boundaries (investment process, trading, operations, compliance, reporting)
Clear control points for model governance (model risk, data lineage, human-in-the-loop)
Consistent integration patterns for embedding AI agents and copilots

The biggest blocker to AI at scale today is architectural inconsistency, not model capability. A standardised reference architecture - directly would be able to remove that blocker.

2. Accelerates interoperability across the vendor ecosystem

Many of the important Asset Management capabilities are very heavily vendor driven. A reference architecture provides:

Standard sets of integration patterns for all vendors to adhere to
Standardised capability map to evaluate vendor fit
Re-usable APIs and canonical data models

This reduces the cost and complexity of vendor replacement or multi-vendor strategies.

3. Creates a shared language between business, technology, and regulators

As AI in financial services becomes more regulated (EU AI Act, SEC guidelines, UK AI White Paper), authorities increasingly expect:

Explainable process boundaries
Data lineage
Governance layers
Integrated risk and control frameworks

An alignment to a standardised architecture becomes the blueprint to demonstrate compliance.

4. Accelerates AI maturity across the entire value chain

AI + IRA could potentially provide a -

A unified data fabric
Clear component definitions (e.g., research, trading, risk, distribution, client solutions)
Reusable AI patterns (models, embeddings, agents)
Governance-by-design

This means that instead of “AI in pockets,” the industry moves toward AI-enabled enterprise platforms.

5. Reduces complexity and cost in legacy simplification

A reference architecture -

Sets the target state to optimize excessively duplicated capabilities and data flows
Simplifies transformation sequencing by removing inconsistent integration mechanisms
Allows firms to modernise incrementally without losing coherence
Enables standardisation of redundant reporting and reconciliation tools

6. Guides AI operating model redesign

Asset Management firms are already exploring options for AI-assisted research, investment idea generation, automated compliance checks, intelligent operational exception handling and more. Industry architecture potentially introduces a baseline to help define the right use cases fit for AI.

Without a defined architecture, AI adoption will remain more ad-hoc, becoming a series of siloed experiments with no enterprise coherence.

7. Strengthens industry collaboration

An IRA becomes a foundation for Industry data standards, Shared solutions (KYC, ESG, market data utilities), benchmarking, and Interoperable best practices of digital ecosystems. This has the potential to help lay a foundation for the Industry Cloud Platforms.

Within the wider Financial Services industry, Banking has standardized operations around BIAN and insurance around ACORD. Asset Management Architecture has the opportunity now for a similar push.

Now is the most strategically aligned moment

For every Asset manager to understand the need to rethink its architecture as:

Data maturity is becoming a competitive weapon
Technology costs are rising
Regulators are expecting more transparency
Operating models are being rebuilt to be AI-first

A consistent enterprise language in the form of an Industry Architecture is not just a documentation exercise, but a strategic enabler of the next decade of transformation. It is no longer about preserving the past—it’s about shaping an AI-native future. The next decade of asset management will be shaped by those who build AI at scale.

Original LinkedIn post - here

#ArtificialIntelligence #AssetManagement #DigitalTransformation #EnterpriseArchitecture #AIAdoption #Innovation #Leadership #CTO #CIO #EnterpriseStrategy #IndustryArchitecture #ReferenceArchitecture

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

2026-01-14T13:45:00.002+00:00

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

2025-12-05T12:03:00.003+00:00

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

2019-08-12T11:33:00.000+01:00

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

2018-11-28T12:29:00.005+00:00

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

2015-12-04T20:34:00.000+00:00

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

CaaS – Now what is that?

2011-01-28T11:48:00.001+00:00

There is too much cloud these days. And still plenty more to come. What started as something called as Application Service Provider (ASP) way back during late 90s, has been transformed to different names with minor changes or additions to it. In the modern era, it is known to all of us as SaaS or S+S (as Microsoft would call it) or in more generic terms – Cloud computing. This doesn’t end here. The cloud strategy matures more and more as day progresses, and we see more variations and more versions of the cloud computing such as PaaS (Platform as a Service) and IaaS (Infrastructure as a Service),

In between all these, what does CaaS mean?

Well, to be honest this isn’t any jargon or buzzword or any standard term used in the Cloud computing arena. This is something coined by me to revive something which used to be once prevalent during the ASP days and the Dotcom boom days and it has tend to remain constant rather than seeing an exponential growth as compared to other cloud terminologies. I call it “Components as a Service”.

Now, before you jump up on me and thrash me for trying to teach you something you already know in a different form, I would like to declare here that this is NOT anything new that I intend to express. This is just an attempt to provide some idea to people thinking to make a new living out of cloud (may be thinking of building a product to be made available to customers as SaaS), that there are even thousands of opportunities to build what I term as CaaS i.e. Components as a Service. Not all software built for the could has to be SaaS. One could build generic parts or components that can be used by others who would build SaaS.

As I mentioned earlier, this isn’t anything new. Way back, in its original form, CaaS providers built many on-the-web “facilities” or “components” to be consumed by web sites. But during that era, the web applications were confined to only e-commerce or a portal in some form or the other. With the cloud becoming more and more a norm to deliver entire software solution on the web, the market for consumption of these components which would be used to build such SaaS applications grows exponentially. The target market for CaaS once that used to be only to Web sites and portals, now is the entire cloud in various forms like the SaaS, PaaS.

Component As A Service

A component as a service as the name suggests is nothing but a ready-made piece of a (web) “functionality” available for other web applications to consume thereby saving their time to build these themselves. One may argue that there is nothing new to this. A custom web control (like Graph or Chart control, a video display control) etc. can be called as a CaaS as they may be used by other SaaS products as is, without them having to develop it on their own. Or in another argument, one may say that any “service” provided in the form of “Web Service” that performs a particular (outsourced) business operation for you may also be called as CaaS. Well the point is not to prove that these are NOT CaaS or otherwise. The point is to throw some light to a broader spectrum of components that can potentially emerge into the cloud arena with a difference.

To my mind, a CaaS is something which provides an end-to-end “independent” business functionality that can be used by other SaaS products within their software so that they would not have a need to build these functionality on their own. It ideally comprises of all the 3 layers of any 3-tier system (UI, Application Logic and Database) but only for that functionality. If you recollect, this is what was once called “Application Service Provider”. So time and again, I would like to stress a point, this is nothing new.

So what can really be developed as CaaS? Well to give an idea, lets look at some existing CaaS that are already available in the market (but people may not know if it could be a potential component that they may use it for their own SaaS product.

Scenario 1

Assume we need to develop an HR System and make it available as a SaaS. An HR system would typically have things like Employee Management, Payroll, Appraisals, Recruitment and so on. So just to make the problem a bit simple to understand the context, we need to develop 4 modules to build the HR system that we intend to make it available as a SaaS. It would be nice if one of these 4 modules is available as a generic “Web based plugin” so that we need to develop only 3 of the 4 modules. Surely the web based ready-to-use plug in should be so configurable that it may not feel different for our customers who would be using our system. It needs to integrate so seamlessly that for a customer who is using our system, would not make out that he is using a different system for 1 of the 4 modules than the other 3.

One such “web based end-to-end recruitment" system available in the market is “Taleo”. (www.taleo.com)

Although they have been providing their Talent Management software as CaaS to most of the top multi-nationals’ web site for Career management, they have a huge potential for being used by SaaS companies (building HR solutions) as a ready to use end-to-end recruitment module. The entire suite offered by Taleo has almost the entire HR operations and they themselves can offer the entire suite as a SaaS to customers, but that’s besides the point. They surely have the potential to offer parts of their software (as a service) to be offered as CaaS for other SaaS companies to consume and thereby giving a them a completely different market to enter.

Scenario 2

Most e-commerce sites these days provide an online chat assistance to shoppers or people who look confused navigating through their sites. This is nothing new to us. But most of these assistance are developed by the e-commerce sites themselves and they provide a very limited functionality. With applications now more widely available as SaaS, providing a Customer Interaction Management would be ideal as the cost of 1st line and the 2nd line support goes down to a great extent. Thus the assistance can be provided by using such web based chat tool. This again, may not be needed to be developed by each and every SaaS vendor (as most of the e-commerce website would have done). They can be hired as a CaaS.

One such “web-based customer interaction management” is provided by a company called “Live Person” (www.liveperson.com). There are far many companies providing similar service as CaaS but Live Person are the oldest and the most popular in this domain.

Scenario 3

The above 2 scenarios are good to explain what a CaaS could be. But they do not provide a new business idea to the readers as the 2 examples I provided are well established market leaders in their own market as CaaS providers. The key point to be noted here is the “concept”. With cloud getting more and more popularity there is a huge potential for building large varieties of CaaS. One such thing that comes to my mind is a Workflow Management component available as CaaS. To my knowledge, there is only 1 company (I may be wrong) providing a Workflow Management as a Service or a CaaS. They call it as WaaS (Workflow as a Service). They are PNMSoft (http://www.pnmsoft.com/workflow-software-as-a-service.aspx). The whole idea of “outsourcing” the workflow operations of our SaaS product to a Workflow CaaS provider for a nominal cost per seat is worth giving a thought.

In short after looking at all the 3 above scenarios, the concept is the same. A idea to develop such CaaS is up to the readers’ imagination. So I hope I have helped you all who are thinking of a SaaS idea to venture into, some food for thought about CaaS too, as a potential.

Key Considerations when negotiating a SaaS agreement

2010-12-01T17:49:00.001+00:00

A key step in any company’s software purchase is the negotiation of the software license agreement. But negotiating contracts can be a difficult task. It can be difficult to make sense of the legalese, server reliability guarantees and scaling options. Negotiating a Software as a Service (SaaS) agreement presents other unique challenges. Unlike traditional license agreements, SaaS contracts need to spell out the terms of data storage, backup, and retrieval. Dealing with all of these issues can rapidly become confusing.

To help buyers, ERP Software Advice has put together a list of 9 key considerations to take in to account when negotiating a SaaS agreement. The list contains really helpful information on standard clauses such as the contract term and renewals. Key considerations also include a few clauses unique to SaaS like service level agreements and data retrieval.

To get an idea of the advice offered by ERP Software Advice on these topics, here is an excerpt from the article:

1. Pricing and Discounts

By pricing software as a utility service, SaaS vendors have simplified software licensing considerably. Most SaaS pricing is based on a subscription – monthly or annual payments for using the system during that period. The subscription pricing is typically based on one simple metric (e.g. users, records, projects) that roughly ties subscription fees to the value of the system. Finally, SaaS vendors tend to publish their pricing openly.

Even with this simplicity and transparency, there is still a need to be vigilant as a buyer. For one, don’t assume that straightforward published pricing means there isn’t room for some negotiation. Many SaaS vendors will discount up to 20% to win your business. The bigger the deal, the bigger the discount. Moreover, if the vendor’s pricing metric doesn’t fit with your business model, you might be able to negotiate custom pricing. Of course, you’ll have to make a cogent argument that the standard metric fails to balance price paid and value received.

2. Additional Costs

Another key component to pricing is ferreting out any extra costs early in the process. Published pricing may appear to be a good value, but extra fees can add up quickly. Common additional costs include extra users, customizations, integrations, third-party services, training and set-up fees. Work with your sales rep early in the process to understand what additional charges might apply to your account.

By far the best way to keep the additional costs down is to avoid customizations to functionality and integration with other systems. The inherent complexity in custom development and data integration makes these services expensive. We recommend that you start with the base system, make use of its core functionality and then assess how important the custom features or integrations are to your success. Start small, think big, grow quickly.

3. Term

If you are negotiating with a vendor over pricing discounts, subscription metrics and additional fees, expect to give something in return. Oftentimes, this means committing to an extended contract term. Vendors like longer terms because it provides more predictability in their revenue forecasting. Terms can be as short as 30 days or as long as five years. If the vendor wants a long-term subscription, we recommend that you start with the shortest – probably one or two years.

If you do agree to a longer term of three to five years, make sure you have an out clause. Typically this would provide a window of opportunity to break the contract during a specific time window. For example, it might allow you to walk after one month of using the system but before 90 days. Another example might be the ability to break the contract if certain levels of service are not provided consistently.

4. Service Level Agreements (SLAs)

Regardless of what you pay for the system, reliability is paramount. The SLA is the vendor’s commitment to keeping the system up and running. It is typically expressed as a percentage of “up time.” You will almost always see the SLA represented as 99.9% or thereabouts. However, there is wide variation in how that number is calculated. Many vendors will simply start with 100% and subtract time during which their internal systems reported an error. Most of these SLAs leave far too much wiggle room for vendors.

If this new SaaS system is mission critical, push the SLA issue to see who is really ready to stand behind their service. The SLA topic is far too detailed to delve into all the considerations here, so we’ll refer you to this great blog post on SLAs. However, we’ll suggest you focus most on the penalty for breaking the SLA when negotiating. Usually these penalties are paltry discounts paid out against future purchases. Just pushing for bigger penalties will provide great insight into the reliability of the system.

For anyone who is thinking about subscribing to a web-based software system, I recommend this as a must read. The full article can be accessed by visiting the ERP Software Advice blog post at: 9 Key Points to Negotiate in a SaaS Agreement.

Ten Scenarios to go cloud

2010-11-29T15:38:00.001+00:00

With everyone speaking about cloud and talking about developing applications, sometimes it is confusing to identify if our application really needs to be on the cloud.

If you are an ISV, the answer may be relatively simpler (of course after reading my previous blog :-) )

If you are looking to develop an application to solve a Business problem or if you are looking to automate any of your business process, the first thing that comes to our mind as of today is, should be develop this on the cloud or are we fine keeping the software on premise.

The purpose of this blog is to provide ten most common scenarios where it may be wise to use the Cloud computing to develop the applications. Please note that these are NOT THE ONLY scenarios for exploiting the cloud platforms. The benefits of cost & maintainability do not form the part of this discussion.

1) SaaS offering

As mentioned in my previous blog, if you are an ISV, then you may want to offer your product as a SaaS rather than selling it as an on premise application. There are various business & technical benefits in doing so, but this is a complete chapter in itself. Developing a SaaS based application from ground up, or building it using a PaaS is again a different discussion. But surely a SaaS is a cloud offering in itself or / and may be build using a PaaS which is also a cloud offering.

2) Scalable Web Application

If you have a very large web application for your enterprise or planning to develop one or if you have an e-commerce site and it needs to be highly scalable (as scalable as a SaaS application), this can be an ideal candidate for going cloud using a PaaS. PaaS provides flexibility of provisioning for spikes in user load. It provides a cost effective way of using more servers and load balance during load and can get back to minimum configuration when the load goes down. Moreover because PaaS or for that matter even IaaS is offered on pay per use basis, it saves a lot of maintenance as well as operational cost.

3) Dynamic requirement of resources

If you have a requirement for large number of resources and the need for the same is highly dynamic, then the best option would be to accomplish the same using a IaaS. E.g. Assume there is a need is to build a data replication tool and lets assume you may want to test the tool to ensure that data is replicated smoothly across 100 servers. A huge amount of investment has to be made to buy a 100 servers and if you are not able to justify the spend or having a 100% utilisation of each one of them, then its a huge hit on the expense. You may opt to have 10 physical servers and create 10 each virtual machines on them, but again as long as there is a very large business benefit, doing so would not be ideal. Using a IaaS like the Amazon EC2, it is extremely easy and cost effective to hire as many server instances as possible. The same can be released if not required and thereby saving money on resources not utilised. Another similar likely scenario – To perform a physical load-test of an application with 10,000+ users on the portal and would like to gradually increase the load to know the breaking points of the system.

As you may recollect, there are many obvious advantages of using IaaS – no upfront investment, Pay per use, Ready to go server instances, on demand scalable model and many more.

4) High processor intensive application

Assume a requirement of an application that requires High end computing power to likes of 8 CORE processors with 32 GB RAM to run the CPU intensive calculations and it is estimated to have 20+ such servers to accommodate the desired throughput.

The same can be easily accommodated using IaaS as well as PaaS and all the benefits of going the cloud route like the no upfront investment and pay on demand model help us achieve the ultimate goal rather than going for a large upfront capital investment. Cloud is very useful in scenarios where time to market is one of the key requirement. Recently Microsoft showcased Pixar’s application called “Renderman” uses cloud to get the best benefit. Similar application requirements which need extremely high processing power can go cloud way either through IaaS or PaaS.

5) Provide a centralised high volume (yet highly secure) Data access

Application Storage Needs for applications to the likes of On-Demand Training Platform of a company are increasing significantly day by day. The storage requirements are already in Several Terabytes (TB) (1 TB = 1024 GB) and growing at the rate of 100 GB/month. There is a need to have scalable storage solution at the same time stay close to the cost. A PaaS would be ideal in this case as it will save on a very high upfront investment on servers and maintainability, provide a very high scalability and also a guaranteed reliability,

6) Hybrid Applications

If there is a need to provide an application which has a on-premise version of the software as well as a web version of the same and both need to share the same data source, then hosting the database for such hybrid applications on the cloud is an ideal option. Both types of front-ends can be in sync and there is a huge save on the money spent on the infrastructure to accommodate connectivity from anywhere.

7) Central Data Repository

Similar to the previous type of application, if there is an application (on-premise or web) deployed and used by thousands of users from across the globe (may be from many different branches of a very large multi-national company), then having the database at a central repository makes sense. Although the same functionality can be achieved by hosting the database server on a secured local intranet and making it available for all the branches to connect, this requires a complex infrastructure setup and a huge investment which may or may not be the best option. Instead, having the database deployed on the cloud using either IaaS or PaaS may be a viable option.

8) Temporary requirement of Datacentre space

Most datacentres do not have a business model by which they provide server space on a need basis or on a temporary basis. Ideally they would want us to provide a minimum 6 month or in many cases a 1 year commitment to use their space so that they have a return on their investment. If your situation demands that you may want to use a datacentre only on a need basis and that too for a period of 1-2 months at a stretch or it is unpredictable, going the IaaS is the best option. IaaS providers like Amazon provides a flexible and cost effective mechanism to configure, host and release the server resources on a need basis.

9) Experimental Applications

If you have an idea to build a SaaS application (or would like to test the waters of building a SaaS version of your existing on-premise software, you may not want to put a high upfront investment if you are not sure of it’s success or failure. Using PaaS to develop your SaaS application idea or prototype provides a very high level of flexibility and safety to ensure you have a strong Business case to go back to your management to build a full blown SaaS application.

10) Freeware

If you are into building Freeware, you may want to keep your cost as low as possible, since the most likely scenario for building your brand would be only after there are too many (happy) users of your product. Keeping the cost low till the time would be key to success for your business. Building your application and / or hosting the same at a PaaS provider or an IaaS provider gives you a minimum till you sense the light of success.

The idea of this blog is to give people some food for thought about whether to build an application the conventional way or to build it for / on the cloud and there are too many reasons to go for it or even to go against it for each of the above types of application. But in most scenarios mentioned above, going the cloud way is surely a potential option.

Go cloud – An ISV perspective…Part 2 – PaaS

2010-11-15T16:01:00.001+00:00

This blog is in continuation to my previous blog entry “Go cloud – An ISV perspective…Part 1 – SaaS” which discussed, if ISV needs to go cloud and offer their products as SaaS, the quicker ways to do so.

Just to keep this article independent, I have copied and pasted below the section which sets the context, to make it easier to read. If you have read my previous blog entry, you may directly jump in to the next section “PAAS”.

Typically as the name suggests, an ISV (Independent Software Vendor) could be one of the following:

A) Traditional Software Product companies: Companies who build and sell software products

B) Web based Software companies offering their products as “Services” typically known as SaaS companies
C) Software intensive companies offering services to a market using a software. The main business of such companies is not to sell Software or even SaaS but to “use” them as their tool to sell their services. A typical example of such a company would be one providing “subscription based” clinical information, or a subscription based access to a vast patent database and so on. In such cases, they do not sell software or service instead they sell “information” using a software.
D) A start-up company who intends to become one of the above three.

For the purpose of the article and for ease of reference, let us refer the above as – A-type ISV, B-Type ISV , C-Type ISV or D-Type ISV respectively.

This article is an attempt to provide a clarity to these ISVs as to which of the cloud services they need / should / may need to consider to embark on for the success of their business.

As briefly explained in one of my previous articles, there are three different aspects to cloud computing i.e.– SaaS (Software as a Service), IaaS (Infrastructure As a Service) & PaaS (Platform as a Service). If you are a B-Type ISV, then I am sure you do not need any more explanation of what SaaS is. Also if you are C-Type ISV then too, you may not be too interested in SaaS as selling software isn’t the main business you are in to. But may be you wish to know more on these other aspects such as PaaS & IaaS.

So this is an attempt from me to put few points across to provide a clarity to all the ISVs out there.

PaaS

Using PaaS to build an offering or a SaaS product may be the fastest and the most cost effective way of doing so if you are a Type-D ISV (A start up company). As a start up you may have a fantastic product idea in mind which you think of offering it to prospective customers as a SaaS rather than an on-premise software, but you may not want to take a huge risk of doing the whole thing yourself.

By choosing a PaaS, effectively one gets a rapid application development platform to build the software along with an ease of deploying the software on the datacentres of the the PaaS providers. Because the ISVs do not have to own anything, there is no upfront investment. It is a Pay-as-you-use model and the charges of the PaaS providers can be accounted as an OpEx. This model is very useful if you are not sure how many customers you may procure during your initial years. Also, because most of the PaaS providers provide the flexibility of allowing you to increase the servers on demand, it is extremely simple to manage the spikes of customer growth.

It is very important for any ISV to ensure that their products offer a high quality of service and hence managing the non-functional Requirements is the key. And since the system is hosted on a PaaS, most of these non-functional requirements are already taken care by the PaaS providers. The ISV just need to align their Service Level Agreements they provide to their customers to the Service Level Agreement offered by the PaaS providers.

All good so far, but is PaaS a long term solution from the ISV’s perspective? May be and May be not.

If you already are a Type B ISV, i.e. you offer your product as SaaS, and if you are successful at it, there is no specific need to move your application to a PaaS. In some cases it may make sense but in most cases it would not. The only advantage of moving an existing SaaS application would be to reduce the infrastructure maintenance effort. Moreover if you already have a huge customer base, moving your system to PaaS would mean more charges / OpEx you may end up paying to the PaaS provider for each of your thousand users. Hence the cost benefit analysis needs to be done between moving the offering to a PaaS provider vs. Continuing to host (or using a Data centre) privately.

For Type A ISVs, it could be a good option to try their business model by creating a SaaS version of their product on a PaaS and sense the market reaction. As mentioned in my previous article, one option for the Type A ISV would be to reuse as much existing on-premise code as possible and build a SaaS version of it using methods mentioned in the article.

The more safer option would be to try a separate version of their product to be offered as SaaS, using a PaaS. This would mean they could treat this part of the Business as a start up and all the advantages that a Type-D ISV enjoys using a PaaS, can be exploited. And most of the PaaS providers provide a huge amount of flexibility to reuse existing code and make minor changes to make it available to be hosted for PaaS.

Type-C ISVs don’t need to worry about the PaaS immediately if they are happy with their current business model. The only reason they may or may not switch to use a PaaS would be cost as their customers are not users of their “software”. Their customers are users of the “information” provided by the software. As long as they are able to comply to the Quality of Service and their SLA agreements with their customer, the need to move to a PaaS would only be a Cost benefit in a long term and also their TCO for the business.

For an ISV (as our current focus is only ISV) whether to go PaaS or otherwise, is not an easy choice to make, for the sole reason that going PaaS means paying for each user using the system hosted on PaaS. SaaS is all about acquiring more users using the system which means more payment to PaaS providers. Hence it is extremely important to do a cost benefit analysis to evaluate if the CapEx investment + the OpEx maintenance cost for Self- hosted (privately hosted at a Datacentre), equates a lower TCO as compared to a TCO in case of having a permanent OpEx as charges to the PaaS providers.

Go cloud – An ISV perspective…Part 1 – SaaS

2010-10-04T15:36:00.001+01:00

Typically as the name suggests, an ISV (Independent Software Vendor) could be one of the following:

A) Traditional Software Product companies: Companies who build and sell software products

B) Web based Software companies offering their products as “Services” typically known as SaaS companies

C) Software intensive companies offering services to a market using a software. The main business of such companies is not to sell Software or even SaaS but to “use” them as their tool to sell their services. A typical example of such a company would be one providing “subscription based” clinical information, or a subscription based access to a vast patent database and so on. In such cases, they do not sell software or service instead they sell “information” using a software.

D) A start-up company who intends to become one of the above three.

For the purpose of the article and for ease of reference, let us refer the above as – A-type ISV, B-Type ISV , C-Type ISV or D-Type ISV respectively.

This article is an attempt to provide a clarity to these ISVs as to which of the cloud services they need / should / may need to consider to embark on for the success of their business.

As briefly explained in my previous article, there are three different aspects to cloud computing i.e.– SaaS (Software as a Service), IaaS (Infrastructure As a Service) & PaaS (Platform as a Service). If you are a B-Type ISV, then I am sure you do not need any more explanation of what SaaS is. Also if you are C-Type ISV then too, you may not be too interested in SaaS as selling software isn’t the main business you are in to. But may be you wish to know more on these other aspects such as PaaS & IaaS.

So this is an attempt from me to put few points across to provide a clarity to all the ISVs out there.

SaaS

If you are A-Type ISV, embarking the SaaS route may be an option for various reasons. It is all about entering a new spectrum of market with a complete new spectrum of operational differences as compared to the on-premise sale model. This new deployment and licensing model fundamentally changes the business model of an ISV, impacting many parts of the organisation – marketing, the sales force, presales engineering, deployment, support, finance, and product engineering and maintenance. It is no longer just sell a license, ship a copy of the product and provide support for an annual support contract. For your customers, your product (or service) is now an OpEx cost and no longer a CapEx cost.

These are the few fundamental questions an ISV should ask themselves

- Are there a large proportion of potential customers who do not buy your product due a higher up-front CapEx (in short is your on premise product expensive)?

- With your current product are you able to cater to all sizes of customers – i.e. Small, Medium, Large?

- Are you into selling a software solution which customers may only want to buy after they try it out?

- Would you like to add to your customer list, a mass volume of small customers over and above your existing amount of medium & large customers?

All the above questions are attractive reasons for an ISV to move to a SaaS based delivery model. But as mentioned earlier this impacts fundamentally all parts of the organisation right from presales to support, marketing to maintenance, product development to deployment. If you are a successful A-type ISV, and if your potential target market is reachable with your current offering, then there is no need for you to take the SaaS route. No one would suggest to get away with the current on-premise model and embrace the SaaS way of delivery (if you are already successful). But providing SaaS based delivery as one more option makes a huge sense to cater to many smaller potential customers.

In my next article I shall provide a detailed analysis of what it takes for an ISV to move to SaaS along with comparisons, pros and cons of this delivery model. As soon as this article is ready I shall change this text to point to that article for ease of reading.

Technically there are three ways of moving to / or extending your product to SaaS:

a) Using PaaS to build a new SaaS version of your product

b) “Extend” your product to enable it to be offered as SaaS

c) Completely re-architect a new SaaS version of your product

Option c) may be the best long term option but it is the most riskiest.

Option a) is the easiest option but in a long run may not be cost effective. (Details in my next blog).

Option b) could be a potential option to choose if the existing architecture is modular, flexile enough to accommodate a SaaS version of it too.

The below chart gives you a high level glimpse of your existing product architecture and whether it allows you to move to a SaaS based delivery too. It also states, what it takes for an existing product to move to be offered as a SaaS – depending upon the type of the product

Microsoft has categorised every SaaS based application in to 4 different maturity models. Please refer to this article from Microsoft for the definitions of these 4 maturity models for reference.

Please note that the above chart should be only used as a reference for a faster way to get into SaaS from a traditional on-premise software and may not necessarily the best way to achieve the same.

An ISV should ideally start thinking over to offer their product offering as SaaS with choosing one of the 3 options above with Option C being the most complex and the most expensive one and Option A would be the more modern method and Option B would be a starting point to extend the existing investment on the on premise software.

Cloud Clarity

2010-10-01T17:21:00.002+01:00

For many, trying to understand the complexities of Cloud-based services can be like navigating through a minefield, particularly if you're an ISV looking to broaden your product offering.
With that said, here's a quick basic concepts of cloud services, which should help clear the muddy waters a little.

SaaS – Software As A Service

Software as a Service can be defined as "Software deployed as a hosted service and accessed over the Internet rather than a product deployed at the customer’s premises for each customer." This new deployment and licensing model fundamentally changes the business model of an ISV, impacting many parts of the organisation – marketing, the sales force, presales engineering, deployment, support, finance, and product engineering and maintenance.
In words of a common man, an on-premise software application is the one that a user / company purchases and installs on their own machine / server and use it internally to perform a specific operation. The best example of it would be products like Microsoft Word, Excel, Outlook, Exchange Server etc.. The same functionalities / operations are also available over the web, accessed via a Web browser. These are hosted, subscription based “services” which provide a user an option to NOT buy an on-premise software and instead use it as a on-demand service. Taking the same example as Microsoft Word, Excel, if one opts to use a SaaS based offering to meet this functionality, they may choose to subscribe to an offering provided by Google called Google Docs – (http://docs.google.com) or the Microsoft’s SaaS offering @ http://office.live.com/. Thus by using one of these two “services”, the need for installing a software like Microsoft Word, Excel on our local computers is vanished.
Here’s a list of few popular SaaS offerings:
1) Salesforce.com – A complete CRM Suite delivered as SaaS
2) Office Live & Google Apps – Office productivity software delivered as SaaS
3) Microsoft Exchange Online – Email Server Software provided as SaaS for companies who do not wish to host their own Email servers for providing their employee email addresses
4) fourthhospitality.com – Complete Back Office System and ERP for Hospitality industry such as Hotels, Pubs, Restaurants delivered as SaaS
If you are an ISV and you have existing on-premise software that provides a specific business functionality, it is wise to consider providing a SaaS version of your software too.
If you are an end user or a company, thinking of buying a software to perform a specific set of business functionalities, you could potentially think of subscribing to a SaaS based offering as they provide many business advantages compared to on-premise software counterparts

IaaS – Infrastructure As A Service

IAAS is essentially delivery of computer infrastructure (typically a platform virtualization environment) as a service. Rather than purchasing servers, operating systems, software, data centre space or network equipment, there is an option to instead buy / rent these resources as a fully outsourced service.
One such example of this service is the Amazon Web Services – EC2 (Elastic Compute Cluster)
With a “pay-per-use” subscription model, these facilities are really very useful especially for trying out infrastructures.
Here are a few characteristics / advantages of using IaaS:
1) No Capital Expenditure
There is no need to buy any servers upfront as one can rent it thus saving a huge Capital Expenditure.
2) Pay-Per-Use
There is no need to pay for your ‘idle’ resources. IaaS is based on a pay-per-use model. So you pay only for the running server instances. Once done with the usage one can simply ‘switch –off’ the server. This adds to cost-effectiveness.
3) Off the shelf Server Instances
There is no need for formatting servers or installing operating systems. One can choose the server instance based on configuration required at the click of a button. IaaS providers such as ‘Amazon’ provides quite a few ready made instances of popular Server OS known as ‘Amazon Machine Image’(AMI) thus providing a significant gain for provisioning servers to not days but minutes.
4) On–Demand Scalable Model
IaaS provides an ability to kick-start given number of server instances at a click of a button.
There are lot many more benefits in using IaaS over traditional usage of on-premise servers. I would have a separate blog on IaaS to cover all of it shortly

PaaS – Platform As A Service

PaaS is a delivery computing platform and solution stack provided as a service. It facilitates development and deployment of applications without the cost and complexity of buying and managing the underlying hardware and software layers. It provides the facilities required to support the complete lifecycle of building and delivering web applications and services and can also be deployed on the servers provided by the Platform providers.
The following are the three known PaaS providers:
1) Force.com
.Force.com is a Application development & deployment platform provided by Salesforce.com. It provides most used application layers as API which can be used by developers / companies to build applications that can run on cloud.
2) Google App Engine
Google App Engine provides APIs to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment with no need to worry about hardware, patches or backups and effortless scalability.
3) Microsoft Azure
Windows Azure is a flexible computing platform provided by Microsoft to build and deploy applications on the cloud. It provides three separate platforms which can either be individually or collectively used to build software solutions:
a) Windows Azure – A platform and a set of APIs to utilise operating system services in the cloud. Windows Azure is an operating system that serves as the development, service hosting and service management environment for the entire Windows Azure platform. It provides developers with on-demand compute and storage to host, scale, and manage web applications on the internet hosted at the Microsoft datacentres.
b) SQL Azure – Hosted version of SQL Server exclusively developed and optimised for providing database functionality to applications developed and deployed on Azure platform. It provides rich set of APIs to build a database for cloud applications.
c) Windows Azure App Fabric – A set of Services provided by Microsoft to bridge the gap between the Windows Azure platform and SQL Azure to build effective clouds solutions. These services include a robust Service bus, Access control, Caching and so on. The goal of Service Bus is to make this simpler by letting an application expose endpoints that can be accessed by other applications, whether on-premises or in the cloud.
The idea of this particular article was to provide the first step to clear the muddy water. There are more cloud service providers than mentioned above. The names provided are only known examples and not the complete list.
I intend to expand more on the above mentioned points on to separate blogs very soon.

Non-Functional Requirements for SaaS

2010-09-29T19:02:00.001+01:00

All software products are built with a set of Functional as well as Non-functional requirements. The key role of the Business Analysts and the Business owners is to define / articulate the need for each and every requirement whether functional or non-functional. Functional requirements are surely the must haves and it is a prime responsibility of the Business owners and the analysts to define it or at least justify the need for it.

It is very important, one must also define Non-functional requirements and give equal importance to it along with functional requirements.It may not be appropriate but surely certain lenience in defining Non functional requirements can be incorporated in case of a on-premise software.

If you are an Independent Software vendor who would like to provide your Software as a Service, or if you would like to extend your current offering to a different market on the cloud by providing a SaaS version of the product, then the game changes completely.

In most cases, a SAAS solution is a SINGLE CODE BASE, with a SINGLE LOGICAL DATABASE serving 100s of customers and potentially 1000s of users with completely different usage patterns, different individual tweaking requirements, different requirements for interfacing with their in-house systems and so on.

Hence it is one of the top priorities to not only define the functional requirements, but also define and design the system to cater to a very clearly and strongly defined non-functional requirements. A non functional requirement as the name suggests does not provide any “business functionality”, but instead they glue the functionalities together better. Although there are too many things that can be defined as a “non-functional requirement”, I would like to highlight the most important ones that any SaaS Architects or Analysts should keep in mind, define them and most important “architect & design” the software to ensure it addresses these requirements.

Please note that there isn’t any specific priority order for each one of them and the importance of one over the other is completely dependent upon the business need and the type of the software to be delivered as a SaaS.

Also please note that not all of them may be a key requirement for every software and hence it is up to the Analysts and the Architect to define the same. The below list may also be used as a check list for the designers of the system to ensure they have it covered in their definition.

Security

No software can escape from the need for security whether SaaS or on-premise. But when it comes to SaaS the requirement turns out to be more stringent. As an ISV, the responsibility of the security (whether data security, network security or intrusion prevention) all of it lies with us. Any subscriber to a SaaS would expect assurance that his information and data is secure enough more since they are not under their own radar but we are the custodian for the same. In a multi-tenanted environment, no one would want their data to be visible to other companies using the same system. This is upmost important and should be one of the key points to be considered while defining the data structure for the software.

The network security and intrusion prevention is not the point of concern for the provider of a traditional on-premise software since the responsibility of deployment and network security then is the responsibility of the client rather than the software provider. When it comes to SaaS, these things are equally important for it to be considered.

I had attempted to provide a simple security checklist in one of my previous blogs which may be used by all parties involved in SaaS whether it be an ISV providing the software or it be a company subscribing to it or a user using the system.

Scalability

Scalability of the software takes a completely different turn when it is a software delivered as SaaS. Any software (whether SaaS or on-premise) would have to consider scalability when it comes to handling “volumes”. And since SaaS is eventually all about multi-clients with multi-users using a single code base, volumes are inherent characteristics of the software. There are no second thoughts to not to consider a Scale-out architecture along with a Scale-Up architecture for any SaaS system. The better the software more number of clients and more number of users are bound to signup for your service.

The software at the architecture level has to natively support a Scale-out architecture whereby you should be able to expand your system to virtually any level up to the theoretical maximum. We never know if our software / service is successful, we could be the next billion dollar salesforce.com :-)

Availability / Reliability

As the case applies to security, the same applies to availability or reliability of the software. It is one of most important factors / characteristics that must be inherently be part of the skull of any SaaS product – Reliability.

A very clearly defined SLAs (Service Level Agreement) has become a norm these days for any SaaS offering and not adhering to it may even have legal implications. With more and more improvements in the technology and also increase in competition, customers expect a 99.99% uptime of the service and no longer just 99.9%. So that mathematically equates to 1 hour of downtime per year. Everyone is aware of the fact that no software can be 100% bug free but at the same time, the software needs to be architected and designed to ensure that the downtime scenarios are well handled and there would be no / minimum data or business loss to the clients. And most importantly ensure your SLAs are aligned to the SLAs of your hosting provider / partner. Always use a hosting provider. Never DIY.

Performance

One of the prime reason Google Search engine and Google’s web browser Chrome is a hit is because of its speed to respond. Although no one would expect your software to be as quick as Google (although if you could get there then nothing like it :-) ) but in terms of response times to any business operations, they have to be quick enough to an extent the users do not get a chance to think about the speed. Defining a clear SLAs for response times is also key for any SaaS offering. Although defining a higher response times in your SLAs to avoid legal implications and to play safe may be a good idea to an extent, but not at the cost of users realising the system is slow and start disliking it.

Perform frequent checks for ensuring the performance is at the top of the agenda. Cache the most frequently accessed metadata, service your database by optimising your queries and ensure all the queries in your database uses the most appropriate indexes. Minimize the network operations, use compression where appropriate. Load balance your web servers and if other factors permit, localise your server location.

And most importantly do not over engineer your software. The above points like caching, database indexing etc., may not always be the solution for performance and hence should be done as a calculated exercise,

Configurability

One of the critical success factor of any SaaS application is configurability. It is even more important to ensure configurability to a great extent is taken on board for a SaaS product since its native characteristics of having a single code base. Configurability in SaaS aims to provide customers with a multitude of options and variations to provide a unique experience. Not just that but having the system configurable allows you to sell different services based on various different licensing modes / editions, e.g. Software – Lite, Software – Professional, Software – Ultimate and so on. Ability to switch on and off a particular feature or an option to change the way a user uses the functionality or even ability to change background colour of a screen, may not be the most important thing to have within a software, but surely it is one of the key differentiators / selling factor for your offering. As mentioned above, providing different editions to different target provides an option to expand market share more easily.

Also since every customer would want to use the system in a different way to suit more to their internal culture, more the configurable your offering the better.

Flexibility / Extensibility

Software offering never ever ends at Version 1. It is relatively easier to incorporate or add functionality / remove / modify functionality from an on-premise software since the consequence of doing so would not affect your other customers. They have separate copies of your system and providing more “bespoke” tweaking is possible in such cases. A SaaS offering is a single piece of software catering to all your customers. Hence the architecture should take in to account an ability / room to extend the software with more features and functionalities to provide more value to your offerings in the future.

The most important point one must avoid for a SaaS offering is to provide bespoke implementations for different customers (with switches). Ensure the software is extensible enough to avoid such scenarios.

Usability

Usability Engineering is a vast area in itself and over the years companies have started taking User experience more seriously rather than just providing “a” User interface they think is appropriate. It becomes even difficult to implement a good user interface and interaction for a SaaS offering since the spectrum of users increases more than ten-fold. A single software instance needs to provide a unique experience and functionalities to different customers and in turn various different users of each customer. It is advised for every SaaS offering to undergo a Usability engineering exercise before getting the Graphics team to define the user interface for the software.

Interoperability

And last but not the least, no software can work stand alone. There is always a need for integration of our systems with other systems providing specialised services. E.g A Purchase Management system may need to provide a facility to interoperate with a financial accounting system. If you are providing a Financial accounting system as a SaaS offering, the need for interoperability would be even higher than the other kinds of business software for obvious reasons.

The key solution to address this non functional requirement is to implement a Service Oriented Architecture. It is important to expose most of your key interoperable business functions in the form of well documented Web services to allow other systems to interact and interoperate with your system. Since we are talking about a SaaS offering, and as mentioned earlier, the requirement of individual customers may differ and hence the SOA layer to the software needs to be well thought of and well documented to avoid any need for bespoke implementations. Also it may be required to consider a facility natively part of the system’s architecture to provide a facility to import and export of raw data to allow other related systems to make the best bonding with your offering. Needless to say, interoperability should not be provided at the cost of security and hence due care needs to be taken to ensure both marry well within the system.

There may be many more points which may be considered important as non-functional requirements, but the above ones are the most important and common ones which almost all the software delivered as SaaS needs to consider and take in to account in their design and implementation.

The success of a software (especially delivered as SaaS) depends not only on its functional requirements but also to a very great extent the….NON-FUNCTIONAL REQUIREMENTS.

Cloud–What it means to common man / end users?

2010-09-08T17:35:00.001+01:00

Every single person who can talk little about IT is talking about cloud. Every other technical article on the web we read is about Cloud, directly or indirectly.

But, for an end user, is the cloud a new terminology to digest? Is it something they need to learn? Is it something they need to consider to make the right choice they make in their IT purchase or IT consumption?

The answer to all these fortunately is a NO. Although cloud as a “terminology” a recent development, but the implementation has been there for ever.

Do you ever remember Yahoo briefcase? Or have you not been using Web based free email services such as Hotmail, Yahoo, AOL, MSN, Gmail and likes of it? Have you not used RapidShare, to share large files with your friends or peers?

What are these……..?

These are nothing but “Services” available on the cloud for your consumption. Some are free, some are chargeable. But the purpose is the same. They provide you with a “facility” to do things without any / few changes / configurations on your local computer.

Think of a scenario of the distant past, when emails were for privileged ones (before Hotmail, Yahoo and net@address revolutionised the concept of “Email for all”). In this scenario, we would have bought / subscribed to an Internet Service provider, installed an email client such as Outlook, Outlook Express, Netscape (yes they too existed then) etc. Then we would configure this client to connect to the ISP’s email server and then start using the service.

Then came Hotmail, Yahoo, net@address, with a concept of – Nothing to be installed on the local machine. Everything happens on the internet. All you need is a web browser. (Free or not free is a different angle to this), So what we have here in this case, is an email service available for us to consume in the cloud. Plain and simple.

Thus before this concept started, everything was local. All software we consume to perform various of our day-to-day activities such as writing documents, creating spread sheets keeping a track of our accounts, checking and replying emails, running a particular Business application such as an Inventory Management system etc., were all local. Then came Web based email, which eliminated the need to installing an email client on our computer. Then came something like Yahoo Briefcase, that more or less reduced the need for us carrying floppy disk to carry files that needs to be accessed by us from two different computers.

Thus two of our activities were replaced by services on the internet and we didn’t need software to be installed on our computer to perform these activities.

So what has happened now that wasn’t there before?

For the past few years, what has changed is the fact that more (or almost all) applications that we use on a day to day basis for productivity or activities, are now available on the internet which means, each service we use on the web, we do not need to install that specific software on our local computer. For writing documents, word processing, maintaining a Spread sheet, software like Word, Excel are no longer the only available option. One could think of using Google docs or Office Live (complete office suite available on the web that can be consumed by just using a web browser).

World has progressed a lot on speed and availability of the internet. Hence even to listen to music, we do not need to install software such as Winamp, Media Player or Quicktime. We could listen to music available on the internet which can be streamed to a browser and provide the same experience.

For almost all the applications we use on a day-to-day basis we now have a choice of whether to install the relevant software locally on our computer or just use a browser to connect to an online version to achieve the same functionality.

The main reason for devices like netbooks, tablets and slate computers like iPad sell today is because we are in an era where most of the common tasks are achieved over the web and hence these devices can afford to be light and handy.

How far do we think this will go?

Well this is a difficult question to answer. As an hypothetical example, if we assume we consume 20 applications for performing our day to day activities, before the Hotmail, yahoo era, all 20 were essentially software that were to be installed locally on our computer. With Hotmail / Yahoo etc. we needed 1 less (emails were available on the web). Over the years the number has gone up to a great extent that we have almost 15-16 of them available on the web.

Are we saying we do not require any kind of software installed on our local computers?

The answer to this would depend upon two things – a) Is there a cloud equivalent of the software we use, and b) the level of our usage. We have to accept a fact here that the web cannot provide (at least as of today) all the richness in terms of user experience as well as functionality that the desktop equivalent provides. It is said that 20% of the functionalities provided by an application are used by 80% users and the remaining 80% of the functionality of that application by 20% users. Unless over the years if the cloud becomes even stronger or as strong as the desktop, the decision of selecting an application to be installed locally or do we use the application available over the internet depends up on the criteria of which category in the 20%-80% ratio, we fall under.

E,g, If you are a very heavy Spreadsheet user, then you would surely need to use Excel on your local computer since the web version (whether be it Google Docs or Microsoft Office Live) does not provide the complete richness that the desktop version provides. That said, may be in the near future, the web version would end up being as powerful as the desktop version, then the choice would be based on other factors such as cost etc..

On the contrary if you use a spreadsheet for the most common activities, the web version is a serious option one could think of since it not only provides a huge cost benefit, but also extra security of backups etc..

Thus in a nut shell, as an end user, we have far more options to choose from, for your productivity applications we use. It is no longer choice of software for your desktop but also option to go the web way.

Google is in the process of building an OS for the cloud called Chrome OS, which means we would not need anything installed on our computer other than a web browser. If it succeeds, everything will be in the cloud!! Possible?? – Time will tell!!!

Security concerns with a SAAS system

2009-10-30T16:59:00.001+00:00

SAAS – Software as a Service can be defined as "Software deployed as a hosted service and accessed over the Internet rather than a product deployed at the customer’s premises for each customer."

Today, SAAS applications are expected to take advantage of the benefits of centralization through a single-instance, multi-tenant architecture, and to provide a feature-rich experience competitive with comparable on-premise applications.

Software as a Service (SAAS) is transforming the way traditional ISVs do business as providers of applications to the market. This new deployment and licensing model will fundamentally change the business model of the ISV, impacting many parts of the organisation – marketing, the sales force, presales engineering, deployment, support, finance, and product engineering and maintenance.

But all sounds good for the ISVs run this Business model. The main point here is to get a customer convinced to go for a subscription based software rather than on-premise software.

Customers surely see lots of business advantages by using a SAAS based product over an on-premise product. The reasoning no longer is a business decision. It is more a technical decision. The key technical factor that influences the customer to take a decision whether to go on-demand subscription-based or to buy an on-premise software is – Security.

Since the data is multi-tenanted in a SAAS environment, the fundamental question that comes to the customers mind is – How secure is my data (since it is not in front of me)? What is the guarantee that other customers of the same service do not have access to my data?

The customer should ideally be asking the SAAS providers the following questions to be convinced. It is not necessary that all the question is expected to have a positive answer for the customer to take a decision. It also depends upon what type of business application is being offered as SAAS. But “knowing” the answers is a “must” before taking a decision of going the on-demand route or on-premise route.

Here’s a list of questions I think should be asked by any customer to a SAAS vendor before subscribing to their service. The same set of questions can also be used as a check list by a SAAS vendor.

Data Access Related Questions

Is the Database Multi-tenanted?
How many people in the entire chain have the Database SA password?
Is the data for one customer securely away from another customer?
Do the Data-Centre engineers have access to the database through SA?
Can anyone in the entire chain in a position to access / copy / change / destroy critical data of any customer?
In a system where 3rd Party integration is involved, is the Data communication secured and restricted to only the required exchange of information?
What information is stored in the Audit log?
What arrangements are made for Database backup?
What types of data are encrypted and what is the encryption mechanism used to ensure it is safe?

Infrastructure Related Questions

What SLA do you the SAAS provider have with their Data Centre?
What is the hardware redundancy arrangements made by the vendor?
Does the data centre have WAN backup? i.e. The data centre is replicated in 2 different continents as a backup?

If yes, Ask all the Data Access Related Questions again with reference to this second Data centre

How many people from the SAAS vendor organisation have the network administrator password within the data centre?
How many people have the Shut-Down permission on the Server?
How often are the servers need to be restarted?
Does the SAAS vendor align with the Data Centre's SLA within their own SLA?

Internet based Security Threats

Is the Site hosting the SAAS system SSL enabled?
Is the Database server on the internet or behind a DMZ?

If, Yes it is exposed to the internet, then Why?

How is the system protected from SQL injection?
(If in case the hacker gets access to Database) Are the critical data encrypted?
Does the Application User security tightly aligned to the data security?
Last but not the least, Does the SAAS vendor / provider get their system audited by Security Auditing authorities?

Typically all these (or most of them) are covered in the SLA provided by the SAAS vendor but this is something to my mind is a must for any customer to be aware of before signing as a customer for a SAAS offering.

Agile, SAAS, NFRs & Architecture

2009-10-29T15:20:00.003+00:00

For quite sometime I have been trying to get a grip of the agile methodology to develop applications. Somehow I am not 100% convinced (although I am 90% convinced) that Agile is the way forward.
I am still in a state of mind that Agile does not solve 100% of all the software development problems. This article is my effort to highlight few of my view points on this subject.

Agile : I would not go any deep in to this topic as it is a known and a well established topic.
If would like to know more about Agile, there are tons of articles on this subject. All you would need to do is google or (in Microsoft terms) bing it :-)

The Agile Mantra says...

Individuals and Interactions - over process and tolls
Working software - over comprehensive documentation
Customer collaboration - over contract negotiation
Responding to change over following a plan

In short Agile means - "Iterative Design & development".

So far so good.

But the key point to note here is - its "Design & Development". The process starts at "Design".

For large scale systems such as high availability, high concurrency, highly scalable systems, the key way forward starts at "Architecture". May be there are cases where a good Design does not require a strong architecture pre-thought but not always the case.

Architecture is NOT Design. Architecture is a process of looking at the entire system from a high level and providing a blueprint of how large scale systems are built.

Architecting a complex product such as a SAAS offering goes beyond just designing. SAAS systems invariably has stringent Non Functional requirements such as Availability (99.99% uptime), Scalability (x Thousand Concurrent users), High Performance response times (X transactions per second), Configurability (Meta data driven configuration), Extensibility (NOT CODE extensibility but product extensibility).

All the above elements have to be well thought of for a successful implementation of a high performance solution such as a SAAS offering.

As the name suggests, these are "NON-FUNCTIONAL REQUIREMENTS". They cannot be "automatically" captured as "User stories". Even if we capture these things as a part of User stories, which sprint do these stories belong to? How do we cater to this in a particular sprint? Should this be pushed to the last sprint? How do you split these requirements within each sprint? Most applications (even enterprise scale) may not worry much about these non-functional requirements. An enterprise application can wait for a half hour down time but a SAAS system, these things are fundamental. A SAAS system is a different game all-together.

There is no doubt that Design and development is key to any software development. But equally important is Architecture. This makes me wonder if there is something called as a 100% pure Agile project? If there is a 100% pure agile project, can this be used to build a SAAS solution with stringent NFRs?

To my mind the answer is NO. The first 10-20% of the time goes in conceptualising and "architecting" the system and then the system can be developed in Sprints (which is rest of the 80%). Architectural Patterns such as Zachman, RM-ODP, Rational Unified Process etc. (or fr that matter any Architectural patterns) wouldn't have existed if it had no use and the same can be done using a Agile methodology by directly jumping into design and development.

I am not sure how this article will be received, but this is just an attempt I thought I should make share my mind to fellow architects in the software world. I do love Agile. Agile is the way to go. There is no doubt about that.

The attempt here is to highlight the fact that - "There is nothing called as 100% agile software development"

Especially if you are thinking of developing a SAAS solution with extremely stringent NFRs, ensure you cover these NFRs within your Architecture and then start development using any Agile methodology.

For an Agile evangelist, a product development life cycle is - Sprint + Spint + Sprint + Sprint.

To my mind it is - Conceptualising & Detailed Architecture + Sprint + Sprint + Sprint + Sprint.

As I have been emphasizing, I am not sure if this arcticle would be well received by Agile Evangelist, but I thought this could be a good food for thought.

I have been involved in building SAAS applications with Stringent NFRs and hence I am able to relate this to agile development.

Await for my next blog on NFRs and its importance in designing a software solution.

C++/CLI - The Alternate way

2009-08-05T14:41:00.005+01:00

Setting the Context...

Do you have heavy duty products developed in C++?
Are you reluctant to touch your tons of legacy codebase written in C++ because of its high stability?
Do you have very complex algorithm written in C++ which is difficult to re-engineer in newer Runtime based Technologies like .NET?
Are you trying to escape the re-engineering route due to above reasons even when the product is just about to reach its End-Of-Life Phase?

Solution...

Retain all the existing Complex and heavy Business Logic and re-engineer the product using a Phased Approach
Use C++/CLI to wrap the existing Native C++ code for consumption from newly designed & developed User Interface using .NET

What is C++/CLI?

C++ Language for targeting applications to .NET CLR
100% Native C++ syntax with ability to write code for .NET too
“ONE” code for Native Application and .NET CLR Applications
Keywords & Syntax for .NET CLR is distinct from Native C++ syntax to clearly differentiate the lines of code
It is a perfect blend of Static C++ Object model and Dynamic Component model of CLI hence the name C++/CLI
C++/CLI is undergoing standardization under the European Computer Manufacturers Association (ECMA) and eventually under ISO

What is good about C++/CLI?

C++ intact for native application development
Use C++ to target powerful applications for .NET CLR
Connect Windows Native Applications written in C++ and the new .NET applications “seamlessly” with ease using C++/CLI
Mix .NET code & Native C++ code within a single code
Take the advantage of C++ features within .NET that are not available on other .NET languages like C#, VB etc.
Take advantage of existing power of Native C++ for complex code that requires to be highly performance optimised
Get full support from Microsoft

Why Should ISVs choose C++/CLI?

Retain truck loads of your Native C++ code
Reuse the already optimised complex business logic
Retain Database optimisation (if already done)
Do a phased transition & Re-engineering
Take the best from technologies best suited – still .NET
C++ expertise within the organisation can be retained
C++ programmers have a career roadmap to .NET
De-couple application layers to get the advantage of extensibility
Develop all the “new” .NET code using C#, VB.NET or even C++ Build the BEST UI “outside” of the Application

Software - The Civil Construction way

2007-01-08T14:05:00.000+00:00

It was a usual Saturday morning. I got up only to find I had nothing to do today and had no social visits too, planned for the day. Was actually breaking my head to find out how should I spend the weekend as nothing was getting worked out.

Gazing out of my balcony, looking at some passing chicks ;-) my attention went towards the building construction happening at the adjacent plot of my apartment. Unintentionally, I started observing the set of activities that was taking place at the construction site and I started following the what the workers were involved in. While giving a little thought on each of their activities, I could actually relate them to the all the activities involved in a Software development life cycle. And I thought, there is absolutely no difference between a civil building construction and a software construction. Then why do we see, loose software, delays, bugs, errors, bad design, and all sorts of ill effects of a bad software and don't find any such thing in a building construction. We end up getting a building which becomes an apartment for many, has a life of at least 100 years as per the Civil Engineering principles.

Here's what I saw... (In no specific sequence)

- A Person measuring the Iron rod required to be used for the RCC (Concrete column) and cutting it in appropriate size. Each floor had more than 50 pillars, each pillar needed 6 rods. So all he was to do was measure the length from the bulk rod, and cut it to a "instructed" size. In short, he had to do 300 of them. Let me also tell you, this set of output was for the next floor and not for the current floor that was getting constructed.

- Another person bending another set of already cut rods to "instructed" rectangle size to actually hold the rods for a pillar. That's all he needed to do.

- A team of 10 involved in making the concrete mixture. 6 of them were to just move get the measured quantity of sand, rock pebbles, cement and water. 2 of them for each item and they knew what they had to do.

- A supervisor with a small chart in hand to check if the quantity of the items he estimated for a floor was actually enough for actually building that floor.

- A separate team of 4-5 involved in plastering the floors that are completed, not knowing what the others are doing.

All these and lots more were happening absolutely flawless and without anyone talking even a word. Of course, there were jokes being cracked by each one of them to keep themselves active and happy while they were working, making their day at work enjoying!

I might sound too silly, but the whole scene was just awesome looking at the fantastic team co-ordination.
That's exactly I would (for that matter everyone would) expect in case of a software development project.

How? (briefly)

- First and foremost: Requirement is clear and is almost frozen (Although External changes and room for expansion and high level modification permitted and provided room for) - In a civil construction, this is the Artistic view and the architect's blueprint.

- Have sub module blueprints of the architecture with reference to the main one. - In civil, this is the floor diagram.

- Have the Technical Architecture, Object Model, Data Model and the Design specifications as accurate as possible. Have frequent check lists at various points.

- Have a very detailed project plan. This is very important. The entire development phase should be on paper with accuracy to the greatest extent. Even the smallest module should have its low level design on paper. (Please note, this doesn't have to be a proper documentation. It can be a scribble in a piece of paper, as long as it is available handy during development of that module :-) )

- It is said that the ideal Software development life cycle has - 30% design, 40% development, 30% testing and validation. Although I would prefer 40% in design and blueprinting each and everything before the development starts, but at least not 40%, see to it that you utilise the 30% earmarked for design effectively and truthfully. I am sure everyone would agree to it, that spending more time in design (even if there is a slippage for the development to start) is worth it since the development would be faster and more or less monotonous.

- Allocate the modules to people who are specialised to do that specific piece of work. E.g. A person might be very good at usability and UI development. Make sure he or she is entrusted the task they are best at and so on. Everyone should know what they are constructing and how is it going to be used in the next upper layer. Involve the team as much as possible. The integration can be managed by module leaders and team leaders, and hence they need to know precisely what their deliverable are, what is their end product and most important, how is it going to fit in the overall system.

- Design documents should be used by the developers as a task guide, and hence see to it that the design documents for each sub module is as accurate as possible.

- Most importantly, plan the activities in such a way that the modules which need to be integrated with other modules are ready before the integrating module is just about to complete or completed. The next set of modules which can be independently developed can start in parallel by a different team. In short as I said earlier, the Project plan should be as accurate as possible.

There are many such points which can be blindly picked up from the way a civil engineering works and incorporated for software development. I have just tried to highlight the importance of having the design and blueprint accurate and complete before the development starts.

I am sure many may disagree with me to this, with a reasoning that we get very less time for software development and this does not arise is not the case with civil engineering.
The civil engineering is more than 500 year old industry and hence the ultimate aim for the software industry is to reach such accuracy that civil engineering follows.

But, with all my previous experience, I have uniformly noticed one thing that, totalled time taken for bug fixing and maintenance plus the initial development, in case of a quickly designed projects, is much more than projects which are accurately and designed in detail. There may not be any visible output early but the end product is not only sturdy but also long lived.

So that was my day on a boring Saturday which turned out to be a very fruitful one. So next time when you come across a building getting constructed, just try spending an hour or so just to notice the set of activities they do and just try to relate it to the software development life cycle and I am very sure, you would end up getting a better understanding than what I have written :-) If I knew to write great articles, I would have been an author of few books by now :-D I am very poor in expressing stuff and explaining, and hence I sincerely hope the message has been passed through successfully.

C++ In or Out?

2006-12-11T07:49:00.001+00:00

Java has been there for almost 12-14 years. Microsoft.NET has been in place for almost 5 years. As you all know, .NET initiative is the Microsoft's strategy to confer competition to Sun's J2EE or more famously the Java Technology.

When Java was launched, people thought, concepts such as memory allocations, pointers are then words of history. But still C++ had its own place in the world of software development. The basic plus point C++ always had was flexibility & power. "Memory leaks, if we develop it in C++" - general misconception still prevails in the world of software development.
Still, Low level programming requires a lot of flexibility, which only C++ provides.

Similarly when .NET was launched, three new languages were introduced to provide a mechanism for people with different language expertise to jump into the world of .NET. VB programmers were provided a road map to move to VB.NET. Java programmers were tempted to move to C# and for more big time Java fans a clone of Java for .NET was introduced - J# encouraging them to use their Java expertise to develop applications targeting .NET Framework.

C++ programmers were feeling a bit left out. With the first couple of versions of .NET (1.0 & 1.1), Microsoft provided a new form of C++ called Managed C++ or MC++ for the C++ programmers to migrate to .NET.

And the next couple of years was a nightmare for C++ programmers. I am sure all of you would agree to this, MC++ sucks. How many of us found working with MC++ was cumbersome? How many of us felt that C++ is getting a step-brotherly treatment in the world of software development? The answer to these are - ALL. The syntax of MC++ was extremely messy making the programmer scratch their heads to distinguish between Pure C++ code and MC++ code.

Oh, by the way, MC++ was supposed to be code written in C++ to target the .NET framework. Soon, C++ programmers started losing faith in Microsoft, started giving up hopes to do anything more on C++, if they have to develop any application for Windows.

Just at the right time, Microsoft C++ team played a vital role in reviving the importance of C++ and making it stand again as of today to be the most powerful language. May it be developing for .NET platform or for native applications, one can write C++ code with all their existing skills. With a major redesign in MC++, it is now possible to have 1 single unified language now called C++/CLI which has got clear distinctions syntactically for writing applications targeted for .NET and also native applications.

What is C++/CLI?

The Visual C++ team spent a lot of time listening to users working on .NET and C++, and decided to redesign the C++ support for the CLR (Common Language Runtime). This redesign is called "C++/CLI" (CLI stands for Common Language Infrastructure) , and is intended to provide a more natural syntax for consuming and authoring CLR types. C++/CLI is introduced as part of the Visual C++ 2005 (part of Visual Studio 2005)

What's good about C++/CLI?

C++ intact for native application development.
Use C++ to target applications for .NET CLR too.
Connect Windows Native Applications and the new .NET applications with ease using C++/CLI
Migrate your truckload full of native C++ applications to .NET by doing a gradual module to module porting of native code to .NET code (This is very easily done using C++/CLI's new syntax and its rich mixed mode support)
For rich pure .NET CLR based applications too, it is not completely true that C# is the only best language available. C++/CLI has been slowly emerging as the most powerful language available for targeting applications for CLR.

(More on the above points, in my next blog, till then search the net on C++/CLI and there are loads of information already that would be very helpful to you to get started)

So C++ enthusiasts, C++ not just still exists, but it rocks and soon retain its status as the the most favourite language in the world of software development. So..... Let Us...CLI

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

~SparK~ in the cloud...

You Automated 25 Steps. You Never Asked Whether You continue to need all the 25 anymore?

Why the next wave of value is capability re-imagination, not agent proliferation

Productivity gain versus structural optimisation

Why this is an architecture conversation, not an AI conversation

So, What good looks like

The tooling has caught up

Where to start

And a closing thought for my fellow software engineers

Legacy vs. AI in Asset Management: The Real Battle Is Not About Technology

First, modernize the data foundation.

Second, redesign workflows - not just tasks.

Third, treat governance and workforce readiness as strategic enablers.

Unlocking AI Value: Why Asset Management Needs an Industry Reference Architecture Now

1. AI requires standardisation of data, workflows, and controls to scale

2. Accelerates interoperability across the vendor ecosystem

3. Creates a shared language between business, technology, and regulators

4. Accelerates AI maturity across the entire value chain

5. Reduces complexity and cost in legacy simplification

6. Guides AI operating model redesign

7. Strengthens industry collaboration

Now is the most strategically aligned moment

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

So, is it time for change? Absolutely.

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

Why this matters in Asset Management

Before enabling AI, ask yourself:

Foundational steps for success:

Ready for the Next Step?

Blockchain - The latest disruptive hype : A different perspective

C++/CLI

Migration from Java to Microsoft.NET

Introduction

Need for Migration from Java to .NET

Types of Migration

Upgrade to Visual J#.NET

Converting Java code to C# using a Tool

Migration Mappings

Like to Like Components

Individual Packages vs. Assemblies

Retirement of Visual J# & JLCA tool

Way forward

References

CaaS – Now what is that?

Component As A Service

Scenario 1

Scenario 2

Scenario 3

Key Considerations when negotiating a SaaS agreement

1. Pricing and Discounts

2. Additional Costs

3. Term

4. Service Level Agreements (SLAs)

Ten Scenarios to go cloud

1) SaaS offering

2) Scalable Web Application

3) Dynamic requirement of resources

4) High processor intensive application

5) Provide a centralised high volume (yet highly secure) Data access

6) Hybrid Applications

7) Central Data Repository

8) Temporary requirement of Datacentre space

9) Experimental Applications

10) Freeware

Go cloud – An ISV perspective…Part 2 – PaaS

PaaS

Go cloud – An ISV perspective…Part 1 – SaaS

SaaS

Cloud Clarity

SaaS – Software As A Service

IaaS – Infrastructure As A Service

PaaS – Platform As A Service

Non-Functional Requirements for SaaS

Security

Scalability

Availability / Reliability

Performance

Configurability

Flexibility / Extensibility

Usability