Software Development can be a long and costly process which can be extremely risky at times. Many companies have tried to combat the risks associated with developing software that does not function in a way that is intended or is unable to properly execute all of its tasks.
One of the major ways to combat these issues is using Low Code Platforms, which have gained a lot in popularity. These platforms are designed for people with different backgrounds and levels of expertise to be able to build functional platforms for their organizations.
While developed software is usually easier to use and can be catered perfectly to the specific operations of the organization, they are notoriously hard to maintain in house. These software’s usually require regular maintenance, upgrading and constant oversight to operate at full capacity, this creates cost and worry for the sources of such software.
On the other hand, Low Code software are very hard to cater specifically to an organization’s specific needs and often impossible to add on, migrate or change. This has driven many experienced software developers away from these platforms.
Big Technology companies have not been a stranger to these issues; organizations like Out Systems have revolutionized the way Low Code platforms work by allowing them to have flexibility in their build and properly managing their data. However, Low Code platforms still have a way to go before they are fully accepted as a viable solution for Enterprise Software Development. Read More An Introduction to Low-Code Development Platforms
First it was the enterprise data model, then data warehouse, enterprise architecture, and finally master data management that became the consultancy solution mega implementations. Each has run its initial course with, at times, very limited results. Some organizations have abandoned methods that demand high levels of investment with the promise of future payback. Today, the pace of change requires incremental, quick-paced action to implement something of value.
Read More Estrada’s Micro-Methods for Data and Business Intelligence
Choose your options
Azure as a cloud service is gaining market share; 13 per cent as of Q1 2018 and second only to AWS with 33 per cent according to Synergy Research Group. Many companies are hoping on-board the Azure train as the platform becomes more mature and more services become available and cost effective.
Building a data warehouse using SQL Server database on Azure is one of the many use cases that’s gaining traction.
This blog explores and compare some key differences between the 3 options to build data warehouse using SQL Server database on Azure.
Read More Building SQL Server Data Warehouse in Azure
Azure is a cloud computing environment that has grown in size and demand over the time, it was first released in 2010 under the name Windows Azure. Later, in 2014, it was renamed to Microsoft Azure. It has a robust, web browser based dashboard that will let you administer all of your cloud resources as well as an extension of PowerShell cmdlets (command line executables) to facilitate resource management and DevOps tasks. It offers multi-platform solutions and different service levels that will accommodate the needs of most companies in a pay-as-you-go schema, moving from Capital Expenditure (CapEx) to Operation Expenditure (OpEx). Read More Microsoft Azure: Service levels to accommodate your needs
Many organizations are transitioning to Agile as their preferred lifecycle model for software development. Transitions were directed due to inability for former methods to lead to successful results. After being brought in to help manage a portfolio of projects in several organizations, there were some disturbing trends when using Agile:
- Software was delivered, but the users found the software to be unusable.
- Consultants developed the software, then left. The organization staff had no idea how to maintain the software.
- A number of application projects were completed. Each had a different architecture and set of tools required to build and maintain the application.
- Projects were being reported to governance teams with scheduled dates, yet there were no apparent requirements, use cases, user stories, backlog or other lists that might indicate what is being built.
- Management was completely at a loss about how to resource projects since many seemed to be ongoing forever without completion.
There were some exceptions; however, the preponderance of software development initiatives that succeeded were very small in scope and constituted a low percentage of overall projects required for customers. There was some information available within the organizations that indicated a process was initiated to convert from a traditional (Waterfall) lifecycle to the Agile lifecycle. Many of the benefits of Agile, however, were not being demonstrated by the activity taking place. What happened?
Read More Are you Agile, or Fragile?