Category Archives: Software

Posted on Mon, Nov 20, 2017 @ 4:00 pm

You have a cloud solution. Congratulations! Now, how do you sell it?

After you built your cloud solution, your next key decision is choosing the right go-to-market (GTM) strategy. There are many factors you’ll need to consider here, including subscriptions, pricing, and sales channel.

When crafting the GTM strategy for a cloud-based solution, you need to look at the subscriptions or offerings you will provide to your customers. Remember that customers like having options from which to choose, but too many options actually can deter them from making a decision. That’s why most cloud solution providers settle on three or four subscription options.  How these subscriptions are structured depends on the solution provided. Some solutions lend themselves to a feature-based subscription model, e.g., the Silver subscription has 10 features, the Gold has 20, and the Platinum has all of them. On the other hand, some solutions lend themselves to a usage-based subscription model, e.g., the Silver subscription provides up to 1,000 transactions a month, the Gold provides 5,000, and the Platinum provides 10,000.  Defining usage-based subscriptions should be done with operating and transactional costs in mind. Defining feature-based subscriptions can be a bit more confusing.

When considering a feature-based subscription model (one of the most common), an important thing to keep in mind is this question: What are the fire breaks between each subscription level?  Why would a customer want to purchase a higher cost subscription level rather than a lower cost one?  What are the “carrots” you can use to entice a customer to move up to a higher subscription? There are many ways to think about this, but there are often two major lines of thinking. One is to place entire features in only one subscription level, e.g., reporting is only in the Platinum subscription level. The second way to think about this is to spread out a feature over multiple subscriptions, e.g., canned reporting is available in the Silver package, basic report configuration in the Gold, and customized report wizards in the Platinum. The idea here is to whet their appetites with a feature in a lower subscription, knowing that once they see it they will want more, when they ask for more you have the perfect answer…upgrade to the next subscription level, and you can have it.

So, now that you have your subscription levels defined, you have to figure out how to price each level. Pricing is an art and has many components to it in order to get it right. Some factors to consider when defining pricing for a cloud-based solution are the length of your costs, license term, revenue recognition and generally accepted accounting principles (GAAP), and the value of building a stream revenue base.

When thinking about pricing, the first thing to consider is your cost. Building, delivering and hosting a cloud-based solution is free for your customers, but certainly not for you. One of the most difficult things to understand is how much it will cost to host and maintain a new cloud-based solution. Work with your cloud provider to estimate compute and storage cost. Doing so on a “per transaction” basis often can help. Then, you can estimate how many transactions each subscription level might generate per month, and you can include this in your pricing model. The next step is to think about the license term. Most smaller, less expensive solutions choose a month-to-month subscription, which give the customer the option to exit every 30 days without penalty. For larger solutions with higher costs for onboarding a customer, some will choose a quarterly or even annual license model. It all depends on the investment made in onboarding on both sides of the table.

One of the most important things to consider when defining the pricing model for a new cloud-based solution is GAAP and revenue recognition. Many companies trying to make the move to providing on-premise monolithic software solutions are used to recognizing all of the revenue from that sale up front. However, revenue can only be recognized on a monthly basis when you’re selling a cloud-based solution, regardless of how you price it. Revenue is based on how your product is consumed. This changes the revenue recognition model, which can affect any factor within an organization, such as profitability, sales channel, and sales model to name a few.  An organization launching a cloud-based solution has to be prepared to build a stream revenue model business instead of an up-front, license revenue model business.

Cloud-based solutions are often billed monthly or quarterly (depending on the size and complexity of the solution), and because of this, they typically have a lower billable price point.  Due to low initial revenue streams, it often does not make financial sense to use traditional sales channels to sell these solutions. It is difficult and often cost prohibitive to pay a sales rep commission on a monthly service. Consequently, the price point and resulting compensation is so low that most field sales reps won’t even want to sell the solution. Because of this, most companies that offer cloud-based solutions use a sales channel other than field sales. Some will use inside sales reps and others will use digital sales channels, using products like Salesforce’s Marketing Cloud to market and sell online solutions to customers. While the GTM channel is an important choice to make, regardless of the outcome of that choice, enabling the customer to see and use the solution before they purchase it is a key component to success.

Free trials are key to a successful launch of any cloud-based solution. For one thing, people have come to expect a free trial, so not having one will be a major strike one in any cloud solution launch. Secondly, customers have a need to see the solution before they purchase it, so they can understand how it works and ensure the solution fits their needs. Remember, cloud-based solutions typically have no customization (custom coding) and minimal configuration (settings). Enabling a free trial will allow your customers to see the value your solution can bring out of the box. A few notes to ensure your free trial is a successful one:

  1. Full Features – Regardless of the subscription model chosen above, the free trial should ideally contain the full feature set and no usage restrictions to enable the customer to get the full experience of the solution.
  2. Nurturing Programs – Many forget that a free trial is great, but it is just that: Free. What often happens with free stuff? It’s free, so it has little to no value. Users often forget about free trials and don’t use them. Nurturing programs are essential to converting as many free trial users to paying customers as possible. Here are some major components for a successful nurturing program:
    • Welcome emails
    • “Did you know?” emails, in which features and use cases are outlined
    • “We noticed you haven’t logged in. Can we help?” emails

Nurturing programs should not stop after the free trial is over and should continue after a purchasing decision is made. Never forget that you could potentially lose every customer every month in the cloud model. Because of this, you need to keep in touch with your customers to ensure they know you are there. Do you have a new feature? Did you just learn about a new development or trend in the market? Let your customers know about these important updates, because this shows them you are a partner and not just a solutions provider.

We hope you enjoyed our 3-part blog series on cloud solutions! If you didn’t catch the first two in the series, click here to get started. If you would like to set up a time to learn more about how we can help you build an effective cloud solution, contact us here.

About the Author

Abdul Rafay Mansoor is a technical architect at ObjectFrontier, Inc., and his work primarily involves presales consulting. Abdul has been a developer for more than a decade, and he began taking on presales consulting roles a few years ago. Abdul’s area of interest is cloud native development, and you often will find him passionately advocating cloud adoption to our clients.

Please follow and like us:
0
Posted on Thu, Nov 9, 2017 @ 12:35 pm

So, you’ve decided to build a cloud-based solution, but where do you go from here? There are a few key things that should be thought through, realized, and decided upon even before you start building your cloud solution. They revolve around what a customer of a cloud-based solution is looking for (hint, they aren’t looking for hundreds of features), which cloud service provider to choose, and why. Technically, cloud solutions are really Software as a Service (SaaS), so keep this in mind as we further explore and define cloud solutions.

Customer Expectations. As we discussed in our previous blog, features and functionality will not ensure you are a winner in the cloud space. Instead, they are table stakes. Without feature parity with your competition, your solution will not even be considered. Be confident in the knowledge that your competition has the same features as you. They know what your solution has, because they have an account on your system and have been using it since it’s been launched. Yup, they’re watching every move you make. Instead of features being the main leverage used to create differentiation, customers are defining a new paradigm.

In order of importance, the most common components customers say are essential for a cloud-based solution (in addition to security) are ease of use, service, support, scalability, performance and availability. More important than having hundreds of features is having usability, support and performance. The second group of components customers look for includes out-of-the-box integrations, insightful analytics, simple reporting, and lastly, a robust feature set.

Interestingly enough, people expect to use a cloud-based solution with no training, get the solution up and running in 10 minutes, and have easy access to helpful, on-demand support. OFS recommends you achieve these goals through being involved in implementation from the beginning and using tutorials, context-specific self-help systems that utilize videos, and chatbots to provide customers with self-service help on demand. For more information on how chatbots can help you provide excellent service to your customers, please see our blog series on chatbots here.

Cloud Service Providers. One of your most impactful decisions in this process is choosing which cloud service provider should host your new solution. There are many from which you can choose, and here are a few top examples:

  • Amazon Web Services (AWS) is the leader in cloud computing, with many services—including many fully managed services—and lots of community. However, a lot of AWS services seem to be going to vendor lock-in.
  • Microsoft Azure Cloud Services is considered the next leading cloud services provider after AWS. Azure is well suited to the Windows\.NET client base. Azure has adopted open source in big data, but every service coming from the traditional Microsoft stack (SQLServer, etc.) is going to be a vendor lock-in.
  • Google Cloud Platform (GCP) does not offer as many services and as much community support as AWS or Azure yet, but GCP is differentiating itself by not using vendor lock-in. Instead, this provider uses more open-source technologies.

Each cloud service provider has its own platform with its own APIs, management and reporting consoles, and technology stack. This is how these providers can offer differentiated services to their customers. There are so many factors that go into selecting a cloud solution that some businesses are not afraid to pick a multi-vendor configuration.

Whether you’re interested in using just one vendor, or you think a multi-vendor configuration is right for you, here are the most important factors to consider in your decision:

  1. How many services does this provider offer, and how many of them are fully managed?
  2. What is the community support like for this platform?
  3. Will I experience vendor lock-in issues with this service provider?
  4. What is the availability, durability and performance offered in this service provider’s SLA (9s)?
  5. Will I need to be aware of conflicts of interest if I choose this service provider?
  6. Is this service provider compliant with industry standards like PCI and HIPAA?
  7. What is the cost structure for this provider?

All the factors above will influence your choice, but the major advantage of cloud is the pay-as-you-go model: You don’t really commit to anything, so you can start experimenting with any or all platforms and mix and match, too. In addition, the new container-based architecture introduces a lot of flexibility.

To learn how you can effectively market and sell your cloud solution, stay tuned for our final blog in this series, “What are Cloud Solutions Anyway? Part 3,” coming next week. What are some of your observations about working with cloud solutions? Do you have any additional suggestions for what to consider when choosing a cloud service provider? Are you planning to implement a cloud solution for your business? Contact us here to talk with one of OFS’s tech experts, or leave us a comment to start the discussion!

About the Author

Abdul Rafay Mansoor is a technical architect at ObjectFrontier, Inc., and his work primarily involves presales consulting. Abdul has been a developer for more than a decade, and he began taking on presales consulting roles a few years ago. Abdul’s area of interest is cloud native development, and you often will find him passionately advocating cloud adoption to our clients.

 

Please follow and like us:
0
Posted on Thu, Nov 2, 2017 @ 7:51 am

SaaS. Public Clouds. Private Clouds. If you’re in the software industry, chances are you hear these terms pretty much every day. From your boss to your colleagues to the software industry gurus you follow on Twitter, cloud solutions are what everyone is talking about right now. But with so much noise out there, you may be asking these questions:

“What exactly are cloud solutions?”

“How relevant are they to my industry?”

“Why should I build my next solution in the cloud?”

These are very good questions we hear from many of our clients, too. As we move into an era of solutions that include Google Docs, Office 365, Mint.com and many others, it’s important to understand what these cloud solutions are and what they aren’t, as well as how customers interact with them. In this blog series, we not only want to answer your questions, but we also want to give you ideas for how you can build successful cloud solutions that speak to your customers’ needs.

To ensure we’re on the same page as you are when you read this series, it’s a good idea to start with a clear working definition of the cloud. The cloud is nothing new. In fact, the cloud has been around since ARPAnet first linked two computers together in 1969. Up until recently, the cloud consisted mostly of web and file servers hosted on different Internet-connected networks and really didn’t have too much more to offer. It remained “the Internet” for years. However, once companies started to build and deliver applications and complete solutions on the Internet, they decided to rename the Internet as “the cloud” to breathe new life into the same infrastructure. The Internet was a network of connected computers and web/file servers, and now it is a network of connected cloud solutions and cloud service providers.

While cloud solutions are very different from each other, they typically have a few common characteristics that define them as such. Cloud solutions often offer benefits such as instant provisioning of new customers and users. This requires scalability, which is provided by virtualized resources with the ability to expand and contract servers and compute power on the fly based on need. First, a cloud solution is typically deployed (installed/configured) on a group of servers hosted and maintained by a third party. With this model, the customer’s main benefit is that his or her IT department typically is not involved in the installation, configuration, or maintenance of the solution. Believe it or not, since budgets continue to shrink and more IT departments are outsourced, many IT departments are advocating for cloud-based solutions because they don’t have to be involved as much over the lifecycle of the solution. Overall, the total cost of ownership of a cloud-based solution is often much less than purchasing and maintaining a software solution in house. Secondly–and this might go without saying–cloud-based solutions are almost always accessed by people using a web browser through the Internet using standard web ports (e.g., 80 and 443) with little to no software installed locally to make the solution work. A good cloud solution will work from any network on any computer that has a modern web browser. Lastly, most cloud-based solutions are multi-tenant to achieve economies of scale for the provider.

There are two ways you can architect a multi-tenant solution, and it is extremely important to understand the difference between them. The first way to implement a multi-tenant solution is cheaper but less secure. You would have a single database that contains all data from all customers in the same tables. Naturally, this is easier to build and cheaper to run. However, this makes a lot of customers nervous because their data is commingled with their competitors’ data in the same table. The only thing separating one customer’s data from another is a customer ID field on each record. The second way to implement a multi-tenant solution is more expensive but also much more secure: Have a unique database for each customer who uses the solution.  Naturally, with one DB per customer, there is no commingling of data. Each DB can be encrypted with its own unique encryption key, and there is almost no chance one customer can gain access to another’s data.

Now that we have working definitions of the cloud and cloud-based solutions, let’s talk about the words public clouds, private clouds, and SaaS. The servers and data in a public cloud are hosted on a provider’s network intended for multiple customers to connect from any place with an Internet connection. In a private cloud, a solution and all of its data is hosted within the firewall of a single customer’s network and is only accessible by that one customer’s users.  Software-as-a-Service (SaaS) is nothing more than a deployment and a model (and sometimes a monetization method) and basically means that users access the hosted solution on demand, as they need it, with little to no installation required. SaaS is the opposite of an on-premise solution. Knowing this, you can see how certain industries would be pulled toward cloud solutions.

If you think about why customers are entertaining cloud-based solutions, it will become clear why most industries today are moving towards them. Costs are a driving factor for every business as they are all going up, like costs for personnel, health care, raw materials, and IT. At the same time, customers are demanding things to be built faster, delivered more quickly (increased costs again) and at a lower price. As a result of this and the current economic climate, most companies are seeing their department capital budgets going down, which means they have less money to invest in costly on-premise solutions. With that in mind, it is no surprise that cloud-based solutions are most relevant in industries that are being forced to operate on leaner budgets, such as higher education, facilities management, healthcare, and legal. Based on a quick review of publically available RFPs, you will find that even the federal government is moving to cloud-based solutions for some of its needs. These industries are moving to cloud-based solutions due to the tremendous cost savings as well as the other benefits they provide.

The benefits of cloud-based solutions are rather substantial for both the customer and the solution provider. Let’s look at why cloud solutions are important from both sides of this table.

The Customer. More customers are demanding services in the cloud for a number of reasons. First of all, many are becoming more cost-sensitive about large purchases and are moving from a CAP-EX operating model to an OP-EX model, meaning they don’t want to commit to purchasing a system for $50-$100k up front. Instead, these customers desire a low monthly payment with no commitment and quick onboarding. Secondly, internal IT costs are rising. We have been hearing from our customers that internal IT department chargebacks for hosting a new application are often just as much, or more, than the license of the application. Lastly, on the same point, IT departments themselves are asking for more cloud-based services since they are running “leaner” than they have in the past.

The Solution Provider. The number one reason you should be thinking about building your next solution in the cloud is simple: Your competition is already doing it. If you take a step back and think about it, the reasons become clear. In a world of cloud-based applications and agile development, you can provide new features and defect fixes every day if you want to, but in reality, the release schedule usually is once every two or three weeks. The point is when there are new features to be rolled out, all you have to do is update a single cluster of servers in a cloud instead of rolling out an update to each of your customers, getting it installed, and dealing with the support fallout of incorrectly applied upgrades and patches. Secondly, when all of your customers log into the same multi-tenant environment, you are able to accumulate all of their usage data in one place. Check out our blog on machine learning and data lakes to understand the benefits.

When all of your customer usage data is stored in one place, you can…

  • Understand usage patterns and see what features customers are and are not using
  • Perform A/B testing of new features/ideas in a real environment
  • Directly market and sell additional functionality (upsell) to specific sets of customers with specific usage patterns. For example, you can say, “We noticed you use feature X. Do you know that if you upgrade to the premium package, feature X is expanded in a way we think would be useful to you?”

Lastly, here’s what we consider the real value of a cloud-based solution: analytics. With cloud solutions and their no-commitment monthly payments comes the reality that you could lose every customer each month. They simply are not locked into any commitment, which is one of the main selling points to the customer in the first place. As a software industry, how have we retained customers in the on-premise world? Implement and release new features before the competition does. With cloud-based solutions, your competition can do that just as quickly as you. So, what is the new way to provide differentiated value to your customers? It’s through using insightful analytics and reporting.

To learn how you can select the right provider to help you build your cloud solution, stay tuned for next week’s blog, “What are Cloud Solutions Anyway? Part 2.” Or, contact us here to set up a time to talk with us about your questions and interest in implementing cloud solutions.

About the Author

Abdul Rafay Mansoor is a technical architect at ObjectFrontier, Inc., and his work primarily involves presales consulting. Abdul has been a developer for more than a decade, and he began taking on presales consulting roles a few years ago. Abdul’s area of interest is cloud native development, and you often will find him passionately advocating cloud adoption to our clients.

Please follow and like us:
0
Posted on Thu, Oct 12, 2017 @ 10:51 am

OFS Prototypes and Accelerators in Blockchain

To show you blockchain in action, I would like to share several of the prototypes and accelerators OFS just built in blockchain.

Please note that the use cases discussed below do not address all the regulatory concerns required in their respective fields. Practical applications of blockchain are still evolving and, in fact, it is possible that blockchain will do away with some of these regulatory concerns. We think this is what makes blockchain applications even more interesting. Having said that, the objective of the proofs of concepts given below is to demonstrate the disruptive potential of blockchain and the skills OFS has developed in-house to develop and deploy them.

#1 Tokenization of Automobiles Enabling Title and Lien Processing in Blockchain 

“Tokenization” is the process of representing the right to a real-world asset as a digital token in a blockchain. A tangible asset like an automobile, which over its lifetime could have many owners, titles, liens, and leases, is a perfect candidate for tokenization.

Automobiles as a Smart Contract

A real-world automobile will be represented as a smart contract on blockchain. When such a smart contract is deployed it gets a unique ID (address) and the functions (contractual terms) of the contract become immutable. The smart contract will initially have all unique and identifiable attributes required, such as a VIN number set during deployment, to uniquely identify the vehicle.

5

Smart Titles – Record of Ownership

A title is an instrument of ownership. There are a lot of administrative efforts involved in issuing, transferring, and maintaining titles. From the consumer point of view, it is something that should be kept safe. There are a lot of contractual terms regarding when a title should be transferred from a lien holder to an owner, and from a previous owner to a new owner, etc.

At the end of the day, a title is just a piece of paper and all the contractual processes around this paper are manual and time consuming. With blockchain, these paper titles can be represented as digital smart contracts.

4

Representation of titles as smart contracts makes them ‘smart’ titles with self-executing functions defining the contractual terms. For example, the transfer of ownership can be programmed in the contract according to specific conditions, such as having the outstanding loan amount paid in full. Even the payments can be processed through these smart contracts. Note that these contracts are immutable (tamper-proof), self-executing and always available.

The functions above can be implemented through traditional applications without blockchain or smart contracts, but also without disintermediation, immutability and transparency.

In the future, as the blockchain technology matures, there is so much potential for these smart contracts to be used to control the operational aspects of an automobile. For example, the contracts can be used to stop a loan defaulter from starting a vehicle until they become current in their payments.

Please note the same use case can be repurposed to fit any kind of asset that can be tokenized. Land registration is another good example.

#2 Mortgage Processing – Blockchain in Business Process Improvement

Mortgage processing has some inherent inefficiencies with its many handoffs, exchanges of value, third-party certifications and built-in delays.

A PwC report from 2016 has this to say:

“Having a third-party intermediary involved in a mortgage transaction can cost as much as 1% to 2% of a property’s value. Blockchain could reduce or eliminate the need for a third-party intermediary in the mortgage process and instead allow two parties to interact directly instead.”

Mortgage processing has many stages like origination, fulfillment, settlement, servicing, and secondary markets with many document handoffs and transfers happening between different parties, organizations, and departments, making mortgage processing a very good candidate for the smart contracts and distributed ledger aspects of blockchain. The applications are not just limited to processing and closing, but also in secondary markets for mortgage securitization.
We are developing a consumer centric mortgage origination proof of concept. Instead of working with a traditional mortgage broker or bank, the philosophy here is to allow a borrower to register the intent to borrow and submit necessary documents in a blockchain marketplace for mortgages. The lenders who have access to the blockchain review the application and respond with competing offers. Technically, blockchain is inefficient to store documents, so we propose using IPFS (https://ipfs.io/) for document storage. We will talk in more detail about IPFS in forthcoming blogs.

The proof of concept shall be expanded to include inter- and intra-organization workflows.

Blockchain-Based Mortgage Marketplace

 

2

#3 ALT Coin Payment Processing Gateway Accelerator

As cryptocurrency gains more acceptance in the market today, there is an increasing number of customers who wish to accept cryptocurrency as a form of payment. In the meantime, there is an explosion of altcoins in the market. To start accepting cryptocurrencies, existing payment processing systems should be linked to cryptocurrency exchanges to ensure users can pay with these alternate currencies. There are multiple cryptocurrency exchanges, each with its own pros and cons regarding time taken for payment processing, transaction fees, etc.

We are developing a pluggable accelerator – an API wrapper for leading exchanges – that can be plugged into your current payment processing gateway. This API wrapper will extend your gateway to start accepting cryptocurrencies.

1

Blockchain, with its smart contracts and the decentralized nature, has greater potential to disrupt any domain and its conventional applications. Even though it will take time for this technology to mature for enterprise applications, an increasing number of organizations and governments around the world are investing time and resources in developing prototypes and proof-of-concept applications with blockchain. There is great interest in how they can make better use of this technology.

Think of the saying, “Today’s fiction is tomorrow’s reality.” Blockchain is already a reality, and that tomorrow is today.

Are you currently exploring the possibility of implementing blockchain technology in your organization? The OFS tech team would love to show you a demo of our accelerators and prototypes and exchange ideas on how you can start working with blockchain technologies. Contact us here.

About the Author

gan

Ganeshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.

 

 

Please follow and like us:
0
Posted on Thu, Oct 5, 2017 @ 1:58 pm

Hardly a day passes by without someone mentioning Bitcoin, especially when the currency’s market value has reached thousands of dollars. This grabs our attention immediately. At ObjectFrontier, we are interested in Bitcoin not just for its market value, but because of the technology that makes it tick, makes it secure, and makes it successful: blockchain.

 Thanks to the likes of Vitalik Buterin, blockchain – the same engine behind the success of Bitcoin – is now available for enterprises to use and build applications on it.

 This is the first post in a two-part series on blockchain. Here, I’d like to show a brief technical view of what blockchain is and how your company can use it. In Part 2 of this series, you’ll get to learn about some of the prototypes we are building and see the opportunities blockchain enables when it’s in action.

 Please note that this post might get fairly technical, so you will need some prior understanding of databases, distributed storage, peer-to-peer (P2P) networks and computer programming.

Applications of Blockchain

As explained in Bretton Woods’ 2015 white paper here , blockchain has far-reaching applications in financial services, healthcare, retail, media, personal investment and governance. To name a few, some applications are already built for the following:

  • Clearing and settlement
  • Payments
  • Property ownership
  • Digital identity
  • Voting
  • Insurance mortgage lending
  • Release of health records
  • Title and lien holding
  • Crowd sourcing

The Blockchain

It is an undeniable fact that Bitcoin revolutionized the field of cryptocurrencies. As mentioned above, the key to Bitcoin’s success compared to many of its predecessors is its underlying technology: the blockchain. Blockchain is a distributed transaction ledger replicated in all participating nodes in the blockchain network, with no central authority controlling it.

Technically, a blockchain is a decentralized database with random independent nodes participating in the network. All the nodes in this network will have the same version of blockchain, and hence the ledger is distributed and one single version of blockchain is replicated across all the nodes. As the name indicates, a “blockchain” is a chain of blocks. The blocks contain transactions committed to the blockchain.

The state of the blockchain changes based on the transactions added to the blocks that make up the chain. Any node in the network can add a block to a blockchain. However, since a blockchain is disintermediated, with no central authority controlling what transactions make up a block or which block is added to the chain, we need a consensus between the competing nodes trying to add the block. A consensus algorithm called Proof of Work (PoW) achieves this unanimity. PoW is the consensus algorithm currently employed by the likes of Bitcoin and Ethereum. Check out this Ethereum white paper for more details.

Beyond cryptocurrencies, blockchain technology—with its decentralized, disintermediary nature—has immense potential to open up new avenues and markets for enterprises willing to build revolutionary applications on blockchain, giving them an edge over others. Private, permissioned blockchain is especially attractive to many enterprises in financial services and healthcare. It is encouraging to see increased acceptance of blockchain with states like Vermont passing legislations honoring transactions on blockchain.

Programmability of Blockchain

To understand the programmability of blockchain, we have to take a good look at how Bitcoin works. When Alice transfers a few bitcoins to Bob, this is considered a transaction in Bitcoin’s blockchain.

As shown below, a Bitcoin transaction has two sections: Input and Output.


Input:

Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6

Index: 0

scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10

90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501


Output:

Value: 5000000000

scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d

OP_EQUALVERIFY OP_CHECKSIG

Without getting into the fine-grained details, the scriptSig and sciptPubKey are actually scripts that define the business logic for this transaction. When executed, this script evaluates the input against defined conditions and ends up changing the state of blockchain if all conditions are met. This ability to define logic in a transaction is what makes blockchain programmable.

Scripting in Bitcoin cannot be expanded much beyond cryptocurrencies, because it is not developed with such applications in mind. Technically, the scripting language in Bitcoin is not Turing complete. This limitation in Bitcoin is overcome by the leading blockchain platforms like Ethereum and Hyperledger, making blockchain a viable option to develop and deploy applications for enterprises.

These platforms also focus on privacy, scalability and access control, making them ready for building and deploying enterprise applications.

Blockchain Platforms

There are many blockchain platforms available in the market today that enable the use of a “smart contract,” which is a code that facilitates the secure execution of contracts between two parties on blockchain. Applications that use smart contracts are called “Decentralized Applications (DAPPS).”

Here are the two leading blockchain platforms:

Both of these platforms enjoy good community contribution, industry adoption and enterprise backing.

Ethereum, which is backed by Ethereum Foundation, is an open software platform based on blockchain technology that can be used to build and deploy smart contracts for decentralized applications. Smart contracts are programs that are deployed to blockchain and run on the Ethereum Virtual Machine (EVM) in an Ethereum network.

Smart contracts are immutable once deployed, and because of blockchain’s decentralized nature, they will always be available for invocations. Invocations of smart contracts are transactions that make up the blocks in blockchain. These transactions can contain data for functions called on smart contracts. Smart contracts have their own storage that can be used to register state changes and can return output of the function invocations. One contract can call other contracts and create more contracts in run time. Ethereum smart contracts are developed using a contract-oriented language called Solidity.

DAPPS are traditional web applications that invoke and use smart contracts behind the scenes. Ethereum is primarily a public blockchain that can be run as a private blockchain.

Hyperledger Fabric backed by Linux Foundation is a platform for running a private blockchain (a.k.a. permission blockchains). Permissioned blockchains are similar in all aspects to the public blockchain except for the following:

  • They are private. These blockchains are accessible only by approved parties.
  • They have pluggable consensus. Participating organizations can decide on the consensus protocol.
  • They allow for specific permissions. There is fine-grained control over who can read and initiate transactions in these blockchains.

The characteristics of a private blockchain sometimes make Hyperledger Fabric an attractive option for the enterprises. You can use the factors above to determine what suits your own use case best.

In general, Hyperledger Fabric works with the same principles as Ethereum with some differences in terminologies. For example, smart contracts are referred to as chaincode and the choice of language for development of contract is Go.

Both the platforms are equally powerful and capable of building revolutionary applications.

To see what blockchain looks like in action through several use cases, check out Part 2 of this series here.

About the Author

ganGaneshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.

 

 

Please follow and like us:
0
Posted on Wed, Apr 13, 2016 @ 6:46 am

I’m an old ­­software warhorse and wrote my first program back in 1972. Everything certainly has changed since then, but some principles endure. For example, one of my early bosses used to remark that good software was like a good axe a lumberjack used for years. Yes, the head had been changed several times and the handle was replaced a few times too, but somehow, it was still the same axe. His point was that good code should be designed and separated into components, so that as one part wears out, it can be replaced without throwing away the entire code base. Even when all the components have been replaced over time, somehow the product is still the same.

That concept of separate components with well-defined interfaces is particularly relevant in today’s digital business. As we all rush headlong into the process of digital transformation, it’s important that we don’t get so wrapped up in the latest mobile, cloud, and IoT technologies that we forget the basic notion that it will all change again. (And, like a metaphorical Yoda in the software world, I’ve lived long enough to see it change many, many times!) We can prepare for that change by moving to an API model that encapsulates our important business logic, which doesn’t change as often, from the ever-changing ways we use that logic to drive our business.

You often hear about the API economy these days, and as a veteran from the early days, I think it’s great to see us reach that nirvana of re-use we had long hoped for years ago. You no longer need to know the details of where data is stored, how it is accessed, or all the rules pertaining to it. You just call the component with an agreed-to format (API) and you instantly get the data you need to incorporate into your own program’s needs. This has given cloud-based software a tremendous boost that allows us to quickly build new software that stands on the shoulders of software already written and tested by someone else.

That same concept applies to our internal business software. If we can componentize our business rules and database access and create a set of well-defined API calls to handle things like adding a customer, calculating a payment, or giving out the current inventory level of a specific product, we are setting up our own building blocks that enable us to assemble them in new and important ways during our digital transformation efforts. Put another way, if we expect to fully participate in the API economy with other businesses, we must build our own APIs for ourselves first.

For example, APIs that record and monitor a car rental can be used by the rental agency’s website for booking purposes, by the renter’s expense management system to get the receipt and charges, and by the car’s manufacturer to provide usage information for warranty coverage.

While all this would certainly help the customer on his journey and streamline the car rental agency’s processing, it requires a lot of effort. The agency first must simplify its backend systems by getting rid of duplicate systems of record that store rental information inherited from prior acquisitions.  However, it takes years to decommission old systems of record. In the meantime, it may be necessary to design and build lower-level APIs around each of the duplicate systems and then build higher-level APIs to hide the fact that some of the data is actually stored in different systems. Neither the renter, nor his expense management system, nor the car manufacturer care one bit about which internal system the agency is using to record the transactions they need. You need to have your APIs mask all that complexity so you can offer a single view into your company and a single way to do business. This is the essence of what APIs offer to both your external customers and your own developers.

While it might be nice to try to build APIs for all your corporate data, the reality is that even if you could do it, the time and cost required would be prohibitive. You have to focus on building your APIs over time, embedding the work to do them in each of the short-term projects that our business requires. This requires some real discipline, as it always takes longer to build some APIs first than it would to just bang out the code asked for by the business.

Also, it always seems that your own staff, who are building new APIs, are the last ones to use them. However, by incenting them through carrots and sticks (like authorship awards for new APIs or penalties for not using them), you’ll create the ability to change the axehead and handle of your systems while keeping the essence of them the same.

Please follow and like us:
0