Services

Enter

close

Enterprise Software development and Services

A number of successful businesses follow product distribution or directs sales as their core business. Other’s provide non tangible products like movie viewing. These organizations require customized software’s to manage their customers, sales, production, procurement and distribution and others. Typically each organization builds a workflow best suited to their processes, sometimes these customizations are the “Unique value Preposition” of the business.

Kranti excels and has a stable practice in consulting and developing scalable enterprise solutions in the space of ERP, CRM (B2B and B2C) and e-commerce. Kranti has built customer facing applications, back office applications and integrated various business systems.

Kranti’s exposure in this fields includes many standard products based on business and technical needs. These include but are not limited to Microsoft Dynamics, Sugar CRM, Salesforce, Oracle, SAP, Maximo, Odoo, WebERP and others.

We on need basis developed completely custom software from scratch but discourage this practice to avoid costs and duplication of business consulting effort.

All enterprise software development begins as a consulting exercise with a goal of understanding requirements, existing setup (IT and back office). This is followed by identification of candidate software which best fits the bill. The selection is based on requirements and existing IT infrastructure. The software is then customised as required and implemented.

Kranti recommends usage of PAAS based ERP and CRM solutions to clients where possible to reduce cost and improve scalability. CRM software is typically used to manage customers which may be an end consumer of another business, this leads to two different variants of CRM vis B2B and B2C CRM.

CRM’s have many features such as relationship management, sales force automation, opportunity management, customer profile, CRM’s are minded with customer behaviour and trends to find how to best serve a customer.

CRM’s also integrate with ERP packages in an end to end automation of customer demands. Kranti has significant experience in integrating CRM’s and feeding them into ERP’s.

ERP’s are typically mammoth software developed to manage entire back office of a typical sales / product oriented enterprise. It includes but is not limited to product planning and procurement, management of vendors, accounting, inventory management, shipping and payments, sales, marketing, manufacturing, workflow management and many more. ERP can also include HR features like recruitment and trainings.

Both ERP and CRM are transactional systems they also typically support integration into other systems because in a typical enterprise either input are coming in from a number of legacy systems which have grown over the years before an entire ERP would have been implemented. Kranti recommends to move to a full ERP and only do a one-time migration in most business cases while making the ERP primary tool for all system needs however at times when this is not possible both real time integration and end of business reconciliation strategies are used on a case to case basis.

A business solution using ERP’s and CRM’s also lead to investments into building a data where house to mine content to plan long term business strategies. Kranti has sufficient exposure into these practices to help build clients end to end systems for sales, planning and minding information.

Enterprise Software development and Services

A number of successful businesses follow product distribution or directs sales as their core business. Other’s provide non tangible products like movie viewing. These organizations require customized software’s to manage their customers, sales, production, procurement and distribution and others.

Typically each organization builds a workflow best suited to their processes, sometimes these customizations are the “Unique value Preposition” of the business.

Kranti excels and has a stable practice in consulting and developing scalable enterprise solutions in the space of ERP, CRM (B2B and B2C) and e-commerce. Kranti has built customer facing applications, back office applications and integrated various business systems.

Readmore

close

Internet Scale Solutions

Internet is huge (Annoyed reader, I never knew that) however is performs and is successful. To be able to design applications beyond the enterprise and into the internet scale of architecture we must study why internet is successful and build applications that mimic the internet.
Internet has proven to be infinitely scalable. Switches, gateways, web servers and so on can all scale.
In this article we attempt to find the reason for this inherent scalability and what can be learnt to achieve the same in building applications on the internet scale

What is internet scale?

We call applications (not just websites) like facebook, twitter, google internet scale applications how are they different from the so called enterprise application’s serving a few thousand people.
While writing this paper the author searched the web to find something satisfactory. We found many examples, some characteristics but no definition. So we finally came up with our own definition “An internet scale application is an application available on the internet which is capable of serving and serves a significant user base of the internet user base.”
In short they are capable of serving many million people, by very nature of definition they will be multitenant and would be serving people from all over the world rather than confines of a few servers in a data centre.

What are the challenges of the internet scale?

Given the unique problem and area the internet scale applications serve in they have a set of challenges. Some of the most important ones are -

  1. Load – An internet scale application has a very large load, for example 71% of online adults use facebook (http://www.pewinternet.org/fact-sheets/social-networking-fact-sheet/). This is a huge number and facebook needs to deal with this load constantly.
  2. Speed / throughput - To be able to keep clients happy the speed needs  to be instantaneous even in high loads. The operations team need strategies at their command to deliver constraint performance.
  3. Distribution of software and updating software – Software distribution and update should be instantaneous and with zero downtime for users.
  4. Unpredictability of traffic – Load’s can suddenly come on the application if something is successful, take the example of “Gangam style” which almost broke Youtube. Application strategies should plan for these unpredictable load at acceptable costs.
  5. Client infrastructure – Unlike enterprise applications where the user experience and client infrastructure may be controlled, internet scale applications do not have such rigid controls. Applications are expected to behave in browsers, mobiles, tablets and other devices. Small obscure bugs can suddenly effect thousands of users.

In essence there need to be a set of patterns to manage these and other operational issues.
In the remainder of this article we explore how to resolve these problems using proven methods and tools at our disposal.

The so called magic bullet

We need to ask ourselves what do we learn when we read up a RFC for an internet protocol like HTTP or FTP and how we can use guidelines in these documents to architect our own applications.
Web as we have experienced has taught us the following

  1. Be stateless - State is evil, it is hard to maintain and requires context. Each request in itself should be complete. State sometimes is perceived to bring performance as it reduces the round trips between business servers and database but they severely reduce scalability and throughput. State is a death sentence to linear scalability
  2. Everything should have a URI to find it uniquely and consistently
  3. Cache- Caching on server or client or anywhere inbetween certainly improves performance. Caching can be a strategy where a group of users can be shown similar data. RFC for http has entire sections devoted to caching and URL’s and should be used to fullest in an internet scale application.
  4. Have clear mechanisms to direct an operation like PUT or POST
  5. Have clear well understood error and response codes like404 is not found
  6. Rich metadata

These point the author towards inferring REST as the key to building internet scale applications. RESTfull services are scalable dictate being stateless and have the rich features of the internet built into their design.
The technology is client agnostic and encourages clients to build their own presentation hence reducing the volume of data transferred over the internet.

Strategies for internet scale

This final section provides certain set of guidelines when building applications for the internet scale

Asynchronous processing

Accepting a piece of work doesn’t mean you have to do it right away, always ask yourself a question do I need to do it right now? Entire No-SQL movement seems to be based around this and is feeding the internet. By delaying the processing throughput increases, acknowledgement time decrease.

Heterogeneous client base

The client on which user experience is displayed is the best judge of its capabilities. The UI should not be driven by the server instead REST api’s should deliver content and there should be client side code generating the user experience.

Deployment strategies of internet scale

On the internet scale there will be massive number of servers which will come up and go down. Non trivial strategies for build deployment need to be created, for instance facebook uses bittorrent to push build to their systems http://arstechnica.com/business/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering/

Configuration strategy for internet scale

While everything else should be distributed, configuration management should be centrally pushed to all systems. This will allow consistent and common configuration across servers and can be consistently changed. Tools like database based configurations, puppet master and others should be the defacto standard for configuration management.

Internet Scale Solutions

Internet is huge (Annoyed reader, I never knew that) however is performs and is successful. To be able to design applications beyond the enterprise and into the internet scale of architecture we must study why internet is successful and build applications that mimic the internet.

Internet has proven to be infinitely scalable. Switches, gateways, web servers and so on can all scale.

In this article we attempt to find the reason for this inherent scalability and what can be learnt to achieve the same in building applications on the internet scale.

Readmore

close

Product Enginnering -DevOps

It has suddenly become hard to define devops, everyone seem’s to be doing it as part of agile, turf’s are invaded and things seem to be failing. What is it that Kranti is doing differently and succeeding in its DevOps practices?
DevOps has become an extremely overloaded term, it has started to mean anything and everything. We have tried to define what DevOps means to us and how we successfully employ it into every project.  We also explore the critical success factors
DevOps is Dev+Ops, Dev meaning here performing all development tasks such as requirement analysis, coding, deployment and others. Operations meaning tasks like system monitoring, release management and others.
DevOps is a style of IT development, implementation and management in which development team is essentially responsible for building an application and then deploying and managing it. The goal is to essentially bridge the gap between development and IT operations and business doesn’t have to hear it is not my fault.
The idea is development team is usually better equipped to understand the scores of configurations, deployments and understanding faults of the applications they build. It has been observed in many IT support what takes days for IT and Level1/2 support to define takes minutes for development team to fix because of their intimate familiarity with the system.
This also brings a culture of responsibility within development teams as they have to support operations of products they build.
There are many consequences (strange consequences driving factors) that have led to easier DevOps adoption, these include but are not limited to agile adoption and agile goals, extreme degree of automation right down to virtualization, availability of cloud cutting down separate operation team’s usefulness and others.
However this is easier said than done the development teams are usually overloaded with changing priorities, operations and deployment requires certain degree of red tape while typical developers are gung-ho and ready to change during deployment, there is an obvious turf war.
Kranti has tried to solve some of these issues with a set of commandments which we shall explore in this article.

  • Automate build and release including Database – Kranti automates entire build and release process this is not just for code deployment but also for VM creation when required, Database diff scripts and so on. Entire deployment process is one click using a CI tool like Jenkins. This process gives minimum access to team doing deployments and hence ensuring no sudden change in system code or configuration.
  • Same scripts for all environments – Right from Development to production it is encouraged to use the same set of scripts to be used for deployment, this ensures testing of the automation scripts and having a consistent deployment pattern.
  • Configuration Management with one key change only – All configuration in the system is stored within the database, this has a number of advantages such as when configuration is changed it is changed at one place only. Further it ensures deployment teams have to change only one variable (in an automated manner) to change from one environment to other.
  • Builds can only move to a higher environment via promotion – Builds can only move from one environment to other via process of promotion, the promotion process and pre-requisites are automated and require all test cases (Dev UT and QA automation) pass before the build may be promoted. In certain cases other criteria such as performance and others may also be required.
  • Automate Reports and send them on a daily basis and these should be present for all environments – System reports like exception details, CPU and memory utilization and others are automated and put on every environment. Further the development team is encouraged to use these in there day to day debugging of issues giving the teams experience in reports and also ensuring consistency.
  • Automate alerts – All alerts like reports are automated.

So to sum it up Kranti uses heavy automation and consistency across environments to ensure DevOps.
The Ops of DevOps for us is not an afterthought but a day to day task in our Dev cycle to successfully practice DevOps.

Product Engineering-DevOps

It has suddenly become hard to define devops, everyone seem’s to be doing it as part of agile, turf’s are invaded and things seem to be failing. What is it that Kranti is doing differently and succeeding in its DevOps practices?

DevOps has become an extremely overloaded term, it has started to mean anything and everything. We have tried to define what DevOps means to us and how we successfully employ it into every project. We also explore the critical success factors

DevOps is Dev+Ops, Dev meaning here performing all development tasks such as requirement analysis, coding, deployment and others. Operations meaning tasks like system monitoring, release management and others.

Readmore

close

Enterprise integration

Enterprise integration allows sharing of data and business logic. It allows creation of centres of excellence. It reduces duplication provides end users consistent experience. It allows performance and scalability.
Data design has always been an art. While remainder of technology becomes more or less of science. Although historically there have been multiple patterns to achieve the goals such as PubSub, Point to Point connect, Enterprise beans, Microsoft (D)COM(+), web services etc. This discussion focuses on topics relevant to today’s IT infrastructure.
There can be varied purposes of EAI such as data integration, extraction of business logic etc.
The two important patterns for enterprises are “PubSub” for sharing data and “Exposure of API’s” for sharing business logic which will be the focus of this paper.

PubSub

PubSub essentially is a pattern in which data for a topic is published by authorities of data while interested systems receive the data and store local copies. It the authoritative system is changed subscribers are shielded to the change.
Conceder an example in an organization where a HR system is  authoritative for employee information, whenever a new employee is hired by an organization or services are terminated the HR system may publish this information to interested systems for example finance or security.
The essential focus point of PubSub is data and topic and not the system vis messaging. PubSub requires maturity of building a data model (the art) which will be forward thinking and allows extension. Industry experts have created many such models and adoption varies from industry to industry for example while banks have consistent models with high adoption rates logistics has varied models across organizations.
There are multiple products aiming PubSub based integrations for example Tibco, Biztalk, Apache MQ, Rabbit MQ, Open ESB and others.
Kranti has wealth of experience in integrating systems using service bus using both proprietary and open source products in domains like banking, trading, insurance, logistics and e-Commerce. These experiences arein areas of architecture, development and implementations. All Kranti architectures are created with seamless data integration pattern with an assumption data will be consumed by other systems.

 API based design

API or more accurately REST based API’s has become the defacto standard for exposing business logic, at times the said API may also be used for data integrations but the payload size is usually small.
REST APi’s have an advantage they standardize on available actions CRUD (much like SQL standardises on actions that may be done on tables), standardise on errors and other meta information such as content type, languages etc. As always the art remains designing data which forms core of design.
Kranti has a wealth of experience in creating RESTful API’s across platforms like .net, Java, python-Django and others. Kranti is heavily invested into creating open source frameworks with REST first approach. This approach allows applications built to have various clients like web browsers or mobile apps.
All Kranti applications are architected as RESTful Api’s with an assumption that client applications for various platforms will be created as the business expands. This further allows separation of concern and clean testable interfaces.

Enterprise integration

Enterprise integration allows sharing of data and business logic. It allows creation of centres of excellence. It reduces duplication provides end users consistent experience. It allows performance and scalability.

Data design has always been an art. While remainder of technology becomes more or less of science. Although historically there have been multiple patterns to achieve the goals such as PubSub, Point to Point connect, Enterprise beans, Microsoft (D)COM(+), web services etc. This discussion focuses on topics relevant to today’s IT infrastructure.

Readmore

close

Mobility

Mobility is no longer niche area it’s a requirement for any modern application be it an enterprise solution or an internet based application.
Mobility is important because it reduces many manual and rework steps within a business. Many business do not have the luxury of sitting on a desk while performing tasks consider examples of doctors taking rounds and filling charts, logistics providers giving deliveries and others.
While some industries have tried to provide customs solutions as in logistics industry a number of them are yet to come up with integrating their back ends with mobile devices.
The term “mobile devices” in the opinion of the author has become blurred and overloaded, should we only consider relatively old school devices like tablets and smart phones mobile devices or are the new age devices like glasses and watches also a part of this mobility bandwagon? And with all this where will the traditional browser based solutions go? With something as tiny as a watch or as untraditional as a glasses what will be the user experience?
In this paper we will try to pose some of these questions, explore currently available solutions. It is difficult to provide a solution in the information space today when by the time this paper is published most of the postulates will be obsolete.
The IT world in the opinion of the author moves like a pendulum. The two extremes being processing done at client end or on server. We started with people taking punch cards to computer operators with processing done on the machine next to us. We then moved to a thin client model with dumb clients talking to servers, we then had thick client era with processing done on local machines. Then we had the web era where processing was done again on server and so on.
Current mobility solutions provide similar options of processing at a device aka building mobile apps or processing on server using responsive websites.
App building has a fascination it allows real-estate and permanent presence on the client’s device. It has technical advantage of making user experience decisions on the device.
New solutions in the mobile space are using HTML to create app’s and hence making the solution game simple. Phoengap is one such leader and is bringing phone app development from the niche development to a simplified development platform.
Current HTML was built to cater needs of a screen based user experience and input it has been tailored to traditional mobile devices, however there exists a gap for the new age devices such as glasses and watches. There is a clear need of a mark-up language as simple as HTML for these devices.
Another concern has been rendering of user experience, there is a clear need to think beyond the two dimensional canvas and hands as input, what will future hold for us would a conversation based system best help user experience where localization will mean translation of text on various languages? Would gestures based system’s become the new defacto standard for inputs as on Proff. Steven Hawkin’s system?
In the opinion of the author our best bet today will be to build responsive websites with clear separation of data and user experience. The information has to be available to provide user experience. The author also thinks that app’s will be a fad and eventually a consistent client will be used to deliver the mobile experience in a manner similar to browser.

Mobility

Mobility is no longer niche area it’s a requirement for any modern application be it an enterprise solution or an internet based application.

Mobility is important because it reduces many manual and rework steps within a business. Many business do not have the luxury of sitting on a desk while performing tasks consider examples of doctors taking rounds and filling charts, logistics providers giving deliveries and others.

While some industries have tried to provide customs solutions as in logistics industry a number of them are yet to come up with integrating their back ends with mobile devices.

Readmore

close

Testing

The objective of this section is to provide an introduction to testing services available from Kranti for testing of applications.

Objective of Quality Assurance

The objective of quality assurance is preservation of assets, provide a set of artefacts to reassess quality on demand (assets may be employed in manual or automated manner) and reports which provide a measurable and dimensional views to effort employed by assets.
By “quality assurance” we mean providing a reasonable assurance and assistance to stake holders to have a view of the quality of the application to make informed decisions.
“Artefacts to reassess quality on demand” means providing a set of documents, scripts and other items of interest such that any team may on demand execute tests again and again to find the quality.
“Reports” would be a set of aggregated data which provide easy to understand multi-dimensional aggregated data to ensure stakeholders can focus on the needs of the hour without getting into too much details.

Quality Assurance Approach

Kranti team employed multiple dimensions towards testing these include

  • Manual scripted testing – Manual testing is done by having dedicated teams manually testing the application by using a browser or tools like fiddler to hand craft requests. Manual testing is done only in the initial stages of the application development when creation of automated tests may fail. However it is strongly recommended to convert all manual testing scripts to automated scripts after one or two rounds of testing. Manual testing may be employed as a long term solution on a case to cases basis where tests may be long running or may needed server changes for example testing of daylight savings requires server date changes.
  • Automated testing – Automated testing is ideally the goal of ay test case. Its objective is to preserve assets at low cost. Typically automated tests are executed on every build deployment and is controlled using continuous integration tools like Jenkins, TFS and others. It should be noted in automated testing we randomize all inputs to cover a wide range of values to ensure obscure data dependent cases are also covered.
  • Exploratory / Monkey testing – This testing is done randomly on the application with an intent to break it. Every time a new break is found in code it is promoted to an automated or a manual test case to ensure that the bug is never missed again.
  • Code analysis – Kranti firmly believes that a number of non-functional and functional defects are caused due to following poor practices, hence our quality assurance (not testing) practices employ manual and automated code analysis. This analysis is done by experienced engineers and uses tools like Sonar, find bugs, fx-cop, xLint and others (depending on language). This testing finds issues which may not cause issues right away but at a later stage for example unwanted table locks or poor localization and globalization techniques. Automated analysis may be plugged into continuous integration tools and can be executed on a per development checkin.  
  • Non-functional Security testing – Kranti is vigilant towards security testing, there are multiple techniques used for security testing which include but is not limited to (using both manual and automated scripts) to check for
    • Executing OWASP top 10 like XSS attacks
    • Code analysis to find issues like minimal surface area exposure, minimum permissions to execute code, configuration for buffer overflow, patches etc.
    • Running tools like Retina or AppScan etc.
  • Non-functional performance testing – Kranti has a dedicated team of engineers to assess performance of an application. This includes running load tests, soak tests, reliability tests, stress tests, volume tests, testing for disaster recovery and others. The objective being to ensure that performance will be acceptable under any expected load.

BDD Testing

Kranti models all its test’s under the behavioural driven development approach, vis following the test cases to be defined as “Given per condition” “When user performs action” “Then expected response”.
This allows business to easily validate and prioritize cases. BDD also has a number  of frameworks for testing which may be exploited for purpose of testing.

Reporting

This section lists the reports utilized for generating test results.

Reports for all tests

  • Test case coverage – This report provides the number of test cases executed with details like how many were executed successfully, what failed, what could not be executed and what were not executed.
  • Priority/Severity vice defects timeline - This report informs a timeline of priority and or severity of defects on a per execution cycle basis.
  • Defect reopen rate – This report informs if a defect is reopened in retest cycle either because it was not properly fixed or reopened at a later stage.
  • Defect injection rate and ratio – This report indicates the number of defects inserted per KLOC, other metric may be used on client needs. This requires access to source code repository to find code churn.

Reports for Automated Tests

  • Code coverage – This report defines what percentage of codebase was hit by running tests.  It is suggested that code coverage be computed by using QA and developer test cases. A higher code coverage ensures confidence between builds.
  • Automation coverage – This report describes the number of automated test cases vs total number of test cases, higher values ensure larger automated test cases.
  • Cost savings due to automation – This report describes cost savings due to automation ideally in number of man-hours.

Reports for code exploration and automated static code analysis

  • Default reports from tool – Based on tool used like sonar, fxcop and others a defatult report with drill downs (where available) is shared with highlights in a report.
  • Code Review report - This is a report based on manual code review to inform any high priority issues.

Reports for Security Issues

  • OWASP security threat analysis -  This is a report based on OWASP security threats, this may be executed manually or using automated tools
  • Surface area analysis -  This report is based on study of surface area exposed of the application and checks things like if minimal number of ports are open, if user has minimal roles, file permissions etc to run the application.
  • Default report from tools – This is a default report based on tools such as retina or AppScan and others.

Reports for performance

  • Load test results
  • Constraint test results
  • Scalability requirements
  • Soak test results
  • Test stress results
  • Disaster recovery results

Tools

This section highlights some of the tools being used, however it should be noted that based on tech stack these tools may be changed

Area

Tool

Continuous Integration

Jenkins, Hudson, TFS, Bamboo others

Static Code Analysis

Sonar, FxCop, Lint others

Performance

Load Runner, JRunner, Ant Profiler, yourkit, JSLitmus, Chrome add on’s and others

Security

Retina, Burp Suite, Nikto, DirBuster, Firebug, SqlMap and others depending on application (API testing usually requires creation of automated test scripts using SOAP UI)

BDD Testing

Language specific

Automated Testing (other than BDD)

xUnit, Nightwatch, Selenium, SOAP UI and others

 

 

TESTING

The objective of this section is to provide an introduction to testing services available from Kranti for testing of applications.

Objective of Quality Assurance

The objective of quality assurance is preservation of assets, provide a set of artefacts to reassess quality on demand (assets may be employed in manual or automated manner) and reports which provide a measurable and dimensional views to effort employed by assets.

Readmore